idnits 2.17.1 draft-ietf-repute-media-type-13.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 (September 15, 2013) is 3866 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) ** Obsolete normative reference: RFC 4627 (ref. 'JSON') (Obsoleted by RFC 7158, RFC 7159) -- 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) -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: March 19, 2014 September 15, 2013 7 A Media Type for Reputation Interchange 8 draft-ietf-repute-media-type-13 10 Abstract 12 This document defines the format of reputation response data 13 ("reputons"), the media-type for packaging it, and definition of a 14 registry for the names of reputation applications and response sets. 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 March 19, 2014. 33 Copyright Notice 35 Copyright (c) 2013 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. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.3. Other Definitions . . . . . . . . . . . . . . . . . . . . 3 55 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Reputon Attributes . . . . . . . . . . . . . . . . . . . . 4 57 4. Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Reputons . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 6 62 6.2.1. Imported JSON Terms . . . . . . . . . . . . . . . . . 7 63 6.2.2. Reputon Structure . . . . . . . . . . . . . . . . . . 7 64 6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 7.1. application/reputons+json Media Type Registration . . . . 11 67 7.2. Reputation Applications Registry . . . . . . . . . . . . . 12 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 73 Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 This document defines a data object for use when answering a 79 reputation query. It also defines a media type to carry the response 80 set data when using a transport method that follows the media type 81 framework, such as the HyperText Transfer Protocol (HTTP) based query 82 method defined in [I-D.REPUTE-QUERY-HTTP]. Any future query methods 83 that might be developed are expected to use the same data object. 85 Also included is the specification for an IANA registry to contain 86 definitions and symbolic names for known reputation applications and 87 corresponding response sets. 89 2. Terminology and Definitions 91 This section defines terms used in the rest of the document. 93 2.1. Reputon 95 A "reputon" is a single independent object containing reputation 96 information. A particular query about a subject of interest will 97 receive one or more reputons in response, depending on the nature of 98 the data collected and reported by the server. 100 2.2. Key Words 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [KEYWORDS]. 106 2.3. Other Definitions 108 Other terms of importance in this document are defined in 109 [I-D.REPUTE-MODEL], the base document in this document series. 111 3. Description 113 The meta-format selected for the representation of a reputon is 114 JavaScript Object Notation (JSON), defined in [JSON]. Accordingly, a 115 new media type, "application/reputons+json", is defined for the JSON 116 representation of reputational data, typically in response to a 117 client making a request for such data about some subject. This media 118 type takes no parameters. 120 The body of the media type consists of a JSON document that contains 121 the reputation information requested. A detailed description of the 122 expected structure of the reply is provided below. 124 The media type comprises a single member indicating the name of the 125 application context (see Section 5.1 of [I-D.REPUTE-MODEL] in which 126 the reputational data are being returned. The application name 127 refers to a registration as described in Section 7.2, which defines 128 the valid assertions and any extensions that might also be valid 129 (i.e., the response set) for that application. 131 3.1. Reputon Attributes 133 The key pieces of data found in a reputon for all reputation 134 applications are defined as follows: 136 rater: The identity of the entity aggregating, computing, and 137 providing the reputation information, typically expressed as a DNS 138 domain name. 140 assertion: A keyword indicating the specific assertion or claim 141 being rated. 143 rated: The identity of the entity being rated. The nature of this 144 field is application-specific; it could be domain names, email 145 addresses, driver's license numbers, or anything that uniquely 146 identifies the entity being rated. Documents that define specific 147 reputation applications are required to define syntax and 148 semantics for this field. 150 rating: The overall rating score for that entity, expressed as a 151 floating-point number between 0.0 and 1.0 inclusive. See 152 Section 4 for discussion. 154 The following are OPTIONAL for all applications, to be used in 155 contexts where they are appropriate: 157 confidence: the level of certainty the reputation provider has that 158 the value presented is appropriate, expressed as a floating-point 159 number between 0.0 and 1.0 inclusive. 161 normal-rating: An indication of what the reputation provider would 162 normally expect as a rating for the subject. This allows the 163 client to note that the current rating is or is not in line with 164 expectations. 166 sample-size: The number of data points used to compute the rating, 167 possibly an approximation. Expressed as an unsigned 64-bit 168 integer. Consumers can assume that the count refers to distinct 169 data points rather than a count of aggregations (for example, 170 individual votes rather than aggregated vote counts) unless it is 171 specified out-of-band that some other interpretation is more 172 appropriate. The units are deliberately not normatively 173 specified, since not all reputation service providers will collect 174 data the same way. 176 generated: A timestamp indicating when this value was generated. 177 Expressed as the number of seconds since January 1, 1970 00:00 178 UTC. 180 expires: A timestamp indicating a time beyond which the score 181 reported is likely not to be valid. Expressed as the number of 182 seconds since January 1, 1970 00:00 UTC. See Section 5 for 183 discussion. 185 A particular application that registers itself with IANA (per 186 Section 7.2, below) can define additional application-specific 187 attribute/value pairs beyond these standard ones. 189 An application service provider might operate with an enhanced form 190 of common services, which might in turn prompt development and 191 reporting of specialized reputation information. The details of the 192 enhancements and specialized information are beyond the scope of this 193 document, except that the underlying JSON syntax is extensible for 194 encoding such provider-specific information. 196 4. Ratings 198 The score presented as the value in the rating attribute appears as a 199 floating point value between 0.0 and 1.0 inclusive. The intent is 200 that the definition of an assertion within an application will 201 declare what the anchor values 0.0 and 1.0 specifically mean. 202 Generally speaking, 1.0 implies full agreement with the assertion, 203 while 0.0 indicates no support for the assertion. 205 The definition will also specify the type of scale in use when 206 generating scores, to which all reputation service providers for that 207 application space must adhere. Further discussion can be found in 208 [I-D.REPUTE-MODEL]. 210 5. Caching 212 A reputon can contain an "expires" field indicating a timestamp after 213 which the client SHOULD NOT use the rating it contains, and SHOULD 214 issue a new query. 216 This specification does not mandate any caching of ratings on the 217 part of the client, but there are obvious operational benefits to 218 doing so. In the context of reputation, a cached (and hence, stale) 219 rating can cause desirable traffic to be identified as undesirable, 220 or vice-versa. 222 Reputation data is typically most volatile when the subject of the 223 reputation is young. Accordingly, if a service chooses to include 224 expiration timestamps as part a reply, these values SHOULD be lower 225 for subjects about which little data has been collected. 227 6. Reputons 229 6.1. Syntax 231 A reputon expressed in JSON is a set of key-value pairs, where the 232 keys are the names of particular attributes that comprise a reputon 233 (as listed above, or as provided with specific applications), and 234 values are the content associated with those keys. The set of keys 235 that make up a reputon within a given application are known as that 236 application's "response set". 238 A reputon object typically contains a reply corresponding to the 239 assertion for which a client made a specific request. For example, a 240 client asking for assertion "sends-spam" about domain "example.com" 241 would expect a reply consisting of a reputon making a "sends-spam" 242 assertion about "example.com" and nothing more. If a client makes a 243 request about a subject but does not specify an assertion of 244 interest, the server can return reputons about any assertion for 245 which it has data; in effect, the client has asked for any available 246 information about the subject. A client that receives an irrelevant 247 reputon simply ignores it. 249 An empty reputon is an acknowledgement by the server that the request 250 has been received, and serves as a positive indication that the 251 server does not have the information requested. This is semantically 252 equivalent to returning a reputon with a "sample-size" of zero. 254 6.2. Formal Definition 256 [JSON] defines the structure of JSON objects and arrays using a set 257 of primitive elements. Those elements will be used to describe the 258 JSON structure of a reputation object. 260 6.2.1. Imported JSON Terms 262 OBJECT: a JSON object, defined in Section 2.2 of [JSON] 264 MEMBER: a member of a JSON object, defined in Section 2.2 of [JSON] 266 MEMBER-NAME: the name of a MEMBER, defined as a "string" in Section 267 2.2 of [JSON] 269 MEMBER-VALUE: the value of a MEMBER, defined as a "value" in Section 270 2.2 of [JSON] 272 ARRAY: an array, defined in Section 2.3 of [JSON] 274 ARRAY-VALUE: an element of an ARRAY, defined in Section 2.3 of 275 [JSON] 277 NUMBER: a "number" as defined in Section 2.4 of [JSON] 279 INTEGER: an "integer" as defined in Section 2.4 of [JSON] 281 STRING: an "string" as defined in Section 2.5 of [JSON] 283 6.2.2. Reputon Structure 285 Using the above terms for the JSON structures, the syntax of a 286 reputation object is defined as follows: 288 reputation-object: an OBJECT containing a MEMBER reputation-context 289 and a MEMBER reputon-list 291 reputation-context: a MEMBER with MEMBER-NAME "application" and 292 MEMBER-VALUE a STRING (see Section 3) 294 reputon-list: a MEMBER with MEMBER-NAME "reputons" and MEMBER-VALUE 295 a reputon-array 297 reputon-array: an ARRAY, where each ARRAY-VALUE is a reputon 299 reputon: an OBJECT, where each MEMBER is a reputon-element 301 reputon-element: one of the following, defined below: rater-value, 302 assertion-value, rated-value, rating-value, conf-value, normal- 303 value, sample-value, gen-value, expire-value, ext-value; note the 304 following: 306 * The order of reputon-element members is not significant. 308 * A specific reputon-element MUST NOT appear more than once. 310 * rater-value, assertion-value, rated-value, and rating-value are 311 REQUIRED. 313 rater-value: a MEMBER with MEMBER-NAME "rater" and MEMBER-VALUE a 314 STRING (see "rater" in Section 3.1) 316 assertion-value: a MEMBER with MEMBER-NAME "assertion" and MEMBER- 317 VALUE a STRING (see "assertion" in Section 3.1) 319 rated-value: a MEMBER with MEMBER-NAME "rated" and MEMBER-VALUE a 320 STRING (see "rated" in Section 3.1) 322 rating-value: a MEMBER with MEMBER-NAME "rating" and MEMBER-VALUE a 323 NUMBER between 0.0 and 1.0 inclusive (see "rating" in 324 Section 3.1); the number SHOULD NOT not have more than three 325 decimal places of precision 327 conf-value: a MEMBER with MEMBER-NAME "confidence" and MEMBER-VALUE 328 a NUMBER between 0.0 and 1.0 inclusive (see "confidence" in 329 Section 3.1); the number SHOULD NOT not have more than three 330 decimal places of precision 332 normal-value: a MEMBER with MEMBER-NAME "normal-rating" and MEMBER- 333 VALUE a NUMBER between 0.0 and 1.0 inclusive (see "normal" in 334 Section 3.1); the number SHOULD NOT not have more than three 335 decimal places of precision 337 sample-value: a MEMBER with MEMBER-NAME "sample-size" and MEMBER- 338 VALUE a non-negative INTEGER (see "sample-size" in "normal" in 339 Section 3.1) 341 gen-value: a MEMBER with MEMBER-NAME "generated" and MEMBER-VALUE a 342 non-negative INTEGER (see "generated" in Section 3.1) 344 expire-value: a MEMBER with MEMBER-NAME "expires" and MEMBER-VALUE a 345 non-negative INTEGER (see "expires" in Section 3.1) 347 ext-value: a MEMBER, for extension purposes; MEMBER-NAME and MEMBER- 348 VALUE will be defined in separate application registrations 350 6.3. Examples 352 The following simple example: 354 Content-Type: application/reputons+json 356 { 357 "application": "baseball", 358 "reputons": [ 359 { 360 "rater": "RatingsRUs.example.com", 361 "assertion": "is-good", 362 "rated": "Alex Rodriguez", 363 "rating": 0.99, 364 "sample-size": 50000 365 } 366 ] 367 } 369 ...indicates to the client that "RatingsRUs.example.com" consolidated 370 50000 data points (perhaps from everyone in Yankee Stadium) and 371 concluded that Alex Rodriguez is very very good (0.99) at something. 372 It doesn't tell us what he's good at, and while it might be playing 373 baseball, it could just as well be paying his taxes on time. 375 A more sophisticated usage would define a baseball application with a 376 response set of specific assertions, so that this example: 378 Content-Type: application/reputons+json 380 { 381 "application": "baseball", 382 "reputons:" [ 383 { 384 "rater": "baseball-reference.example.com", 385 "assertion": "hits-for-power", 386 "rated": "Alex Rodriguez", 387 "rating": 0.99, 388 "sample-size": 50000 389 } 390 ] 391 } 393 ...would indicate that 50000 fans polled by the entity baseball- 394 reference.example.com rate Alex Rodriguez very highly in hitting for 395 power, whereas this example: 397 Content-Type: application/reputons+json 399 { 400 "application": "baseball", 401 "reputons": [ 402 { 403 "rater": "baseball-reference.example.com", 404 "assertion": "strong-hitter", 405 "rated": "Alex Rodriguez", 406 "rating": 0.4, 407 "confidence": 0.2, 408 "sample-size": 50000 409 } 410 ] 411 } 413 ...would indicate that a similar poll indicated a somewhat weak 414 consensus that Alex Rodriguez tends to fail in critical batting 415 situations during baseball games. 417 The following is an example reputon generated using this schema, 418 including the media type definition line that identifies a specific 419 reputation application context. Here, reputation agent 420 "rep.example.net" is asserting within the context of the "email-id" 421 application (see [I-D.REPUTE-EMAIL-IDENTIFIERS]) that "example.com" 422 appears to be associated with spam 1.2% of the time, based on just 423 short of 17 million messages analyzed or reported to date. The 424 "email-id" application has declared the extension key "email-id- 425 identity" to indicate how the subject identifier was used in the 426 observed data, establishing some more specific semantics for the 427 "rating" value. In this case, the extension is used to show the 428 identity "example.com", the subject of the query, is extracted from 429 the analyzed messages using the DomainKeys Identified Mail [DKIM] 430 "d=" parameter for messages where signatures validate. The 431 reputation agent is 95% confident of this result. A second reputon 432 is also present indicating similar information for the same domain as 433 it is used in the context of Sender Policy Framework [SPF] 434 evaluations. (See [I-D.REPUTE-EMAIL-IDENTIFIERS] for details about 435 the registered email identifiers application.) 436 Content-Type: application/reputons+json 438 { 439 "application": "email-id", 440 "reputons": [ 441 { 442 "rater": "rep.example.net", 443 "assertion": "spam", 444 "identity": "dkim", 445 "rated": "example.com", 446 "confidence": 0.95, 447 "rating": 0.012, 448 "sample-size": 16938213, 449 "updated": 1317795852 450 }, 451 { 452 "rater": "rep.example.net", 453 "assertion": "spam", 454 "identity": "spf", 455 "rated": "example.com", 456 "confidence": 0.98, 457 "rating": 0.023, 458 "sample-size": 16938213, 459 "updated": 1317795852 460 } 461 ] 462 } 464 7. IANA Considerations 466 This document presents two actions for IANA, namely the creation of 467 the new media type "application/reputons+json" and the creation of a 468 registry for reputation application types. Another document in this 469 series creates an initial registry entry for the latter. 471 7.1. application/reputons+json Media Type Registration 473 This section provides the media type registration application from 474 [MIME-REG] for processing by IANA: 476 To: media-types@iana.org 478 Subject: Registration of media type application/reputons+json 479 Type name: application 481 Subtype name: reputon+json 483 Required parameters: none 485 Optional parameters: none 487 Encoding considerations: "7bit" encoding is sufficient and is used 488 to maintain readability when viewed by non-MIME mail readers. 490 Security considerations: See Section 8 of [this document]. 492 Interoperability considerations: Implementers may encounter "app" 493 values, attribute/value pairs, or response set items that they do 494 not support, which are to be ignored. 496 Published specification: [this document] 498 Applications that use this media type: Any application that wishes 499 to query a service that provides reputation data using the form 500 defined in [I-D.REPUTE-QUERY-HTTP]. The example application is 501 one that provides reputation data about DNS domain names and other 502 identifiers found in email messages. 504 Additional information: The value of the "app" parameter is 505 registered with IANA. 507 Person and email address to contact for further information: 509 Murray S. Kucherawy 511 Intended usage: COMMON 513 Author: 515 Nathaniel Borenstein 517 Murray S. Kucherawy 519 Change controller: IESG 521 7.2. Reputation Applications Registry 523 IANA is requested to create the "Reputation Applications" registry. 524 This registry will contain names of applications used with the 525 application/reputons+json media type (and other media types that 526 carry reputons), as defined by this document. 528 New registrations or updates are published in accordance with either 529 the "IETF Review" or "Specification Required" guidelines as described 530 in [IANA-CONSIDERATIONS]. 532 New registrations and updates are to contain the following 533 information: 535 1. Name of the application being registered or updated. Valid names 536 conform to the ABNF construction "token" as defined in 537 Multipurpose Internet Mail Extensions (MIME) Part One [MIME]. 539 2. Short description of the application (i.e., the class of entity 540 about which it reports reputation data) 542 3. The document in which the application is defined 544 4. New or updated status, which is to be one of: 546 current: The application is in current use 548 deprecated: The application is in current use but its use is 549 discouraged 551 historic: The application is no longer in current use 553 A specification for an application space needs to be specific and 554 clear enough to allow interoperability, and include at least the 555 following details: 557 o The application's symbolic name, as it appears in the registration 558 (see above) 560 o A description of the subject of a query within this reputation, 561 and a legal syntax for the same 563 o An optional table of query parameters that are specific to this 564 application; each table entry must include: 566 Name: Name of the query parameter 568 Status: (as above) 570 Description: A short description of the purpose of this parameter 572 Syntax: A reference to a description of valid syntax for the 573 parameter's value 575 Required: "yes" if the parameter is mandatory, "no" otherwise 577 o A list of one or more assertions registered within this 578 application; each table entry is to include: 580 Name: Name of the assertion 582 Description: A short description of the assertion, with specific 583 meanings for values of 0.0 and 1.0 585 Scale: A short description of the scale used in computing the 586 value (see Section 4 of this document) 588 o An optional list of one or more response set extension keys for 589 use within this application; each table entry is to include: 591 Name: Name of the extension key 593 Description: A short description of the key's intended meaning 595 Syntax: A description of valid values that can appear associated 596 with the key 598 The names of attributes registered should be prefixed by the name of 599 the application itself (e.g., the "foo" application registering a 600 "bar" attribute should call it "foo-bar") to avoid namespace 601 collisions. 603 For registrations qualifying under "Specification Required" rules, 604 the designated expert should confirm the document meets the minima 605 described above and otherwise looks generally acceptable, and then 606 approve the registration. 608 8. Security Considerations 610 This document is primarily an IANA action registering a media type. 611 It does not describe a new protocol that might introduce security 612 considerations. 614 Discussion of the security and operational impacts of using 615 reputation services in general can be found throughout 616 [I-D.REPUTE-CONSIDERATIONS]. 618 9. References 619 9.1. Normative References 621 [I-D.REPUTE-MODEL] 622 Borenstein, N. and M. Kucherawy, "A Model for Reputation 623 Interchange", draft-ietf-repute-model (work in progress), 624 November 2012. 626 [I-D.REPUTE-QUERY-HTTP] 627 Borenstein, N. and M. Kucherawy, "Reputation Data 628 Interchange using HTTP and XML", 629 draft-ietf-repute-query-http (work in progress), 630 November 2012. 632 [JSON] Crockford, D., "The application/json Media Type for 633 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 635 [KEYWORDS] 636 Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 9.2. Informative References 641 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 642 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, 643 September 2011. 645 [I-D.REPUTE-CONSIDERATIONS] 646 Kucherawy, M., "Operational Considerations Regarding 647 Reputation Services", draft-ietf-repute-considerations 648 (work in progress), November 2012. 650 [I-D.REPUTE-EMAIL-IDENTIFIERS] 651 Borenstein, N. and M. Kucherawy, "A Reputation Vocabulary 652 for Email Identifiers", 653 draft-ietf-repute-email-identifiers (work in progress), 654 November 2012. 656 [IANA-CONSIDERATIONS] 657 Narten, T. and H. Alvestrand, "Guidelines for Writing an 658 IANA Considerations Section in RFCs", RFC 5226, May 2008. 660 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 661 Extensions (MIME) Part One: Format of Internet Message 662 Bodies", RFC 2045, November 1996. 664 [MIME-REG] 665 Freed, N. and J. Klensin, "Media Type Specifications and 666 Registration Procedures", RFC 4288, December 2005. 668 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 669 for Authorizing Use of Domains in E-Mail, Version 1", 670 RFC 4408, April 2006. 672 Appendix A. Acknowledgments 674 The authors wish to acknowledge the contributions of the following to 675 this specification: Frank Ellermann, Tony Hansen, Jeff Hodges, Simon 676 Hunt, John Levine, David F. Skoll, and Mykyta Yevstifeyev. 678 Appendix B. Public Discussion 680 Public discussion of this suite of documents takes place on the 681 domainrep@ietf.org mailing list. See 682 https://www.ietf.org/mailman/listinfo/domainrep. 684 Authors' Addresses 686 Nathaniel Borenstein 687 Mimecast 688 203 Crescent St., Suite 303 689 Waltham, MA 02453 690 USA 692 Phone: +1 781 996 5340 693 Email: nsb@guppylake.com 695 Murray S. Kucherawy 696 270 Upland Drive 697 San Francisco, CA 94127 698 USA 700 Email: superuser@gmail.com