draft-ietf-repute-media-type-10.txt   draft-ietf-repute-media-type-11.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: January 18, 2014 July 17, 2013 Expires: March 2, 2014 August 29, 2013
A Media Type for Reputation Interchange A Media Type for Reputation Interchange
draft-ietf-repute-media-type-10 draft-ietf-repute-media-type-11
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 January 18, 2014. This Internet-Draft will expire on March 2, 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 6, line 30 skipping to change at page 6, line 30
A reputon expressed in JSON consists of an object that itself A reputon expressed in JSON consists of an object that itself
contains zero or more objects whose names are "reputon". Each contains zero or more objects whose names are "reputon". Each
reputon object is a set of key-value pairs, where the keys are the reputon object is a set of key-value pairs, where the keys are the
names of particular attributes that comprise a reputon (as listed names of particular attributes that comprise a reputon (as listed
above, or as provided with specific applications), and values are the above, or as provided with specific applications), and values are the
content associated with those keys. The set of keys that make up a content associated with those keys. The set of keys that make up a
reputon within a given application are known as that application's reputon within a given application are known as that application's
"response set". "response set".
A reputon object typically contains a reply corresponding to the
assertion for which a client made a specific request. For example, a
client asking for assertion "sends-spam" about domain "example.com"
would expect a reply consisting of a reputon making a "sends-spam"
assertion about "example.com" and nothing more. If a client makes a
request about a subject but does not specify an assertion of
interest, the server can return reputons about any assertion for
which it has data; in effect, the client has asked for any available
information about the subject. A client that receives an irrelevant
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 server has been received, and serves as a positive indication that the
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.1.1. Formal Definition
Using [ABNF], the syntax of a reputon is: Using [ABNF], the syntax of a reputon is:
reputon = "{" [ reputon-object reputon = "{" [ reputon-object
*(value-separator reputon-object) ] "}" *(value-separator reputon-object) ] "}"
reputon-object = "reputon" name-separator response-set reputon-object = "reputon" name-separator response-set
skipping to change at page 14, line 21 skipping to change at page 14, line 21
[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., [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-CONSIDERATIONS] [I-D.REPUTE-CONSIDERATIONS]
Kucherawy, M., "Operational Considerations Regarding Kucherawy, M., "Operational Considerations Regarding
Reputation Services", draft-ietf-repute-model (work in Reputation Services", draft-ietf-repute-considerations
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.
 End of changes. 6 change blocks. 
7 lines changed or deleted 18 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/