One document matched: draft-ietf-repute-media-type-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="4" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-repute-media-type-00"
ipr="trust200902">
<front>
<title abbrev="Reputation Media Type">
A Media Type for Reputation Interchange
</title>
<author fullname="Nathaniel Borenstein" initials="N." surname="Borenstein">
<organization>Mimecast</organization>
<address>
<postal>
<street>203 Crescent St., Suite 303</street>
<city>Waltham</city>
<region>MA</region>
<code>02453</code>
<country>USA</country>
</postal>
<phone>+1 781 996 5340</phone>
<email>nsb@guppylake.com</email>
</address>
</author>
<author fullname="Murray S. Kucherawy" initials="M. S." surname="Kucherawy">
<organization>Cloudmark</organization>
<address>
<postal>
<street>128 King St., 2nd Floor</street>
<city>San Francisco</city>
<region>CA</region>
<code>94107</code>
<country>USA</country>
</postal>
<phone>+1 415 946 3800</phone>
<email>msk@cloudmark.com</email>
</address>
</author>
<date year="2011" />
<area>Applications</area>
<workgroup>REPUTE Working Group</workgroup>
<keyword>reputation</keyword>
<keyword>domain</keyword>
<keyword>security</keyword>
<keyword>messaging</keyword>
<keyword>dkim</keyword>
<keyword>spf</keyword>
<keyword>authentication</keyword>
<abstract>
<t> This document defines a media type for exchanging reputation
information about an arbitrary class of object. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> This memo defines a media type for use when answering a reputation query
using the "long form" query defined in RFCxxxx+4, which uses
<xref target="HTTP"/>. It is part of a series defining the overall
reputation query/response structure as well as the concept of
reputation "vocabularies" for particular applications. </t>
<t> Also included is the specification for an IANA registry to contain
definitions and symbolic names for known reputation vocabularies. </t>
</section> <!-- Introduction -->
<section title="Terminology and Definitions" anchor="terms_and_defs">
<t>This section defines terms used in the rest of the document.</t>
<section title="Keywords" anchor="defs_keywords">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
<xref target="KEYWORDS"/>.</t>
</section> <!-- Keywords -->
<section title="Other Definitions" anchor="defs_other">
<t> Other terms of importance in this memo are defined in RFCxxxx, the
base memo in this document series. </t>
</section> <!-- Vocabulary -->
</section> <!-- Terminology and Definitions -->
<section title="Description" anchor="descr">
<t> A new media type, "application/reputon", is defined for the
representation of reputational data. This media type has two optional
parameters: "app", which conveys the specific application of reputation
data in use, and usually extends the set of data values that MAY be
included in the media object itself; and "format", which specifies
the format with which the content are relayed. </t>
<t> The default for "format" is "text", which is defined here.
Reputons bearing unrecognized format values MUST be ignored. </t>
<t> The body of the media type consists of <xref target="MAIL"/>-style
attribute/value pairs. The following are REQUIRED for all applications:
<list style="hanging">
<t hangText="RATER:"> The identity of the entity providing the
reputation information, generally expressed as a DNS domain
name. </t>
<t hangText="ASSERTION:"> A keyword indicating the specific assertion
or claim being rated. In the absence of an "app" parameter,
the reputon can only indicate generic goodness, with the
default assertion "IS-GOOD," but each application is expected
to define additional types of ASSERTION. </t>
<t hangText="RATED:"> The identity of the entity being rated. </t>
<t hangText="RATING:"> The overall rating score for that entity,
expressed as a floating-point number between 0.0 and 1.0
inclusive. See <xref target="scores"/> for discussion. </t>
</list> </t>
<t> The following are OPTIONAL for all applications, to be used in contexts
where they are appropriate:
<list style="hanging">
<t hangText="CONFIDENCE:"> The level of confidence the reputation
provider has in the value presented being accurate, expressed
as a floating-point number between 0 and 1 inclusive. </t>
<t hangText="RATER-AUTHENTICITY:"> The level of confidence in that
identity being genuine, expressed as a floating-point
number between 0 and 1 inclusive. </t>
<t hangText="SAMPLE-SIZE:"> The number of data points used to compute
that score, possibly an approximation. Expressed as an
unsigned 64-bit integer. The units are deliberately not
specified, since not all reputation service providers will
collect data the same way. Consumers will need to determine
out-of-band the units being reported and apply this value
accordingly within their local policies. </t>
</list> </t>
<t> A particular application that registers itself with IANA MAY also define
extension attribute/value pairs beyond these standard ones. </t>
<t> Thus, the following example:
<figure><artwork>
Content-type: application/reputon
RATER: RatingsRUs.example.com
RATER-AUTHENTICITY: 1.0
ASSERTION: IS-GOOD
RATED: Alex Rodriguez
RATING: 0.99
SAMPLE-SIZE: 50000
</artwork></figure> </t>
<t> ...indicates that we are absolutely sure (1.0) that the entity
"RatingsRUs.example.com" consolidated 50000 data points (perhaps from
everyone in Yankee Stadium) and concluded that Alex Rodriguez is
very very good (0.99) at something. It doesn't tell us what he's
good at, and while it might be playing baseball, it could just as
well be paying his taxes on time. </t>
<t> A more sophisticated usage would define a baseball application with a
vocabulary of specific assertions, so that this example:
<figure><artwork>
Content-type: application/reputon; app="baseball"
RATER: baseball-reference.example.com
RATER-AUTHENTICITY: 1.0
ASSERTION: HITS-FOR-POWER
RATED: Alex Rodriguez
RATING: 0.99
SAMPLE-SIZE: 50000
</artwork></figure> </t>
<t> ...would indicate that 50000 fans polled by the entity
baseball-reference.example.com rate A-Rod very highly in hitting for
power, whereas this example:
<figure><artwork>
Content-type: application/reputon; app="baseball"
RATER: baseball-reference.example.com
RATER-AUTHENTICITY: 1.0
ASSERTION: CLUTCH-HITTER
RATED: Alex Rodriguez
RATING: 0.4
SAMPLE-SIZE: 50000
</artwork></figure> </t>
<t> ...would indicate that a similar poll indicated a somewhat weaker
consensus that A-Rod tends to choke in critical baseball situations. </t>
<t> In practice, most usage of reputons is expected to make use of the
"app" parameter to target an application-specific set of assertions. </t>
<section title="Formal Definition" anchor="abnf">
<t> More formally, using <xref target="ABNF"/>, the content of the
application/reputon MIME object MUST conform to the following syntax:
<figure><artwork>
reputon := rater rater-auth assertion *extension
rated rating sampsize
rater := "RATER:"
*WSP (atom / quoted-string) [CFWS] CRLF
rater-auth := "RATER-AUTHENTICITY:"
*WSP 1*DIGIT "." 1*DIGIT [CFWS] CRLF
; must be a number between -1 and 1 inclusive
assertion := "ASSERTION:"
*WSP dot-atom-text [CFWS] CRLF
extension := dot-atom-text %x3A *WSP dot-atom-text [CFWS] CRLF
; must be registered with IANA within a reputation
; vocabulary registration
rated := "RATED:"
*WSP (atom / quoted-string) [CFWS] CRLF
rating := "RATING:"
*WSP 1*DIGIT "." 1*DIGIT [CFWS] CRLF
; must be a number between 0 and 1 inclusive
sampsize := "SAMPLE-SIZE":
*WSP 1*DIGIT [CFWS] CRLF
; must be an unsigned 64-bit integer
</artwork></figure></t>
<t> "atom", "quoted-string" and "dot-atom-text" are imported from
<xref target="MAIL"/>. </t>
</section> <!-- ABNF -->
</section> <!-- Description -->
<section title="Scores" anchor="scores">
<t> The score presented as the value in the RATING parameter appears as a
floating point value between 0.0 and 1.0 inclusive. The intent is that
the definition of an assertion within an application will declare what
the anchor values 0.0 and 1.0 specifically mean. Generally speaking,
1.0 implies full agreement with the assertion, while 0.0 indicates no
support for the assertion. </t>
<t> The definition will also specify the type of scale in use when
generating scores, to which all reputation service providers for that
application space must adhere. This will allow a client to change
which reputation service provider is being queried for a given
without having to learn through some out-of-band method what the new
provider's values mean. For example, a registration might state that
ratings are linear, which would mean a score of "x" is twice as strong
as a value of "x/2". </t>
</section> <!-- Scores -->
<section title="IANA Considerations" anchor="iana_considerations">
<t> This memo presents two actions for IANA, namely the creation of the new
media type "application/reputon" and the creation of a registry
for reputation application types. Another memo in this series creates
an initial registry entry for the latter. </t>
<section title="application/reputon Media Type Registration"
anchor="iana_media">
<t> This section provides the media type registration application from
<xref target="MIME-REG"/> for processing by IANA:
<list style="hanging">
<t hangText="To:"> ietf-types@iana.org </t>
<t hangText="Subject:"> Registration of media
type application/reputon </t>
<t hangText="Type name:"> application </t>
<t hangText="Subtype name:"> reputon </t>
<t hangText="Required parameters:"> none </t>
<t hangText="Optional parameters:">
<list style="hanging">
<t hangText="app:"> Names the reputation application
in use within the reputon, which
defines the valid assertions and
any extensions that may also be
valid (i.e., the vocabulary)
for that application. These
MUST be registered with IANA. </t>
<t hangText="format:"> Describes the format of the
content of the MIME object.
The default is "text" which
is defined in this memo. </t>
</list> </t>
<t hangText="Encoding considerations:">
"7bit" encoding is sufficient and MUST be
used to maintain readability when viewed by
non-MIME mail readers. </t>
<t hangText="Security considerations:">
See <xref target="sec_considerations"/> of
[this document]. </t>
<t hangText="Interoperability considerations:">
Implementers MUST ignore any "app" values,
attribute/value pairs, or vocabulary items
they do not support. </t>
<t hangText="Published specification:">
[this document] </t>
<t hangText="Applications that use this media type:">
Any application that wishes to query a service
that provides reputation data using the "long form"
defined in RFCxxxx. The example application
is one that provides reputation expressions about
DNS domain names found in email messages. </t>
<t hangText="Additional information:"> The value of the
"app" parameter MUST also be registered with IANA. </t>
<t hangText="Person and email address to contact for further information:">
<list style="empty">
<t> Nathaniel Borenstein <nps@guppylake.com> </t>
<t> Murray S. Kucherawy <msk@cloudmark.com> </t>
</list> </t>
<t hangText="Intended usage:"> COMMON </t>
<t hangText="Author:">
<list style="empty">
<t> Nathaniel Borenstein </t>
<t> Murray S. Kucherawy </t>
</list> </t>
<t hangText="Change controller:"> IESG </t>
</list> </t>
</section> <!-- application/reputon Media Type Registration -->
<section title="Reputation Applications Registry" anchor="iana_registry">
<t> IANA is requested to create the "Reputation Applications" registry.
This registry will contain names of applications used with the
application/reputon media type, as defined by this memo. </t>
<t> New registrations or updates MUST be published in accordance with the
"Specification Required" guidelines as described in
<xref target="IANA-CONSIDERATIONS"/>. </t>
<t> New registrations and updates MUST contain the following information:
<list style="numbers">
<t> Name of the application being registered or updated </t>
<t> Short description of the application (i.e., the class
of entity about which it reports reputation data) </t>
<t> The document in which the application is defined </t>
<t> New or updated status, which MUST be one of:
<list style="hanging">
<t hangText="current:"> The application is in
current use </t>
<t hangText="deprecated:"> The application is in
current use but its use is discouraged </t>
<t hangText="historic:"> The application is no
longer in current use </t>
</list> </t>
<t> An optional table of query parameters that are specific
to this application; each table entry must include:
<list style="hanging">
<t hangText="Name:"> Name of the query parameter </t>
<t hangText="Status:"> (as above) </t>
<t hangText="Description:"> A short description
of the purpose of this parameter </t>
<t hangText="Syntax:"> A reference to a description
of valid syntax for the parameter's value </t>
<t hangText="Required:"> "yes" if the parameter is
mandatory, "no" otherwise </t>
</list> </t>
</list> </t>
<t> A document creating a reputation application MUST include:
<list style="numbers">
<t> A list of one or more assertions registered within this
application; each table entry must include:
<list style="hanging">
<t hangText="Name:"> Name of the assertion </t>
<t hangText="Description:"> A short description
of the assertion, with specific meanings for
values of 0.0 and 1.0 </t>
<t hangText="Scale:"> A short description
of the scale used in computing the value
(see <xref target="scores"/> of this memo) </t>
</list> </t>
</list> </t>
</section> <!-- Reputation Application Registry -->
</section> <!-- IANA Considerations -->
<section title="Security Considerations" anchor="sec_considerations">
<t> This memo describes security considerations introduced by the media
type defined here. </t>
<t> [TBD] </t>
</section> <!-- Security Considerations -->
</middle>
<back>
<references title="Normative References">
<reference anchor="ABNF">
<front>
<title> Augmented BNF for Syntax
Specifications: ABNF </title>
<author initials="D." surname="Crocker"
fullname="D. Crocker">
<organization>
Brandenburg InternetWorking
</organization>
</author>
<author initials="P." surname="Overell"
fullname="P. Overell">
<organization>
THUS plc.
</organization>
</author>
<date month="January" year="2008" />
</front>
<seriesInfo name="RFC" value="5234" />
</reference>
</references>
<references title="Informative References">
<reference anchor="HTTP">
<front>
<title> Hypertext Transfer Protocol --
HTTP/1.1 </title>
<author initials="R." surname="Fielding"
fullname="R. Fielding">
<organization>
UC Irvine
</organization>
</author>
<author initials="J." surname="Gettys"
fullname="J. Gettys">
<organization>
Compaq/W3C
</organization>
</author>
<author initials="J." surname="Mogul"
fullname="J. Mogul">
<organization>
Compaq
</organization>
</author>
<author initials="H." surname="Frystyk"
fullname="H. Frystyk">
<organization>
W3C/MIT
</organization>
</author>
<author initials="L." surname="Masinter"
fullname="L. Masinter">
<organization>
Xerox
</organization>
</author>
<author initials="P." surname="Leach"
fullname="P. Leach">
<organization>
Microsoft
</organization>
</author>
<author initials="T." surname="Berners-Lee"
fullname="T. Berners-Lee">
<organization>
W3C/MIT
</organization>
</author>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2616"/>
</reference>
<reference anchor="IANA-CONSIDERATIONS">
<front>
<title> Guidelines for Writing an IANA
Considerations Section in RFCs </title>
<author initials="T." surname="Narten"
fullname="T. Narten">
<organization>
IBM
</organization>
</author>
<author initials="H." surname="Alvestrand"
fullname="H. Alvestrand">
<organization>
Google
</organization>
</author>
<date month="May" year="2008" />
</front>
<seriesInfo name="RFC" value="5226" />
</reference>
<reference anchor="KEYWORDS">
<front>
<title abbrev="RFC Key Words">Key words for
use in RFCs to Indicate Requirement
Levels</title>
<author initials="S." surname="Bradner"
fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date year="1997" month="March"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="MAIL">
<front>
<title> Internet Message Format </title>
<author initials="P." surname="Resnick"
fullname="P. Resnick" role="editor">
<organization>
Qualcomm, Inc.
</organization>
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="RFC" value="5322" />
</reference>
<reference anchor="MIME-REG">
<front>
<title> Media Type Specifications and
Registration Procedures </title>
<author initials="N." surname="Freed"
fullname="N. Freed">
<organization>
Sun Microsystems
</organization>
</author>
<author initials="J." surname="Klensin"
fullname="J. Klensin">
<organization/>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4288" />
</reference>
</references>
<section title="Acknowledgments" anchor="acks">
<t> The authors wish to acknowledge the contributions of the following to
this specification:
Frank Ellermann,
Tony Hansen,
Jeff Hodges,
John Levine,
and
David F. Skoll. </t>
</section>
<section title="Public Discussion" anchor="public">
<t> Public discussion of this suite of memos takes place on the
domainrep@ietf.org mailing list. See
https://www.ietf.org/mailman/listinfo/domainrep. </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:28:22 |