draft-ietf-repute-media-type-00.txt   draft-ietf-repute-media-type-01.txt 
REPUTE Working Group N. Borenstein REPUTE Working Group N. Borenstein
Internet-Draft Mimecast Internet-Draft Mimecast
Intended status: Standards Track M. Kucherawy Intended status: Standards Track M. Kucherawy
Expires: May 22, 2012 Cloudmark Expires: July 16, 2012 Cloudmark
November 19, 2011 January 13, 2012
A Media Type for Reputation Interchange A Media Type for Reputation Interchange
draft-ietf-repute-media-type-00 draft-ietf-repute-media-type-01
Abstract Abstract
This document defines a media type for exchanging reputation This document defines a media type for exchanging reputation
information about an arbitrary class of object. information about an arbitrary class of object.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 22, 2012. This Internet-Draft will expire on July 16, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3
2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Other Definitions . . . . . . . . . . . . . . . . . . . . 3 2.2. Other Definitions . . . . . . . . . . . . . . . . . . . . 3
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Formal Definition . . . . . . . . . . . . . . . . . . . . 5 3.1. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Scores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Example Reply . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Scores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. application/reputon Media Type Registration . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.2. Reputation Applications Registry . . . . . . . . . . . . . 8 5.1. application/reputon Media Type Registration . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.2. Reputation Applications Registry . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This memo defines a media type for use when answering a reputation This memo defines a media type for use when answering a reputation
query using the "long form" query defined in RFCxxxx+4, which uses query using the "long form" query defined in [I-D.REPUTE-QUERY-HTTP],
[HTTP]. It is part of a series defining the overall reputation which uses [HTTP]. It is part of a series defining the overall
query/response structure as well as the concept of reputation reputation query/response structure as well as the concept of
"vocabularies" for particular applications. reputation "vocabularies" for particular applications.
Also included is the specification for an IANA registry to contain Also included is the specification for an IANA registry to contain
definitions and symbolic names for known reputation vocabularies. definitions and symbolic names for known reputation vocabularies.
2. Terminology and Definitions 2. Terminology and Definitions
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
2.1. Keywords 2.1. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
2.2. Other Definitions 2.2. Other Definitions
Other terms of importance in this memo are defined in RFCxxxx, the Other terms of importance in this memo are defined in
base memo in this document series. [I-D.REPUTE-MODEL], the base memo in this document series.
3. Description 3. Description
A new media type, "application/reputon", is defined for the A new media type, "application/reputon", is defined for the
representation of reputational data. This media type has two representation of reputational data, typically in response to a
optional parameters: "app", which conveys the specific application of client making a request for such data about some subject. This media
reputation data in use, and usually extends the set of data values type has one optional parameter, "app", which conveys the specific
that MAY be included in the media object itself; and "format", which application of reputation data in use, and may extend the set of data
specifies the format with which the content are relayed. values that can be included in the media object itself.
The default for "format" is "text", which is defined here. Reputons The body of the media type consists of an Extended Markup Language
bearing unrecognized format values MUST be ignored. (XML) document that contains the reputation information requested.
An XML schema is included in a later section of this document.
The body of the media type consists of [MAIL]-style attribute/value The key pieces of data found in a reputon for all reputation
pairs. The following are REQUIRED for all applications: applications are defined as follows:
RATER: The identity of the entity providing the reputation RATER: The identity of the entity providing the reputation
information, generally expressed as a DNS domain name. information, generally expressed as a DNS domain name.
ASSERTION: A keyword indicating the specific assertion or claim ASSERTION: A keyword indicating the specific assertion or claim
being rated. In the absence of an "app" parameter, the reputon being rated. In the absence of an "app" parameter, the reputon
can only indicate generic goodness, with the default assertion can only indicate generic goodness, with the default assertion
"IS-GOOD," but each application is expected to define additional "IS-GOOD," but each application is expected to define additional
types of ASSERTION. ASSERTIONs.
RATED: The identity of the entity being rated. RATED: The identity of the entity being rated.
RATING: The overall rating score for that entity, expressed as a RATING: The overall rating score for that entity, expressed as a
floating-point number between 0.0 and 1.0 inclusive. See floating-point number between 0.0 and 1.0 inclusive. See
Section 4 for discussion. Section 4 for discussion.
The following are OPTIONAL for all applications, to be used in The following are OPTIONAL for all applications, to be used in
contexts where they are appropriate: contexts where they are appropriate:
CONFIDENCE: The level of confidence the reputation provider has in CONFIDENCE: The level of confidence the reputation provider has in
the value presented being accurate, expressed as a floating-point the value presented being accurate, expressed as a floating-point
number between 0 and 1 inclusive. number between 0.0 and 1.0 inclusive.
EXTENSION: Contains application-specific extension data. It MUST
NOT be present unless the reputon was introduced using the "app"
parameter to identify a specific reputation application. Valid
values are established by registration of application-specific
extensions with IANA (see Section 5.2).
RATER-AUTHENTICITY: The level of confidence in that identity being RATER-AUTHENTICITY: The level of confidence in that identity being
genuine, expressed as a floating-point number between 0 and 1 genuine, expressed as a floating-point number between 0.0 and 1.0
inclusive. inclusive.
SAMPLE-SIZE: The number of data points used to compute that score, SAMPLE-SIZE: The number of data points used to compute that score,
possibly an approximation. Expressed as an unsigned 64-bit possibly an approximation. Expressed as an unsigned 64-bit
integer. The units are deliberately not specified, since not all integer. The units are deliberately not specified, since not all
reputation service providers will collect data the same way. reputation service providers will collect data the same way.
Consumers will need to determine out-of-band the units being Consumers will need to determine out-of-band the units being
reported and apply this value accordingly within their local reported and apply this value accordingly within their local
policies. policies.
UPDATED: A timestamp indicating when this value was generated.
Expressed as the number of seconds since January 1, 1970 00:00
UTC.
A particular application that registers itself with IANA MAY also A particular application that registers itself with IANA MAY also
define extension attribute/value pairs beyond these standard ones. define extension attribute/value pairs beyond these standard ones.
Thus, the following example: Thus, the following simple example (using simple text rather than XML
for brevity):
Content-type: application/reputon Content-type: application/reputon
RATER: RatingsRUs.example.com RATER: RatingsRUs.example.com
RATER-AUTHENTICITY: 1.0 RATER-AUTHENTICITY: 1.0
ASSERTION: IS-GOOD ASSERTION: IS-GOOD
RATED: Alex Rodriguez RATED: Alex Rodriguez
RATING: 0.99 RATING: 0.99
SAMPLE-SIZE: 50000 SAMPLE-SIZE: 50000
...indicates that we are absolutely sure (1.0) that the entity ...indicates we are absolutely sure (1.0) that the entity
"RatingsRUs.example.com" consolidated 50000 data points (perhaps from "RatingsRUs.example.com" consolidated 50000 data points (perhaps from
everyone in Yankee Stadium) and concluded that Alex Rodriguez is very 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, 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 and while it might be playing baseball, it could just as well be
paying his taxes on time. paying his taxes on time.
A more sophisticated usage would define a baseball application with a A more sophisticated usage would define a baseball application with a
vocabulary of specific assertions, so that this example: vocabulary of specific assertions, so that this example:
Content-type: application/reputon; app="baseball" Content-type: application/reputon; app="baseball"
skipping to change at page 5, line 39 skipping to change at page 6, line 5
RATED: Alex Rodriguez RATED: Alex Rodriguez
RATING: 0.4 RATING: 0.4
SAMPLE-SIZE: 50000 SAMPLE-SIZE: 50000
...would indicate that a similar poll indicated a somewhat weaker ...would indicate that a similar poll indicated a somewhat weaker
consensus that A-Rod tends to choke in critical baseball situations. consensus that A-Rod tends to choke in critical baseball situations.
In practice, most usage of reputons is expected to make use of the In practice, most usage of reputons is expected to make use of the
"app" parameter to target an application-specific set of assertions. "app" parameter to target an application-specific set of assertions.
3.1. Formal Definition 3.1. XML Schema
More formally, using [ABNF], the content of the application/reputon The following XML schema describes the format of the reply:
MIME object MUST conform to the following syntax:
reputon := rater rater-auth assertion *extension <?xml version="1.0" encoding="ISO-8859-1" ?%gt;
rated rating sampsize <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
rater := "RATER:" <!-- definition of local types -->
*WSP (atom / quoted-string) [CFWS] CRLF <xs:simpleType name="exttype">
<xs:restriction base="xs:token">
<xs:pattern value="\w+(-\w*)*:\s?[\w\p{P}]+"/>
<xs:/restriction>
<xs:/simpleType>
rater-auth := "RATER-AUTHENTICITY:" <!-- definition of simple elements -->
*WSP 1*DIGIT "." 1*DIGIT [CFWS] CRLF <xs:element name="rater" type="xs:token"/>
; must be a number between -1 and 1 inclusive <xs:element name="rater-authenticity" type="xs:decimal"/>
<xs:element name="assertion" type="xs:token"/>
<xs:element name="extension" type="exttype"/>
<xs:element name="rated" type="xs:token"/>
<xs:element name="rating" type="xs:decimal"/>
<xs:element name="confidence" type="xs:decimal"/>
<xs:element name="sample-size" type="xs:positiveInteger"/>
<xs:element name="updated" type="xs:positiveInteger"/>
assertion := "ASSERTION:" <!-- definition of complex elements -->
*WSP dot-atom-text [CFWS] CRLF <xs:complexType name="assertiontype">
<xs:sequence>
<xs:element ref="rater" minOccurs="1"/>
<xs:element ref="rater-authenticity" minOccurs="1"/>
<xs:element ref="assertion" minOccurs="1"/>
<xs:element ref="extension"/>
<xs:element ref="rated" minOccurs="1"/>
<xs:element ref="rating" minOccurs="1"/>
<xs:element ref="confidence" minOccurs="1"/>
<xs:element ref="sample-size" minOccurs="1"/>
<xs:element ref="updated" minOccurs="1"/>
<xs:/sequence>
<xs:/complexType>
extension := dot-atom-text %x3A *WSP dot-atom-text [CFWS] CRLF <xs:complexType name="reporttype">
; must be registered with IANA within a reputation <xs:sequence>
; vocabulary registration <xs:element name="reputon" type="assertiontype"
maxOccurs="unbounded" minOccurs="1"/>
<xs:/sequence>
<xs:/complexType>
rated := "RATED:" <xs:element name="reputation" type="reporttype"/>
*WSP (atom / quoted-string) [CFWS] CRLF
rating := "RATING:" </xs:schema>
*WSP 1*DIGIT "." 1*DIGIT [CFWS] CRLF
; must be a number between 0 and 1 inclusive
sampsize := "SAMPLE-SIZE": 3.2. Example Reply
*WSP 1*DIGIT [CFWS] CRLF
; must be an unsigned 64-bit integer
"atom", "quoted-string" and "dot-atom-text" are imported from [MAIL]. The following is an example reputon generated using this schema,
including the media type definition line:
Content-Type: application/reputon; app="email"
<?xml version="1.0" encoding="US-ASCII"?>
<reputation>
<reputon>
<rater>rep.example.net</rater>
<rater-authenticity>0.95</rater-authenticity>
<assertion>SENDS-SPAM</assertion>
<extension>IDENTITY: DKIM</extension>
<rated>example.com</rated>
<rating>0.0012</rating>
<sample-size>16938213</sample-size>
<updated>1317795852</updated>
</reputon>
</reputation>
Here, reputation agent "rep.example.net" is asserting within the
context of email that "example.com" appears to send spam 1.2% of the
time, based on just short of 17 million messages analyzed or reported
to date. The identity "example.com", the subject of the query, is
extracted from the analyzed messages using the [DKIM] "d=" parameter
for messages where signatures validate. The reputation agent is 95%
confident of this result. (See [I-D.REPUTE-EMAIL-IDENTIFIERS] for
details about the registered email identifiers vocabulary.)
4. Scores 4. Scores
The score presented as the value in the RATING parameter appears as a 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 floating point value between 0.0 and 1.0 inclusive. The intent is
that the definition of an assertion within an application will that the definition of an assertion within an application will
declare what the anchor values 0.0 and 1.0 specifically mean. declare what the anchor values 0.0 and 1.0 specifically mean.
Generally speaking, 1.0 implies full agreement with the assertion, Generally speaking, 1.0 implies full agreement with the assertion,
while 0.0 indicates no support for the assertion. while 0.0 indicates no support for the assertion.
skipping to change at page 7, line 34 skipping to change at page 8, line 37
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
app: Names the reputation application in use within the reputon, app: Names the reputation application in use within the reputon,
which defines the valid assertions and any extensions that may which defines the valid assertions and any extensions that may
also be valid (i.e., the vocabulary) for that application. also be valid (i.e., the vocabulary) for that application.
These MUST be registered with IANA. These MUST be registered with IANA.
format: Describes the format of the content of the MIME object.
The default is "text" which is defined in this memo.
Encoding considerations: "7bit" encoding is sufficient and MUST be Encoding considerations: "7bit" encoding is sufficient and MUST be
used to maintain readability when viewed by non-MIME mail readers. used to maintain readability when viewed by non-MIME mail readers.
Security considerations: See Section 6 of [this document]. Security considerations: See Section 6 of [this document].
Interoperability considerations: Implementers MUST ignore any "app" Interoperability considerations: Implementers MUST ignore any "app"
values, attribute/value pairs, or vocabulary items they do not values, attribute/value pairs, or vocabulary items they do not
support. support.
Published specification: [this document] Published specification: [this document]
skipping to change at page 7, line 47 skipping to change at page 9, line 4
Encoding considerations: "7bit" encoding is sufficient and MUST be Encoding considerations: "7bit" encoding is sufficient and MUST be
used to maintain readability when viewed by non-MIME mail readers. used to maintain readability when viewed by non-MIME mail readers.
Security considerations: See Section 6 of [this document]. Security considerations: See Section 6 of [this document].
Interoperability considerations: Implementers MUST ignore any "app" Interoperability considerations: Implementers MUST ignore any "app"
values, attribute/value pairs, or vocabulary items they do not values, attribute/value pairs, or vocabulary items they do not
support. support.
Published specification: [this document] Published specification: [this document]
Applications that use this media type: Any application that wishes Applications that use this media type: Any application that wishes
to query a service that provides reputation data using the "long to query a service that provides reputation data using the "long
form" defined in RFCxxxx. The example application is one that form" defined in [I-D.REPUTE-QUERY-HTTP]. The example application
provides reputation expressions about DNS domain names found in is one that provides reputation expressions about DNS domain names
email messages. found in email messages.
Additional information: The value of the "app" parameter MUST also Additional information: The value of the "app" parameter MUST also
be registered with IANA. be registered with IANA.
Person and email address to contact for further information: Person and email address to contact for further information:
Nathaniel Borenstein <nps@guppylake.com> Nathaniel Borenstein <nps@guppylake.com>
Murray S. Kucherawy <msk@cloudmark.com> Murray S. Kucherawy <msk@cloudmark.com>
skipping to change at page 9, line 43 skipping to change at page 11, line 4
value (see Section 4 of this memo) value (see Section 4 of this memo)
6. Security Considerations 6. Security Considerations
This memo describes security considerations introduced by the media This memo describes security considerations introduced by the media
type defined here. type defined here.
[TBD] [TBD]
7. References 7. References
7.1. Normative References 7.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [I-D.REPUTE-MODEL]
Specifications: ABNF", RFC 5234, January 2008. Borenstein, N. and M. Kucherawy, "A Model for Reputation
Interchange", I-D draft-kucherawy-reputation-model,
June 2011.
[I-D.REPUTE-QUERY-HTTP]
Borenstein, N. and M. Kucherawy, "Reputation Data
Interchange using HTTP and XML",
I-D draft-ietf-repute-query-http, November 2011.
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References 7.2. Informative References
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
September 2011.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[I-D.REPUTE-EMAIL-IDENTIFIERS]
Borenstein, N. and M. Kucherawy, "A Reputation Vocabulary
for Email Identifiers",
I-D draft-ietf-repute-email-identifiers, November 2011.
[IANA-CONSIDERATIONS] [IANA-CONSIDERATIONS]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008. IANA Considerations Section in RFCs", RFC 5226, May 2008.
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[MIME-REG] [MIME-REG]
Freed, N. and J. Klensin, "Media Type Specifications and Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", RFC 4288, December 2005. Registration Procedures", RFC 4288, December 2005.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors wish to acknowledge the contributions of the following to The authors wish to acknowledge the contributions of the following to
this specification: Frank Ellermann, Tony Hansen, Jeff Hodges, John this specification: Frank Ellermann, Tony Hansen, Jeff Hodges, John
Levine, and David F. Skoll. Levine, David F. Skoll, and Mykyta Yevstifeyev.
Appendix B. Public Discussion Appendix B. Public Discussion
Public discussion of this suite of memos takes place on the Public discussion of this suite of memos takes place on the
domainrep@ietf.org mailing list. See domainrep@ietf.org mailing list. See
https://www.ietf.org/mailman/listinfo/domainrep. https://www.ietf.org/mailman/listinfo/domainrep.
Authors' Addresses Authors' Addresses
Nathaniel Borenstein Nathaniel Borenstein
 End of changes. 36 change blocks. 
79 lines changed or deleted 147 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/