idnits 2.17.1 draft-kucherawy-reputation-media-type-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 4551 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CFWS' is mentioned on line 236, but not defined -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4288 (ref. 'MIME-REG') (Obsoleted by RFC 6838) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Borenstein 3 Internet-Draft Mimecast 4 Intended status: Informational M. Kucherawy 5 Expires: May 3, 2012 Cloudmark 6 October 31, 2011 8 A Media Type for Reputation Interchange 9 draft-kucherawy-reputation-media-type-02 11 Abstract 13 This document defines a media type for exchanging reputation 14 information about an arbitrary class of object. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 3, 2012. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Document Series . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 53 3.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Other Definitions . . . . . . . . . . . . . . . . . . . . 3 55 4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Formal Definition . . . . . . . . . . . . . . . . . . . . 6 57 5. Scores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 6.1. application/reputon Media Type Registration . . . . . . . 7 60 6.2. Reputation Applications Registry . . . . . . . . . . . . . 8 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 66 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 67 Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 This memo defines a media type for use when answering a reputation 73 query using the "long form" query defined in RFCxxxx+4, which uses 74 [HTTP]. It is part of a series defining the overall reputation 75 query/response structure as well as the concept of reputation 76 "vocabularies" for particular applications. 78 Also included is the specification for an IANA registry to contain 79 definitions and symbolic names for known reputation vocabularies. 81 2. Document Series 83 This memo represents the media type registration, part of a series of 84 documents that define the overall service and introduce the initial 85 exemplary applications. The series is as follows: 87 1. RFCxxxx: A Model for Reputation Interchange 89 2. RFCxxxx+1: A Media Type for Reputation Information (this memo) 91 3. RFCxxxx+2: Using UDP for Reputation Interchange 93 4. RFCxxxx+3: Using the DNS for Reputation Interchange 95 5. RFCxxxx+4: Using HTTP/XML for Reputation Interchange 97 6. RFCxxxx+5: A Reputation Vocabulary for Email Identity Reputation 99 7. RFCxxxx+6: A Reputation Vocabulary for Email Property Reputation 101 3. Terminology and Definitions 103 This section defines terms used in the rest of the document. 105 3.1. Keywords 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [KEYWORDS]. 111 3.2. Other Definitions 113 Other terms of importance in this memo are defined in RFCxxxx, the 114 base memo in this document series. 116 4. Description 118 A new media type, "application/reputon", is defined for the 119 representation of reputational data. This media type has two 120 optional parameters: "app", which conveys the specific application of 121 reputation data in use, and usually extends the set of data values 122 that MAY be included in the media object itself; and "format", which 123 specifies the format with which the content are relayed. 125 The default for "format" is "text", which is defined here. Reputons 126 bearing unrecognized format values MUST be ignored. 128 The body of the media type consists of [MAIL]-style attribute/value 129 pairs, six of which are standard for all apps: 131 RATER: The identity of the entity providing the reputation 132 information, generally expressed as a DNS domain name. 134 RATER-AUTHENTICITY: The level of confidence in that identity being 135 genuine, expressed as a floating-point number between 0 and 1 136 inclusive. 138 ASSERTION: A keyword indicating the specific assertion or claim 139 being rated. In the absence of an "app" parameter, the reputon 140 can only indicate generic goodness, with the default assertion 141 "IS-GOOD," but each application is expected to define additional 142 types of ASSERTION. 144 RATED: The identity of the entity being rated. 146 RATING: The overall rating score for that entity, expressed as a 147 floating-point number between 0.0 and 1.0 inclusive. See 148 Section 5 for discussion. 150 SAMPLE-SIZE: The number of data points used to compute that score, 151 possibly an approximation. Expressed as an unsigned 64-bit 152 integer. 154 A particular application that registers itself with IANA MAY also 155 define extension attribute/value pairs beyond the six mandatory ones. 157 Thus, the following example: 159 Content-type: application/reputon 161 RATER: RatingsRUs.example.com 162 RATER-AUTHENTICITY: 1.0 163 ASSERTION: IS-GOOD 164 RATED: Alex Rodriguez 165 RATING: 0.99 166 SAMPLE-SIZE: 50000 168 ...indicates that we are absolutely sure (1.0) that the entity 169 "RatingsRUs.example.com" consolidated 50000 data points (perhaps from 170 everyone in Yankee Stadium) and concluded that Alex Rodriguez is very 171 very good (0.99) at something. It doesn't tell us what he's good at, 172 and while it might be playing baseball, it could just as well be 173 paying his taxes on time. 175 A more sophisticated usage would define a baseball application with a 176 vocabulary of specific assertions, so that this example: 178 Content-type: application/reputon; app="baseball" 180 RATER: baseball-reference.example.com 181 RATER-AUTHENTICITY: 1.0 182 ASSERTION: HITS-FOR-POWER 183 RATED: Alex Rodriguez 184 RATING: 0.99 185 SAMPLE-SIZE: 50000 187 ...would indicate that 50000 fans polled by the entity baseball- 188 reference.example.com rate A-Rod very highly in hitting for power, 189 whereas this example: 191 Content-type: application/reputon; app="baseball" 193 RATER: baseball-reference.example.com 194 RATER-AUTHENTICITY: 1.0 195 ASSERTION: CLUTCH-HITTER 196 RATED: Alex Rodriguez 197 RATING: 0.4 198 SAMPLE-SIZE: 50000 200 ...would indicate that a similar poll indicated a somewhat weaker 201 consensus that A-Rod tends to choke in critical baseball situations. 203 In practice, most usage of reputons is expected to make use of the 204 "app" parameter to target an application-specific set of assertions. 206 4.1. Formal Definition 208 More formally, using [ABNF], the content of the application/reputon 209 MIME object MUST conform to the following syntax: 211 reputon := rater rater-auth assertion *extension 212 rated rating sampsize 214 rater := "RATER:" 215 *WSP (atom / quoted-string) [CFWS] CRLF 217 rater-auth := "RATER-AUTHENTICITY:" 218 *WSP 1*DIGIT "." 1*DIGIT [CFWS] CRLF 219 ; must be a number between -1 and 1 inclusive 221 assertion := "ASSERTION:" 222 *WSP dot-atom-text [CFWS] CRLF 224 extension := dot-atom-text %x3A *WSP dot-atom-text [CFWS] CRLF 225 ; must be registered with IANA within a reputation 226 ; vocabulary registration 228 rated := "RATED:" 229 *WSP (atom / quoted-string) [CFWS] CRLF 231 rating := "RATING:" 232 *WSP 1*DIGIT "." 1*DIGIT [CFWS] CRLF 233 ; must be a number between 0 and 1 inclusive 235 sampsize := "SAMPLE-SIZE": 236 *WSP 1*DIGIT [CFWS] CRLF 237 ; must be an unsigned 64-bit integer 239 "atom", "quoted-string" and "dot-atom-text" are imported from [MAIL]. 241 5. Scores 243 The score presented as the value in the RATING parameter appears as a 244 floating point value between 0.0 and 1.0 inclusive. The intent is 245 that the definition of an assertion within an application will 246 declare what the anchor values 0.0 and 1.0 specifically mean. 247 Generally speaking, 1.0 implies full agreement with the assertion, 248 while 0.0 indicates no support for the assertion. 250 The definition will also specify the type of scale in use when 251 generating scores, to which all reputation service providers for that 252 application space must adhere. This will allow a client to change 253 which reputation service provider is being queried for a given 254 without having to learn through some out-of-band method what the new 255 provider's values mean. For example, a registration might state that 256 ratings are linear, which would mean a score of "x" is twice as 257 strong as a value of "x/2". 259 6. IANA Considerations 261 This memo presents two actions for IANA, namely the creation of the 262 new media type "application/reputon" and the creation of a registry 263 for reputation application types. Another memo in this series 264 creates an initial registry entry for the latter. 266 6.1. application/reputon Media Type Registration 268 This section provides the media type registration application from 269 [MIME-REG] for processing by IANA: 271 To: ietf-types@iana.org 273 Subject: Registration of media type application/reputon 275 Type name: application 277 Subtype name: reputon 279 Required parameters: none 281 Optional parameters: 283 app: Names the reputation application in use within the reputon, 284 which defines the valid assertions and any extensions that may 285 also be valid (i.e., the vocabulary) for that application. 286 These MUST be registered with IANA. 288 format: Describes the format of the content of the MIME object. 289 The default is "text" which is defined in this memo. 291 Encoding considerations: "7bit" encoding is sufficient and MUST be 292 used to maintain readability when viewed by non-MIME mail readers. 294 Security considerations: See Section 7 of [this document]. 296 Interoperability considerations: Implementers MUST ignore any "app" 297 values, attribute/value pairs, or vocabulary items they do not 298 support. 300 Published specification: [this document] 302 Applications that use this media type: Any application that wishes 303 to query a service that provides reputation data using the "long 304 form" defined in RFCxxxx. The example application is one that 305 provides reputation expressions about DNS domain names found in 306 email messages. 308 Additional information: The value of the "app" parameter MUST also 309 be registered with IANA. 311 Person and email address to contact for further information: 313 Nathaniel Borenstein 315 Murray S. Kucherawy 317 Intended usage: COMMON 319 Author: 321 Nathaniel Borenstein 323 Murray S. Kucherawy 325 Change controller: IESG 327 6.2. Reputation Applications Registry 329 IANA is requested to create the "Reputation Applications" registry. 330 This registry will contain names of applications used with the 331 application/reputon media type, as defined by this memo. 333 New registrations or updates MUST be published in accordance with the 334 "Specification Required" guidelines as described in 335 [IANA-CONSIDERATIONS]. 337 New registrations and updates MUST contain the following information: 339 1. Name of the application being registered or updated 341 2. Short description of the application (i.e., the class of entity 342 about which it reports reputation data) 344 3. The document in which the application is defined 346 4. New or updated status, which MUST be one of: 348 current: The application is in current use 350 deprecated: The application is in current use but its use is 351 discouraged 353 historic: The application is no longer in current use 355 5. An optional table of query parameters that are specific to this 356 application; each table entry must include: 358 Name: Name of the query parameter 360 Status: (as above) 362 Description: A short description of the purpose of this 363 parameter 365 Syntax: A reference to a description of valid syntax for the 366 parameter's value 368 Required: "yes" if the parameter is mandatory, "no" otherwise 370 A document creating a reputation application MUST include: 372 1. A list of one or more assertions registered within this 373 application; each table entry must include: 375 Name: Name of the assertion 377 Description: A short description of the assertion, with specific 378 meanings for values of 0.0 and 1.0 380 Scale: A short description of the scale used in computing the 381 value (see Section 5 of this memo) 383 7. Security Considerations 385 This memo describes security considerations introduced by the media 386 type defined here. 388 7.1. General 390 This memo is part of a series introducing a reputation query and 391 response system (see Section 2). The Security Considerations 392 sections of the other memos should also be consulted. 394 As this message structure is designed for use with the "long form" of 395 the reputation query, the Security Considerations of RFCxxxx+3 would 396 be of particular interest to implementers. 398 8. References 400 8.1. Normative References 402 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 403 Specifications: ABNF", RFC 5234, January 2008. 405 8.2. Informative References 407 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 408 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 409 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 411 [IANA-CONSIDERATIONS] 412 Narten, T. and H. Alvestrand, "Guidelines for Writing an 413 IANA Considerations Section in RFCs", RFC 5226, May 2008. 415 [KEYWORDS] 416 Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997. 419 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 420 October 2008. 422 [MIME-REG] 423 Freed, N. and J. Klensin, "Media Type Specifications and 424 Registration Procedures", RFC 4288, December 2005. 426 Appendix A. Acknowledgments 428 The authors wish to acknowledge the contributions of the following to 429 this specification: Frank Ellermann. 431 Appendix B. Public Discussion 433 Public discussion of this suite of memos takes place on the 434 domainrep@ietf.org mailing list. See 435 https://www.ietf.org/mailman/listinfo/domainrep. 437 Authors' Addresses 439 Nathaniel Borenstein 440 Mimecast 441 203 Crescent St., Suite 303 442 Waltham, MA 02453 443 USA 445 Phone: +1 781 996 5340 446 Email: nsb@guppylake.com 448 Murray S. Kucherawy 449 Cloudmark 450 128 King St., 2nd Floor 451 San Francisco, CA 94107 452 USA 454 Phone: +1 415 946 3800 455 Email: msk@cloudmark.com