draft-ietf-repute-media-type-12.txt   draft-ietf-repute-media-type-13.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: March 11, 2014 September 7, 2013 Expires: March 19, 2014 September 15, 2013
A Media Type for Reputation Interchange A Media Type for Reputation Interchange
draft-ietf-repute-media-type-12 draft-ietf-repute-media-type-13
Abstract Abstract
This document defines the format of reputation response data This document defines the format of reputation response data
("reputons"), the media-type for packaging it, and definition of a ("reputons"), the media-type for packaging it, and definition of a
registry for the names of reputation applications and response sets. registry for the names of reputation applications and response sets.
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
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 March 11, 2014. This Internet-Draft will expire on March 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3
2.1. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Other Definitions . . . . . . . . . . . . . . . . . . . . 3 2.3. Other Definitions . . . . . . . . . . . . . . . . . . . . 3
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Reputon Attributes . . . . . . . . . . . . . . . . . . . . 4 3.1. Reputon Attributes . . . . . . . . . . . . . . . . . . . . 4
4. Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Reputon Structure . . . . . . . . . . . . . . . . . . . . . . 6 6. Reputons . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1.1. Formal Definition . . . . . . . . . . . . . . . . . . 6 6.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 6
6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2.1. Imported JSON Terms . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6.2.2. Reputon Structure . . . . . . . . . . . . . . . . . . 7
7.1. application/reputon+json Media Type Registration . . . . . 10 6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Reputation Applications Registry . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.1. application/reputons+json Media Type Registration . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Reputation Applications Registry . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16
Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document defines a media type for use when answering a This document defines a data object for use when answering a
reputation query via the query method described in reputation query. It also defines a media type to carry the response
[I-D.REPUTE-QUERY-HTTP], which uses [HTTP]. set data when using a transport method that follows the media type
framework, such as the HyperText Transfer Protocol (HTTP) based query
method defined in [I-D.REPUTE-QUERY-HTTP]. Any future query methods
that might be developed are expected to use the same data object.
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 applications and definitions and symbolic names for known reputation applications and
corresponding response sets. corresponding response sets.
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. Reputon 2.1. Reputon
skipping to change at page 3, line 41 skipping to change at page 3, line 44
2.3. Other Definitions 2.3. Other Definitions
Other terms of importance in this document are defined in Other terms of importance in this document are defined in
[I-D.REPUTE-MODEL], the base document in this document series. [I-D.REPUTE-MODEL], the base document in this document series.
3. Description 3. Description
The meta-format selected for the representation of a reputon is The meta-format selected for the representation of a reputon is
JavaScript Object Notation (JSON), defined in [JSON]. Accordingly, a JavaScript Object Notation (JSON), defined in [JSON]. Accordingly, a
new media type, "application/reputon+json", is defined for the JSON new media type, "application/reputons+json", is defined for the JSON
representation of reputational data, typically in response to a representation of reputational data, typically in response to a
client making a request for such data about some subject. This media client making a request for such data about some subject. This media
type has one optional parameter, "context", which names the semantic type takes no parameters.
context (i.e., the specific sphere of reputation evaluation, or
application) in which the query is made and the response returned.
If the parameter is absent, a generic reputation query (i.e., one not
associated with a specific reputation application) is assumed for
which only a simple reply is allowed.
The body of the media type consists of a JSON document that contains The body of the media type consists of a JSON document that contains
the reputation information requested. A detailed description of the the reputation information requested. A detailed description of the
expected structure of the reply is provided below. expected structure of the reply is provided below.
The media type comprises a single member indicating the name of the
application context (see Section 5.1 of [I-D.REPUTE-MODEL] in which
the reputational data are being returned. The application name
refers to a registration as described in Section 7.2, which defines
the valid assertions and any extensions that might also be valid
(i.e., the response set) for that application.
3.1. Reputon Attributes 3.1. Reputon Attributes
The key pieces of data found in a reputon for all reputation The key pieces of data found in a reputon for all reputation
applications are defined as follows: applications are defined as follows:
rater: The identity of the entity aggregating, computing, and rater: The identity of the entity aggregating, computing, and
providing the reputation information, typically expressed as a DNS providing the reputation information, typically expressed as a DNS
domain name. 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 a "context" parameter on the media being rated.
type, the reputon can only indicate generic goodness, with the
default assertion "is-good", but each application is expected to
define additional assertions.
rated: The identity of the entity being rated. The nature of this rated: The identity of the entity being rated. The nature of this
field is application-specific; it could be domain names, email field is application-specific; it could be domain names, email
addresses, driver's license numbers, or anything that uniquely addresses, driver's license numbers, or anything that uniquely
identifies the entity being rated. Documents that define specific identifies the entity being rated. Documents that define specific
reputation applications are required to define syntax and reputation applications are required to define syntax and
semantics for this field. semantics for this field.
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
skipping to change at page 5, line 39 skipping to change at page 5, line 41
The score presented as the value in the rating attribute appears as a The score presented as the value in the rating attribute 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.
The definition will also specify the type of scale in use when The definition will also specify the type of scale in use when
generating scores, to which all reputation service providers for that generating scores, to which all reputation service providers for that
application space must adhere. This will allow a client to change application space must adhere. Further discussion can be found in
which reputation service provider is being queried without having to [I-D.REPUTE-MODEL].
learn through some out-of-band method what the new provider's ratings
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". It also allows easier aggregation of ratings collected
from multiple reputation service providers.
5. Caching 5. Caching
A reputon can contain an "expires" field indicating a timestamp after A reputon can contain an "expires" field indicating a timestamp after
which the client SHOULD NOT use the rating it contains, and SHOULD which the client SHOULD NOT use the rating it contains, and SHOULD
issue a new query. issue a new query.
This specification does not mandate any caching of ratings on the This specification does not mandate any caching of ratings on the
part of the client, but there are obvious operational benefits to part of the client, but there are obvious operational benefits to
doing so. In the context of reputation, a cached (and hence, stale) doing so. In the context of reputation, a cached (and hence, stale)
rating can cause desirable traffic to be identified as undesirable, rating can cause desirable traffic to be identified as undesirable,
or vice-versa. or vice-versa.
Reputation data is typically most volatile when the subject of the Reputation data is typically most volatile when the subject of the
reputation is young. Accordingly, if a service chooses to include reputation is young. Accordingly, if a service chooses to include
expiration timestamps as part a reply, these values SHOULD be lower expiration timestamps as part a reply, these values SHOULD be lower
for subjects about which little data has been collected. for subjects about which little data has been collected.
6. Reputon Structure 6. Reputons
6.1. Syntax 6.1. Syntax
A reputon expressed in JSON consists of an object that itself A reputon expressed in JSON is a set of key-value pairs, where the
contains zero or more objects whose names are "reputon". Each keys are the names of particular attributes that comprise a reputon
reputon object is a set of key-value pairs, where the keys are the (as listed above, or as provided with specific applications), and
names of particular attributes that comprise a reputon (as listed values are the content associated with those keys. The set of keys
above, or as provided with specific applications), and values are the that make up a reputon within a given application are known as that
content associated with those keys. The set of keys that make up a application's "response set".
reputon within a given application are known as that application's
"response set".
A reputon object typically contains a reply corresponding to the A reputon object typically contains a reply corresponding to the
assertion for which a client made a specific request. For example, a assertion for which a client made a specific request. For example, a
client asking for assertion "sends-spam" about domain "example.com" client asking for assertion "sends-spam" about domain "example.com"
would expect a reply consisting of a reputon making a "sends-spam" would expect a reply consisting of a reputon making a "sends-spam"
assertion about "example.com" and nothing more. If a client makes a assertion about "example.com" and nothing more. If a client makes a
request about a subject but does not specify an assertion of request about a subject but does not specify an assertion of
interest, the server can return reputons about any assertion for interest, the server can return reputons about any assertion for
which it has data; in effect, the client has asked for any available which it has data; in effect, the client has asked for any available
information about the subject. A client that receives an irrelevant information about the subject. A client that receives an irrelevant
reputon simply ignores it. reputon simply ignores it.
An empty reputon is an acknowledgement by the server that the request An empty reputon is an acknowledgement by the server that the request
has been received, and serves as a positive indication that the has been received, and serves as a positive indication that the
server does not have the information requested. This is semantically server does not have the information requested. This is semantically
equivalent to returning a reputon with a "sample-size" of zero. equivalent to returning a reputon with a "sample-size" of zero.
6.1.1. Formal Definition 6.2. Formal Definition
Using [ABNF], the syntax of a reputon is: [JSON] defines the structure of JSON objects and arrays using a set
of primitive elements. Those elements will be used to describe the
JSON structure of a reputation object.
reputon = "{" [ reputon-object 6.2.1. Imported JSON Terms
*(value-separator reputon-object) ] "}"
reputon-object = "reputon" name-separator response-set OBJECT: a JSON object, defined in Section 2.2 of [JSON]
response-set = "{" reputon-element MEMBER: a member of a JSON object, defined in Section 2.2 of [JSON]
*(value-separator reputon-element) "}
reputon-element = rater-value / assertion-value / rated-value MEMBER-NAME: the name of a MEMBER, defined as a "string" in Section
/ rating-value / conf-value / normal-value 2.2 of [JSON]
/ sample-value / gen-value / expire-value
/ ext-value
; these can appear in any order, but MUST appear at most
; once each
rater-value = %x22 "rater" %x22 name-separator string MEMBER-VALUE: the value of a MEMBER, defined as a "value" in Section
2.2 of [JSON]
assertion-value = %x22 "assertion" %x22 name-separator string ARRAY: an array, defined in Section 2.3 of [JSON]
rated-value = %x22 "rated" %x22 name-separator string ARRAY-VALUE: an element of an ARRAY, defined in Section 2.3 of
[JSON]
rating-value = %x22 "rating" %x22 name-separator number NUMBER: a "number" as defined in Section 2.4 of [JSON]
; "number" MUST be between 0.0 and 1.0 inclusive
conf-value = %x22 "confidence" %x22 name-separator number INTEGER: an "integer" as defined in Section 2.4 of [JSON]
; "number" MUST be between 0.0 and 1.0 inclusive
normal-value = %x22 "normal-rating" %x22 name-separator number STRING: an "string" as defined in Section 2.5 of [JSON]
; "number" MUST be between 0.0 and 1.0 inclusive
sample-value = %x22 "sample-size" %x22 name-separator int 6.2.2. Reputon Structure
; "int" MUST NOT be negative
gen-value = %x22 "generated" %x22 name-separator int Using the above terms for the JSON structures, the syntax of a
; "int" MUST NOT be negative reputation object is defined as follows:
expire-value = %x22 "expires" %x22 name-separator int reputation-object: an OBJECT containing a MEMBER reputation-context
; "int" MUST NOT be negative and a MEMBER reputon-list
ext-value = member reputation-context: a MEMBER with MEMBER-NAME "application" and
; specific syntax is defined in separate application MEMBER-VALUE a STRING (see Section 3)
; registrations
The tokens "value-separator", "name-separator", "string", "int", and reputon-list: a MEMBER with MEMBER-NAME "reputons" and MEMBER-VALUE
"member" are defined in [JSON]. a reputon-array
6.2. Examples reputon-array: an ARRAY, where each ARRAY-VALUE is a reputon
reputon: an OBJECT, where each MEMBER is a reputon-element
reputon-element: one of the following, defined below: rater-value,
assertion-value, rated-value, rating-value, conf-value, normal-
value, sample-value, gen-value, expire-value, ext-value; note the
following:
* The order of reputon-element members is not significant.
* A specific reputon-element MUST NOT appear more than once.
* rater-value, assertion-value, rated-value, and rating-value are
REQUIRED.
rater-value: a MEMBER with MEMBER-NAME "rater" and MEMBER-VALUE a
STRING (see "rater" in Section 3.1)
assertion-value: a MEMBER with MEMBER-NAME "assertion" and MEMBER-
VALUE a STRING (see "assertion" in Section 3.1)
rated-value: a MEMBER with MEMBER-NAME "rated" and MEMBER-VALUE a
STRING (see "rated" in Section 3.1)
rating-value: a MEMBER with MEMBER-NAME "rating" and MEMBER-VALUE a
NUMBER between 0.0 and 1.0 inclusive (see "rating" in
Section 3.1); the number SHOULD NOT not have more than three
decimal places of precision
conf-value: a MEMBER with MEMBER-NAME "confidence" and MEMBER-VALUE
a NUMBER between 0.0 and 1.0 inclusive (see "confidence" in
Section 3.1); the number SHOULD NOT not have more than three
decimal places of precision
normal-value: a MEMBER with MEMBER-NAME "normal-rating" and MEMBER-
VALUE a NUMBER between 0.0 and 1.0 inclusive (see "normal" in
Section 3.1); the number SHOULD NOT not have more than three
decimal places of precision
sample-value: a MEMBER with MEMBER-NAME "sample-size" and MEMBER-
VALUE a non-negative INTEGER (see "sample-size" in "normal" in
Section 3.1)
gen-value: a MEMBER with MEMBER-NAME "generated" and MEMBER-VALUE a
non-negative INTEGER (see "generated" in Section 3.1)
expire-value: a MEMBER with MEMBER-NAME "expires" and MEMBER-VALUE a
non-negative INTEGER (see "expires" in Section 3.1)
ext-value: a MEMBER, for extension purposes; MEMBER-NAME and MEMBER-
VALUE will be defined in separate application registrations
6.3. Examples
The following simple example: The following simple example:
Content-type: application/reputon+json Content-Type: application/reputons+json
{ {
"reputon": "application": "baseball",
{ "reputons": [
"rater": "RatingsRUs.example.com", {
"assertion": "is-good", "rater": "RatingsRUs.example.com",
"rated": "Alex Rodriguez", "assertion": "is-good",
"rating": 0.99, "rated": "Alex Rodriguez",
"sample-size": 50000 "rating": 0.99,
} "sample-size": 50000
}
]
} }
...indicates to the client that "RatingsRUs.example.com" consolidated ...indicates to the client that "RatingsRUs.example.com" consolidated
50000 data points (perhaps from everyone in Yankee Stadium) and 50000 data points (perhaps from everyone in Yankee Stadium) and
concluded that Alex Rodriguez is very very good (0.99) at something. 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 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. baseball, it could just as well be 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
response set of specific assertions, so that this example: response set of specific assertions, so that this example:
Content-type: application/reputon+json; context="baseball" Content-Type: application/reputons+json
{ {
"reputon": "application": "baseball",
{ "reputons:" [
"rater": "baseball-reference.example.com", {
"assertion": "hits-for-power", "rater": "baseball-reference.example.com",
"rated": "Alex Rodriguez", "assertion": "hits-for-power",
"rating": 0.99, "rated": "Alex Rodriguez",
"sample-size": 50000 "rating": 0.99,
} "sample-size": 50000
}
]
} }
...would indicate that 50000 fans polled by the entity baseball- ...would indicate that 50000 fans polled by the entity baseball-
reference.example.com rate Alex Rodriguez very highly in hitting for reference.example.com rate Alex Rodriguez very highly in hitting for
power, whereas this example: power, whereas this example:
Content-type: application/reputon+json; context="baseball" Content-Type: application/reputons+json
{ {
"reputon": "application": "baseball",
{ "reputons": [
"rater": "baseball-reference.example.com", {
"assertion": "clutch-hitter", "rater": "baseball-reference.example.com",
"rated": "Alex Rodriguez", "assertion": "strong-hitter",
"rating": 0.4, "rated": "Alex Rodriguez",
"confidence": 0.2, "rating": 0.4,
"sample-size": 50000 "confidence": 0.2,
} "sample-size": 50000
}
]
} }
...would indicate that a similar poll indicated a somewhat weak ...would indicate that a similar poll indicated a somewhat weak
consensus that Alex Rodriguez tends to choke in critical baseball consensus that Alex Rodriguez tends to fail in critical batting
situations. situations during baseball games.
In practice, it is expected that most reputons will have an "context"
parameter to target an application-specific set of assertions.
The following is an example reputon generated using this schema, The following is an example reputon generated using this schema,
including the media type definition line that identifies a specific including the media type definition line that identifies a specific
reputation application context. Here, reputation agent reputation application context. Here, reputation agent
"rep.example.net" is asserting within the context of the "email-id" "rep.example.net" is asserting within the context of the "email-id"
application (see [I-D.REPUTE-EMAIL-IDENTIFIERS]) that "example.com" application (see [I-D.REPUTE-EMAIL-IDENTIFIERS]) that "example.com"
appears to be associated with spam 1.2% of the time, based on just appears to be associated with spam 1.2% of the time, based on just
short of 17 million messages analyzed or reported to date. The short of 17 million messages analyzed or reported to date. The
"email-id" application has declared the extension key "identity" to "email-id" application has declared the extension key "email-id-
indicate how the subject identifier was used in the observed data, identity" to indicate how the subject identifier was used in the
establishing some more specific semantics for the "rating" value. In observed data, establishing some more specific semantics for the
this case, the extension is used to show the identity "example.com", "rating" value. In this case, the extension is used to show the
the subject of the query, is extracted from the analyzed messages identity "example.com", the subject of the query, is extracted from
using the [DKIM] "d=" parameter for messages where signatures the analyzed messages using the DomainKeys Identified Mail [DKIM]
validate. The reputation agent is 95% confident of this result. "d=" parameter for messages where signatures validate. The
(See [I-D.REPUTE-EMAIL-IDENTIFIERS] for details about the registered reputation agent is 95% confident of this result. A second reputon
email identifiers application.) is also present indicating similar information for the same domain as
Content-Type: application/reputon+json; context="email-id" it is used in the context of Sender Policy Framework [SPF]
evaluations. (See [I-D.REPUTE-EMAIL-IDENTIFIERS] for details about
the registered email identifiers application.)
Content-Type: application/reputons+json
{ {
"reputon": "application": "email-id",
{ "reputons": [
"rater": "rep.example.net", {
"assertion": "spam", "rater": "rep.example.net",
"identity": "dkim", "assertion": "spam",
"rated": "example.com", "identity": "dkim",
"confidence": 0.95, "rated": "example.com",
"rating": 0.012, "confidence": 0.95,
"sample-size": 16938213, "rating": 0.012,
"updated": 1317795852 "sample-size": 16938213,
} "updated": 1317795852
},
{
"rater": "rep.example.net",
"assertion": "spam",
"identity": "spf",
"rated": "example.com",
"confidence": 0.98,
"rating": 0.023,
"sample-size": 16938213,
"updated": 1317795852
}
]
} }
7. IANA Considerations 7. IANA Considerations
This document presents two actions for IANA, namely the creation of This document presents two actions for IANA, namely the creation of
the new media type "application/reputon+json" and the creation of a the new media type "application/reputons+json" and the creation of a
registry for reputation application types. Another document in this registry for reputation application types. Another document in this
series creates an initial registry entry for the latter. series creates an initial registry entry for the latter.
7.1. application/reputon+json Media Type Registration 7.1. application/reputons+json Media Type Registration
This section provides the media type registration application from This section provides the media type registration application from
[MIME-REG] for processing by IANA: [MIME-REG] for processing by IANA:
To: media-types@iana.org To: media-types@iana.org
Subject: Registration of media type application/reputon+json Subject: Registration of media type application/reputons+json
Type name: application Type name: application
Subtype name: reputon+json Subtype name: reputon+json
Required parameters: none Required parameters: none
Optional parameters: Optional parameters: none
context: 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 response set) for that
application. These are registered with IANA in the Reputation
Application Registry as described in Section 7.2.
Encoding considerations: "7bit" encoding is sufficient and is used Encoding considerations: "7bit" encoding is sufficient and is used
to maintain readability when viewed by non-MIME mail readers. to maintain readability when viewed by non-MIME mail readers.
Security considerations: See Section 8 of [this document]. Security considerations: See Section 8 of [this document].
Interoperability considerations: Implementers may encounter "app" Interoperability considerations: Implementers may encounter "app"
values, attribute/value pairs, or response set items that they do values, attribute/value pairs, or response set items that they do
not support, which are to be ignored. not support, which are to be ignored.
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 form
form" defined in [I-D.REPUTE-QUERY-HTTP]. The example application defined in [I-D.REPUTE-QUERY-HTTP]. The example application is
is one that provides reputation expressions about DNS domain names one that provides reputation data about DNS domain names and other
found in email messages. identifiers found in email messages.
Additional information: The value of the "app" parameter is Additional information: The value of the "app" parameter is
registered with IANA. 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> Murray S. Kucherawy <superuser@gmail.com>
Murray S. Kucherawy <msk@cloudmark.com>
Intended usage: COMMON Intended usage: COMMON
Author: Author:
Nathaniel Borenstein Nathaniel Borenstein
Murray S. Kucherawy Murray S. Kucherawy
Change controller: IESG Change controller: IESG
7.2. Reputation Applications Registry 7.2. Reputation Applications Registry
IANA is requested to create the "Reputation Applications" registry. IANA is requested to create the "Reputation Applications" registry.
This registry will contain names of applications used with the This registry will contain names of applications used with the
application/reputon+json media type (and other media types that carry application/reputons+json media type (and other media types that
reputons), as defined by this document. carry reputons), as defined by this document.
New registrations or updates are published in accordance with the New registrations or updates are published in accordance with either
"Specification Required" guidelines as described in the "IETF Review" or "Specification Required" guidelines as described
[IANA-CONSIDERATIONS]. in [IANA-CONSIDERATIONS].
New registrations and updates are to contain the following New registrations and updates are to contain the following
information: information:
1. Name of the application being registered or updated 1. Name of the application being registered or updated. Valid names
conform to the ABNF construction "token" as defined in
Multipurpose Internet Mail Extensions (MIME) Part One [MIME].
2. Short description of the application (i.e., the class of entity 2. Short description of the application (i.e., the class of entity
about which it reports reputation data) about which it reports reputation data)
3. The document in which the application is defined 3. The document in which the application is defined
4. New or updated status, which is to be one of: 4. New or updated status, which is to be one of:
current: The application is in current use current: The application is in current use
deprecated: The application is in current use but its use is deprecated: The application is in current use but its use is
discouraged discouraged
historic: The application is no longer in current use historic: The application is no longer in current use
5. A description of the subject of a query within this reputation, A specification for an application space needs to be specific and
and a legal syntax for the same clear enough to allow interoperability, and include at least the
following details:
6. An optional table of query parameters that are specific to this o The application's symbolic name, as it appears in the registration
application; each table entry must include: (see above)
Name: Name of the query parameter o A description of the subject of a query within this reputation,
and a legal syntax for the same
Status: (as above) o An optional table of query parameters that are specific to this
application; each table entry must include:
Description: A short description of the purpose of this Name: Name of the query parameter
parameter
Syntax: A reference to a description of valid syntax for the Status: (as above)
parameter's value
Required: "yes" if the parameter is mandatory, "no" otherwise Description: A short description of the purpose of this parameter
7. A list of one or more assertions registered within this Syntax: A reference to a description of valid syntax for the
application; each table entry is to include: parameter's value
Name: Name of the assertion Required: "yes" if the parameter is mandatory, "no" otherwise
Description: A short description of the assertion, with specific o A list of one or more assertions registered within this
meanings for values of 0.0 and 1.0 application; each table entry is to include:
Scale: A short description of the scale used in computing the Name: Name of the assertion
value (see Section 4 of this document)
8. An optional list of one or more response set extension keys for Description: A short description of the assertion, with specific
use within this application; each table entry is to include: meanings for values of 0.0 and 1.0
Name: Name of the extension key Scale: A short description of the scale used in computing the
value (see Section 4 of this document)
Description: A short description of the key's intended meaning o An optional list of one or more response set extension keys for
use within this application; each table entry is to include:
Syntax: A description of valid values that can appear associated Name: Name of the extension key
with the key
Description: A short description of the key's intended meaning
Syntax: A description of valid values that can appear associated
with the key
The names of attributes registered should be prefixed by the name of The names of attributes registered should be prefixed by the name of
the application itself (e.g., the "foo" application registering a the application itself (e.g., the "foo" application registering a
"bar" attribute should call it "foo-bar") to avoid namespace "bar" attribute should call it "foo-bar") to avoid namespace
collisions. collisions.
For registrations qualifying under "Specification Required" rules,
the designated expert should confirm the document meets the minima
described above and otherwise looks generally acceptable, and then
approve the registration.
8. Security Considerations 8. Security Considerations
This document is primarily an IANA action registering a media type. This document is primarily an IANA action registering a media type.
It does not describe a new protocol that might introduce security It does not describe a new protocol that might introduce security
considerations. considerations.
Discussion of the security and operational impacts of using Discussion of the security and operational impacts of using
reputation services in general can be found throughout reputation services in general can be found throughout
[I-D.REPUTE-CONSIDERATIONS]. [I-D.REPUTE-CONSIDERATIONS].
skipping to change at page 13, line 31 skipping to change at page 15, line 4
This document is primarily an IANA action registering a media type. This document is primarily an IANA action registering a media type.
It does not describe a new protocol that might introduce security It does not describe a new protocol that might introduce security
considerations. considerations.
Discussion of the security and operational impacts of using Discussion of the security and operational impacts of using
reputation services in general can be found throughout reputation services in general can be found throughout
[I-D.REPUTE-CONSIDERATIONS]. [I-D.REPUTE-CONSIDERATIONS].
9. References 9. References
9.1. Normative References 9.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.REPUTE-MODEL] [I-D.REPUTE-MODEL]
Borenstein, N. and M. Kucherawy, "A Model for Reputation Borenstein, N. and M. Kucherawy, "A Model for Reputation
Interchange", draft-ietf-repute-model (work in progress), Interchange", draft-ietf-repute-model (work in progress),
November 2012. November 2012.
[I-D.REPUTE-QUERY-HTTP] [I-D.REPUTE-QUERY-HTTP]
Borenstein, N. and M. Kucherawy, "Reputation Data Borenstein, N. and M. Kucherawy, "Reputation Data
Interchange using HTTP and XML", Interchange using HTTP and XML",
draft-ietf-repute-query-http (work in progress), draft-ietf-repute-query-http (work in progress),
November 2012. November 2012.
skipping to change at page 14, line 15 skipping to change at page 15, line 30
[KEYWORDS] [KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
September 2011. September 2011.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[I-D.REPUTE-CONSIDERATIONS] [I-D.REPUTE-CONSIDERATIONS]
Kucherawy, M., "Operational Considerations Regarding Kucherawy, M., "Operational Considerations Regarding
Reputation Services", draft-ietf-repute-considerations Reputation Services", draft-ietf-repute-considerations
(work in progress), November 2012. (work in progress), November 2012.
[I-D.REPUTE-EMAIL-IDENTIFIERS] [I-D.REPUTE-EMAIL-IDENTIFIERS]
Borenstein, N. and M. Kucherawy, "A Reputation Vocabulary Borenstein, N. and M. Kucherawy, "A Reputation Vocabulary
for Email Identifiers", for Email Identifiers",
draft-ietf-repute-email-identifiers (work in progress), draft-ietf-repute-email-identifiers (work in progress),
November 2012. November 2012.
[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.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[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.
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
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, Simon this specification: Frank Ellermann, Tony Hansen, Jeff Hodges, Simon
Hunt, John Levine, David F. Skoll, and Mykyta Yevstifeyev. Hunt, John Levine, David F. Skoll, and Mykyta Yevstifeyev.
Appendix B. Public Discussion Appendix B. Public Discussion
Public discussion of this suite of documents takes place on the Public discussion of this suite of documents takes place on the
domainrep@ietf.org mailing list. See domainrep@ietf.org mailing list. See
 End of changes. 70 change blocks. 
190 lines changed or deleted 255 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/