idnits 2.17.1 draft-ietf-repute-media-type-00.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 (November 19, 2011) is 4542 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CFWS' is mentioned on line 225, but not defined == Missing Reference: 'TBD' is mentioned on line 377, 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 (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 REPUTE Working Group N. Borenstein 3 Internet-Draft Mimecast 4 Intended status: Standards Track M. Kucherawy 5 Expires: May 22, 2012 Cloudmark 6 November 19, 2011 8 A Media Type for Reputation Interchange 9 draft-ietf-repute-media-type-00 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 22, 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. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 52 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Other Definitions . . . . . . . . . . . . . . . . . . . . 3 54 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Formal Definition . . . . . . . . . . . . . . . . . . . . 5 56 4. Scores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 5.1. application/reputon Media Type Registration . . . . . . . 7 59 5.2. Reputation Applications Registry . . . . . . . . . . . . . 8 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 64 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 65 Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 This memo defines a media type for use when answering a reputation 71 query using the "long form" query defined in RFCxxxx+4, which uses 72 [HTTP]. It is part of a series defining the overall reputation 73 query/response structure as well as the concept of reputation 74 "vocabularies" for particular applications. 76 Also included is the specification for an IANA registry to contain 77 definitions and symbolic names for known reputation vocabularies. 79 2. Terminology and Definitions 81 This section defines terms used in the rest of the document. 83 2.1. Keywords 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [KEYWORDS]. 89 2.2. Other Definitions 91 Other terms of importance in this memo are defined in RFCxxxx, the 92 base memo in this document series. 94 3. Description 96 A new media type, "application/reputon", is defined for the 97 representation of reputational data. This media type has two 98 optional parameters: "app", which conveys the specific application of 99 reputation data in use, and usually extends the set of data values 100 that MAY be included in the media object itself; and "format", which 101 specifies the format with which the content are relayed. 103 The default for "format" is "text", which is defined here. Reputons 104 bearing unrecognized format values MUST be ignored. 106 The body of the media type consists of [MAIL]-style attribute/value 107 pairs. The following are REQUIRED for all applications: 109 RATER: The identity of the entity providing the reputation 110 information, generally expressed as a DNS domain name. 112 ASSERTION: A keyword indicating the specific assertion or claim 113 being rated. In the absence of an "app" parameter, the reputon 114 can only indicate generic goodness, with the default assertion 115 "IS-GOOD," but each application is expected to define additional 116 types of ASSERTION. 118 RATED: The identity of the entity being rated. 120 RATING: The overall rating score for that entity, expressed as a 121 floating-point number between 0.0 and 1.0 inclusive. See 122 Section 4 for discussion. 124 The following are OPTIONAL for all applications, to be used in 125 contexts where they are appropriate: 127 CONFIDENCE: The level of confidence the reputation provider has in 128 the value presented being accurate, expressed as a floating-point 129 number between 0 and 1 inclusive. 131 RATER-AUTHENTICITY: The level of confidence in that identity being 132 genuine, expressed as a floating-point number between 0 and 1 133 inclusive. 135 SAMPLE-SIZE: The number of data points used to compute that score, 136 possibly an approximation. Expressed as an unsigned 64-bit 137 integer. The units are deliberately not specified, since not all 138 reputation service providers will collect data the same way. 139 Consumers will need to determine out-of-band the units being 140 reported and apply this value accordingly within their local 141 policies. 143 A particular application that registers itself with IANA MAY also 144 define extension attribute/value pairs beyond these standard ones. 146 Thus, the following example: 148 Content-type: application/reputon 150 RATER: RatingsRUs.example.com 151 RATER-AUTHENTICITY: 1.0 152 ASSERTION: IS-GOOD 153 RATED: Alex Rodriguez 154 RATING: 0.99 155 SAMPLE-SIZE: 50000 157 ...indicates that we are absolutely sure (1.0) that the entity 158 "RatingsRUs.example.com" consolidated 50000 data points (perhaps from 159 everyone in Yankee Stadium) and concluded that Alex Rodriguez is very 160 very good (0.99) at something. It doesn't tell us what he's good at, 161 and while it might be playing baseball, it could just as well be 162 paying his taxes on time. 164 A more sophisticated usage would define a baseball application with a 165 vocabulary of specific assertions, so that this example: 167 Content-type: application/reputon; app="baseball" 169 RATER: baseball-reference.example.com 170 RATER-AUTHENTICITY: 1.0 171 ASSERTION: HITS-FOR-POWER 172 RATED: Alex Rodriguez 173 RATING: 0.99 174 SAMPLE-SIZE: 50000 176 ...would indicate that 50000 fans polled by the entity baseball- 177 reference.example.com rate A-Rod very highly in hitting for power, 178 whereas this example: 180 Content-type: application/reputon; app="baseball" 182 RATER: baseball-reference.example.com 183 RATER-AUTHENTICITY: 1.0 184 ASSERTION: CLUTCH-HITTER 185 RATED: Alex Rodriguez 186 RATING: 0.4 187 SAMPLE-SIZE: 50000 189 ...would indicate that a similar poll indicated a somewhat weaker 190 consensus that A-Rod tends to choke in critical baseball situations. 192 In practice, most usage of reputons is expected to make use of the 193 "app" parameter to target an application-specific set of assertions. 195 3.1. Formal Definition 197 More formally, using [ABNF], the content of the application/reputon 198 MIME object MUST conform to the following syntax: 200 reputon := rater rater-auth assertion *extension 201 rated rating sampsize 203 rater := "RATER:" 204 *WSP (atom / quoted-string) [CFWS] CRLF 206 rater-auth := "RATER-AUTHENTICITY:" 207 *WSP 1*DIGIT "." 1*DIGIT [CFWS] CRLF 208 ; must be a number between -1 and 1 inclusive 210 assertion := "ASSERTION:" 211 *WSP dot-atom-text [CFWS] CRLF 213 extension := dot-atom-text %x3A *WSP dot-atom-text [CFWS] CRLF 214 ; must be registered with IANA within a reputation 215 ; vocabulary registration 217 rated := "RATED:" 218 *WSP (atom / quoted-string) [CFWS] CRLF 220 rating := "RATING:" 221 *WSP 1*DIGIT "." 1*DIGIT [CFWS] CRLF 222 ; must be a number between 0 and 1 inclusive 224 sampsize := "SAMPLE-SIZE": 225 *WSP 1*DIGIT [CFWS] CRLF 226 ; must be an unsigned 64-bit integer 228 "atom", "quoted-string" and "dot-atom-text" are imported from [MAIL]. 230 4. Scores 232 The score presented as the value in the RATING parameter appears as a 233 floating point value between 0.0 and 1.0 inclusive. The intent is 234 that the definition of an assertion within an application will 235 declare what the anchor values 0.0 and 1.0 specifically mean. 236 Generally speaking, 1.0 implies full agreement with the assertion, 237 while 0.0 indicates no support for the assertion. 239 The definition will also specify the type of scale in use when 240 generating scores, to which all reputation service providers for that 241 application space must adhere. This will allow a client to change 242 which reputation service provider is being queried for a given 243 without having to learn through some out-of-band method what the new 244 provider's values mean. For example, a registration might state that 245 ratings are linear, which would mean a score of "x" is twice as 246 strong as a value of "x/2". 248 5. IANA Considerations 250 This memo presents two actions for IANA, namely the creation of the 251 new media type "application/reputon" and the creation of a registry 252 for reputation application types. Another memo in this series 253 creates an initial registry entry for the latter. 255 5.1. application/reputon Media Type Registration 257 This section provides the media type registration application from 258 [MIME-REG] for processing by IANA: 260 To: ietf-types@iana.org 262 Subject: Registration of media type application/reputon 264 Type name: application 266 Subtype name: reputon 268 Required parameters: none 270 Optional parameters: 272 app: Names the reputation application in use within the reputon, 273 which defines the valid assertions and any extensions that may 274 also be valid (i.e., the vocabulary) for that application. 275 These MUST be registered with IANA. 277 format: Describes the format of the content of the MIME object. 278 The default is "text" which is defined in this memo. 280 Encoding considerations: "7bit" encoding is sufficient and MUST be 281 used to maintain readability when viewed by non-MIME mail readers. 283 Security considerations: See Section 6 of [this document]. 285 Interoperability considerations: Implementers MUST ignore any "app" 286 values, attribute/value pairs, or vocabulary items they do not 287 support. 289 Published specification: [this document] 291 Applications that use this media type: Any application that wishes 292 to query a service that provides reputation data using the "long 293 form" defined in RFCxxxx. The example application is one that 294 provides reputation expressions about DNS domain names found in 295 email messages. 297 Additional information: The value of the "app" parameter MUST also 298 be registered with IANA. 300 Person and email address to contact for further information: 302 Nathaniel Borenstein 304 Murray S. Kucherawy 306 Intended usage: COMMON 308 Author: 310 Nathaniel Borenstein 312 Murray S. Kucherawy 314 Change controller: IESG 316 5.2. Reputation Applications Registry 318 IANA is requested to create the "Reputation Applications" registry. 319 This registry will contain names of applications used with the 320 application/reputon media type, as defined by this memo. 322 New registrations or updates MUST be published in accordance with the 323 "Specification Required" guidelines as described in 324 [IANA-CONSIDERATIONS]. 326 New registrations and updates MUST contain the following information: 328 1. Name of the application being registered or updated 330 2. Short description of the application (i.e., the class of entity 331 about which it reports reputation data) 333 3. The document in which the application is defined 335 4. New or updated status, which MUST be one of: 337 current: The application is in current use 339 deprecated: The application is in current use but its use is 340 discouraged 342 historic: The application is no longer in current use 344 5. An optional table of query parameters that are specific to this 345 application; each table entry must include: 347 Name: Name of the query parameter 349 Status: (as above) 351 Description: A short description of the purpose of this 352 parameter 354 Syntax: A reference to a description of valid syntax for the 355 parameter's value 357 Required: "yes" if the parameter is mandatory, "no" otherwise 359 A document creating a reputation application MUST include: 361 1. A list of one or more assertions registered within this 362 application; each table entry must include: 364 Name: Name of the assertion 366 Description: A short description of the assertion, with specific 367 meanings for values of 0.0 and 1.0 369 Scale: A short description of the scale used in computing the 370 value (see Section 4 of this memo) 372 6. Security Considerations 374 This memo describes security considerations introduced by the media 375 type defined here. 377 [TBD] 379 7. References 381 7.1. Normative References 383 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 384 Specifications: ABNF", RFC 5234, January 2008. 386 7.2. Informative References 388 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 389 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 390 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 392 [IANA-CONSIDERATIONS] 393 Narten, T. and H. Alvestrand, "Guidelines for Writing an 394 IANA Considerations Section in RFCs", RFC 5226, May 2008. 396 [KEYWORDS] 397 Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 401 October 2008. 403 [MIME-REG] 404 Freed, N. and J. Klensin, "Media Type Specifications and 405 Registration Procedures", RFC 4288, December 2005. 407 Appendix A. Acknowledgments 409 The authors wish to acknowledge the contributions of the following to 410 this specification: Frank Ellermann, Tony Hansen, Jeff Hodges, John 411 Levine, and David F. Skoll. 413 Appendix B. Public Discussion 415 Public discussion of this suite of memos takes place on the 416 domainrep@ietf.org mailing list. See 417 https://www.ietf.org/mailman/listinfo/domainrep. 419 Authors' Addresses 421 Nathaniel Borenstein 422 Mimecast 423 203 Crescent St., Suite 303 424 Waltham, MA 02453 425 USA 427 Phone: +1 781 996 5340 428 Email: nsb@guppylake.com 429 Murray S. Kucherawy 430 Cloudmark 431 128 King St., 2nd Floor 432 San Francisco, CA 94107 433 USA 435 Phone: +1 415 946 3800 436 Email: msk@cloudmark.com