idnits 2.17.1 draft-lilly-field-specification-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 696. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 702. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Lilly 2 Intended status: Informational 3 Expires: December 3, 2005 5 Implementer-friendly Specification of Message and MIME-Part Header 6 Fields and Field Components 7 draft-lilly-field-specification-04 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2005). 36 Abstract 38 Implementation of generators and parsers of header fields requires 39 certain information about those fields. Interoperability is most 40 likely when all such information is explicitly provided by the 41 technical specification of the fields. Lacking such explicit 42 information, implementers may guess, and interoperability may suffer. 43 This memo identifies information useful to implementers of header 44 field generators and parsers. 46 Discussion of this document should take place on the ietf-822 mailing 47 list. 49 Table of Contents 51 1. Introduction................................................... 3 52 2. Scope.......................................................... 3 53 3. Specification Items............................................ 3 54 3.1. Established Conventions................................... 3 55 3.1.1. Standard Terminology................................. 3 56 3.1.2. Naming Rules and Conventions......................... 4 57 3.2. Common Specification Items................................ 5 58 3.2.1. ABNF................................................. 5 59 3.2.2. Minimum and Maximum Instances of Fields per Header... 7 60 3.2.3. Categorization....................................... 7 61 3.3. Semantics................................................. 7 62 3.3.1. Producers, Modifiers, and Consumers.................. 7 63 3.3.2. What's it All About?................................. 7 64 3.3.3. Context.............................................. 7 65 3.4. Overall Considerations.................................... 8 66 3.4.1. Security............................................. 8 67 3.4.2. Backwards Compatibility.............................. 8 68 3.4.3. Compatibility With Legacy Content.................... 8 69 3.4.4. Interaction With Established Mechanisms.............. 9 70 4. Acknowledgments................................................ 9 71 5. Security Considerations........................................ 9 72 6. Internationalization Considerations............................ 9 73 7. IANA Considerations............................................ 9 74 Appendix A. Disclaimers........................................... 9 75 Appendix B. Change History........................................ 10 76 Normative References.............................................. 11 77 Informative References............................................ 12 78 Author's Address.................................................. 14 80 1. Introduction 82 Internet messages consist of a message header and a body [N1.STD11], 83 [N2.RFC2822]. MIME content begins with a MIME-part header 84 [N3.RFC2045], [N4.RFC2046]. Message headers and MIME-part headers 85 consist of fields. While the Message Format and MIME specifications 86 define their respective overall formats and some specific fields, 87 they also have provision for extension fields. A number of extension 88 fields have been specified, some more or less completely than others. 89 Incomplete or imprecise specification has led to interoperability 90 problems as implementers make assumptions in the absence of 91 specifications. This memo identifies items of potential interest to 92 implementers and section 3 of this memo may serve as an informational 93 guide for authors of specifications of extension fields and field 94 components. 96 2. Scope 98 This memo is intended as a non-binding informational supplement to 99 various specifications, guidelines, and procedures for specification 100 of header fields [N1.STD11], [N2.RFC2822], [N3.RFC2045], 101 [N4.RFC2046], [N5.BCP9], [N6.BCP90]. It does not absolve authors of 102 header field specifications from compliance with any provisions of 103 those or other specifications, guidelines, and procedures. It offers 104 clarification and supplementary suggestions that will promote 105 interoperability and may spare specification authors many questions 106 regarding incomplete header field specifications. 108 3. Specification Items 110 3.1. Established Conventions 112 A number of conventions exist for naming and specifying header 113 fields. It would be unwise and confusing to specify a field which 114 conflicts with those conventions. 116 3.1.1. Standard Terminology 118 Terms related to the Internet Message Format are defined in 119 [N2.RFC2822]. Authors specifying extension header fields should use 120 the same terms in the same manner in order to provide clarity and 121 avoid confusion. For example, a "header" [I1.FYI18], [N2.RFC2822] is 122 comprised of "header fields", each of which has a "field name" and 123 usually has a "field body". Each message may have multiple 124 "headers", viz. a message header and MIME-part [N4.RFC2046] headers. 126 A message header has a Date header field (i.e. a field with field 127 name "Date"). However, there is no "Date header"; use of such 128 non-standard terms is likely to lead to confusion, possibly resulting 129 in interoperability failures of implementations. 131 3.1.2. Naming Rules and Conventions 133 Several rules and conventions have been established for naming of 134 header fields. Rules are codified in published RFCs, conventions 135 reflect common use. 137 3.1.2.1. Naming Rules 139 Some RFCs define a particular prefix, reserving use of that prefix 140 for specific purposes. 142 3.1.2.1.1. Content- prefix rule 144 This prefix must be used for all MIME extension fields and must not 145 be used for fields which are not MIME extension fields [N3.RFC2045] 146 (section 9). 148 3.1.2.1.2. Resent- prefix rule 150 Specified for certain standard fields as given in [N1.STD11] (also 151 used by [N2.RFC2822], although not specified as a prefix therein). 152 If a Resent- version of a field is applicable, an author should say 153 so explicitly, and should provide a comprehensive specification of 154 any differences between the plain field and the Resent- version. 156 3.1.2.2. Naming Conventions 158 Some prefixes have developed as conventions. Although not formally 159 specified as reserved prefixes, these conventions are or have been in 160 use in multiple fields with common semantics for each prefix. 162 3.1.2.2.1. Accept- prefix convention 164 This prefix should be used for all extension fields intended for use 165 in content negotiation [I2.RFC2616] and should not be used for fields 166 which are not intended for such use. An example may be found in 167 [I3.RFC3282]. 169 3.1.2.2.2. List- prefix convention 171 Used to indicate information about mailing lists when a list 172 expansion takes place. Examples of defined fields can be found in 173 [I4.RFC2369] and [I5.RFC2919]. 175 3.1.2.2.3. Illegal- prefix convention 177 This prefix provides a record of illegal content in a field when 178 fields are transformed at a gateway [I6.RFC886]. 180 3.1.2.2.4. Disposition-Notification- prefix convention 182 Specification of information used in conjunction with Message 183 Disposition Notifications (MDNs) [I7.RFC3798]. 185 3.1.2.2.5. Original- prefix convention 187 Used to reference some content from a related message. Examples 188 include Original-Message-ID as used by [I8.RFC3297] and [I7.RFC3798], 189 Original-Encoded-Information-Types [I9.RFC2156], Original-Envelope-ID 190 [I10.RFC3464], and Original-Recipient [I7.RFC3798]. 192 3.1.2.2.6. Reporting- prefix 194 Specifies a host that generated a type of report, such as those 195 defined in [I7.RFC3798], [I10.RFC3464]. 197 3.1.2.2.7. X400- prefix convention 199 Used in conversion from X.400 environments by gateways [I9.RFC2156]. 201 3.1.2.2.8. Discarded-X400- prefix convention 203 Also used by gateways from X.400 [I9.RFC2156]. 205 3.1.2.2.9. P1- prefix convention 207 Was used by X.400 gateways [I11.RFC987]. 209 3.1.2.2.10. Delivery-Report-Content- prefix convention 211 Also used by legacy X.400 gateways [I11.RFC987] 213 3.2. Common Specification Items 215 Several items are specified for standard header fields; these items 216 should also be specified for extension fields. 218 3.2.1. ABNF 220 [N1.STD11] is vague about where whitespace is permitted or required 221 in header field syntax. [N2.RFC2822] addresses that issue by 222 defining grammar productions such as FWS and CFWS, in conjunction 223 with formal ABNF [N7.RFC2234] and in accordance with the necessity 224 for specificity of such issues as noted in section 3.1 of 225 [N7.RFC2234]. Extension field ABNF should clearly specify where 226 comments, line folding, and whitespace are prohibited and permitted, 227 and should use the [N2.RFC2822] grammar productions in ABNF for that 228 purpose. 230 All ABNF must be carefully checked for ambiguities and to ensure that 231 all productions resolve to some combination of terminal productions 232 provided by a normative reference [N8.CKLIST] ("All ABNF must be 233 checked"). [N7.RFC2234] provides several productions that may be 234 useful. While use of suitable productions defined and in use is 235 encouraged, specification authors are cautioned that some such 236 productions have been amended by subsequently issued RFCs and/or by 237 formal errata [I12.Errata]. 239 Authors and designers should be careful not to mix syntax with 240 disparate semantics within a single field. Examples of disparate 241 semantics are [N2.RFC2822] comments (which use parentheses as 242 delimiters), [I13.RFC2533] feature sets (which also use parentheses 243 as delimiters, but not for comments), and [I14.RFC3986] URIs (which 244 permit parentheses in URI text). 246 It is sometimes necessary or desirable to define keywords as protocol 247 elements in structured fields. Protocol elements should be 248 case-insensitive per the Internet Architecture [I15.RFC1958] (section 249 4.3). Keywords are typically registered by IANA; a specification 250 using registered keywords must include an IANA considerations section 251 [N9.BCP26], [I16.RFC3692], and should indicate to readers of the 252 specification precisely where IANA has set up the registry (authors 253 will need to coordinate this with IANA prior to publication as an 254 RFC). In many cases, it will be desirable to make provision for 255 extending the set of keywords; that may be done by specifying that 256 the set may be extended by publication of an RFC, or a formal review 257 and registration procedure may be specified (typically as a BCP RFC). 259 If keywords are defined, and if there is any chance that the set of 260 keywords might be expanded, a registry should be established via 261 IANA. If a registry is not established initially, there is a good 262 chance that initially-defined keywords will not be registered, or 263 will subsequently be registered with different semantics (this has 264 happened!). 266 Provision may be made for experimental or private-use keywords. 267 These typically begin with a case-insensitive "x-" prefix. Note that 268 [N10.BCP82] has specific considerations for use of experimental 269 keywords. 271 If some field content is to be considered human-readable text, there 272 must be provision for specifying language in accordance with 273 [N11.BCP18] (section 4.2). Header fields typically use the mechanism 274 specified in [I17.RFC2047] as amended by [I18.RFC2231] and 275 [I12.Errata] for that purpose. Note, however, that that mechanism 276 applies only to three specific cases; unstructured fields, an RFC 822 277 "word" in an RFC 822 "phrase", and comments in structured fields. 278 Any internationalization considerations should be detailed in an 279 Internationalization Considerations section of the specification as 280 specified in [N11.BCP18] (section 6). 282 Some field bodies may include ABNF representing numerical values. 283 Such ABNF, its comments, and supporting normative text should clearly 284 indicate whether such a numerical value is decimal, octal, 285 hexadecimal, etc., whether or not leading and/or trailing zeroes are 286 significant and/or permitted, and how any combinations of numeric 287 fields are intended to be interpreted. For example, two numeric 288 fields separated by a dot, exemplified by "001.100", "1.1", "1.075", 289 and "1.75" might be interpreted in several ways, depending on factors 290 such as those enumerated above. 292 While ABNF [N7.RFC2234] is used by [N2.RFC2822] and is mentioned 293 above, alternate formal syntax formats may be used in specifications 294 [I19.Syntax]. 296 3.2.2. Minimum and Maximum Instances of Fields per Header 298 Some fields are mandatory, others are optional. It may make sense to 299 permit multiple instances of a field in a given header; in other 300 cases at most a single instance is sensible. [N2.RFC2822] specifies 301 a minimum and maximum count per header for each standard field in a 302 message; specification authors should likewise specify minimum and 303 maximum counts for extension fields. 305 3.2.3. Categorization 307 [N2.RFC2822] defines categories of header fields (e.g. trace fields, 308 address fields). Such categories have implications for processing 309 and handling of fields. A specification author should indicate any 310 applicable categories. 312 3.3. Semantics 314 In addition to specifying syntax of a field, a specification document 315 should indicate the semantics of each field. Such semantics are 316 comprised of several aspects: 318 3.3.1. Producers, Modifiers, and Consumers 320 Some fields are intended for end-to-end communication between author 321 or sender and recipient; such fields should not be generated or 322 altered by intermediaries in the transmission chain [I20.Arch]. 323 Other fields comprise trace information which is added during 324 transport. Authors should clearly specify who may generate a field, 325 who may modify it in transit, who should interpret such a field, and 326 who is prohibited from interpreting or modifying the field. 328 3.3.2. What's it All About? 330 When introducing a new field or modifying an existing field, an 331 author should present a clear description of what problem or 332 situation is being addressed by the extension or change. 334 3.3.3. Context 336 The permitted types of headers in which the field may appear should 337 be specified. Some fields might only be appropriate in a message 338 header, some might appear in MIME-part headers [N4.RFC2046] as well 339 as message headers, still others might appear in specialized MIME 340 media types. 342 3.4. Overall Considerations 344 Several factors should be specified regarding how a field interacts 345 with the Internet at large, with the applications for which it is 346 intended, and in interacting with other applications. 348 3.4.1. Security 350 Every specification is supposed to include a carefully-considered 351 Security Considerations section [N12.RFC2223] (section 9), 352 [I21.BCP72]. 354 3.4.2. Backwards Compatibility 356 There is a large deployed base of applications which use header 357 fields. Implementations that comprise that deployed base may change 358 very slowly. It is therefore critically important to consider and 359 specify the impact of a new or revised field or field component on 360 that deployed base. A new field, or extensions to the syntax of an 361 existing field or field component, might not be recognizable to 362 deployed implementations. Depending on the care with which the 363 authors of an extension have considered such backwards compatibility, 364 such an extension might, for example: 366 a. Cause a deployed implementation to simply ignore the field in its 367 entirety. That is not a problem provided that it is a new field 368 and that there is no assumption that such deployed implementations 369 will do otherwise. 371 b. Cause a deployed implementation to behave differently from how it 372 would behave in the absence of the proposed change, in ways that 373 are not intended by the proposal. That is a failure of the 374 proposal to remain backwards compatible with the deployed base of 375 implementations. 377 There are many subtleties and variations that may come into play. 378 Authors should very carefully consider backwards compatibility when 379 devising extensions, and should clearly describe all known 380 compatibility issues. 382 3.4.3. Compatibility With Legacy Content 384 Content is sometimes archived for various reasons. It is sometimes 385 necessary or desirable to access archived content, with the semantics 386 of that archived content unchanged. It is therefore important that 387 lack of presence of an extension field or field component should not 388 be construed (by an extension specification) as conferring new 389 semantics on a message or piece of MIME content which lacks that 390 field or field component. Any such semantics should be explicitly 391 specified. 393 3.4.4. Interaction With Established Mechanisms 395 Header fields are handled specially by gateways under various 396 circumstances. Message fragmentation and reassembly [N4.RFC2046] is 397 one example. If special treatment is required for a header field 398 under such circumstances, it should be clearly specified by the 399 author of the specification. [I7.RFC3798] is an example of how this 400 might be handled (however, because that specification requires 401 deployed RFC 2046-conforming implementations to be modified, it is 402 not strictly backwards compatible). 404 4. Acknowledgments 406 The author would like to acknowledge the helpful comments provided by 407 members of the ietf-822 mailing list. In particular, Peter Koch and 408 Keith Moore have made useful comments. 410 5. Security Considerations 412 No new security considerations are addressed by this memo. The memo 413 reinforces the need for careful consideration and specification of 414 security issues. 416 6. Internationalization Considerations 418 This memo does not directly have internationalization considerations, 419 however it reminds specification authors of the need to consider 420 internationalization of textual field components. 422 7. IANA Considerations 424 While no specific action is required of IANA in regard to this memo, 425 it does note that some coordination between IANA and specification 426 authors who do require IANA to set up registries is at least 427 desirable, if not a necessity. IANA should also closely coordinate 428 with the RFC Editor so that registries are set up and properly 429 referenced at the time of publication of an RFC which refers to such 430 a registry. IANA is also encouraged to work closely with authors and 431 the RFC Editor to ensure that descriptions of registries maintained 432 by IANA are accurate and meaningful. 434 Appendix A. Disclaimers 436 This document has exactly one (1) author. 438 In spite of the fact that the author's given name may also be the 439 surname of other individuals, and the fact that the author's surname 440 may also be a given name for some females, the author is, and has 441 always been, male. 443 The presence of "or she", "/SHE", "each", "their", and "authors" 444 (plural) in the boilerplate sections of this document is irrelevant. 445 The author of this document is not responsible for the boilerplate 446 text. 448 Comments regarding the silliness, lack of accuracy, and lack of 449 precision of the boilerplate text should be directed to the IESG, not 450 to the author. 452 Appendix B. Change History 454 [[This change history will not be part of a published RFC]] 456 -03 to -04 (IESG review and RFC prep) 458 o separated sect. 4.1.1 into two paragraphs 460 o Further clarified rules vs. conventions 462 o removed items which go beyond scope of field specification 464 o removed BCP 14 reference and BCP 14 keywords 466 o added specific references for requirements imposed by referenced 467 specifications 469 o clarified some text 471 o added reference to IESG syntax format statement 473 o minor formatting improvements 475 -02 to -03 (Last Call comments and final tweaks) 477 o added suggested discussion forum to Abstract 479 o replaced two instances of naked RFC 2822 with reference tags 481 o separated prefix discussion into standardized prefixes and mere 482 conventions 484 o clarified requirements for standardized prefixes, with 485 references 487 o added several conventional prefixes 489 o clarified specificity of CFWS specification as noted in RFC 2234 491 o updated date in reference to Crocker mail architecture draft 493 o clarified purpose of message header fields 495 o added disclaimers of boilerplate silliness, etc. 497 -01 to -02 499 o added this change history 500 o added text regarding Accept- prefix 502 o added paragraph about mixed semantics within a field 504 o added paragraph regarding initial establishment of keyword 505 registry 507 o added paragraph about numerical value semantics 509 o updated references 511 o Internationalization Considerations section is emphasized to 512 correspond to RFC 2277 514 o revised boilerplate 516 -00 to -01 518 o revised reference numbering scheme 520 o updated Requirement Levels text to correspond to text changes 522 o added "and confusing" to introductory text re. Established 523 Conventions 525 o Added paragraph about standard terminology 527 o (RFC 2119) emphasis added for common specification items text 529 o minor wording changes 531 o changed ABNF checking to a requirement 533 o IANA Considerations section is a requirement if keywords are 534 registered 536 o provision for specifying language of text is a requirement 538 o added architectural considerations regarding DNS etc. 540 Normative References 542 [N1.STD11] Crocker, D., "Standard for the format of ARPA Internet 543 text messages", STD 11, RFC 822, August 1982. 545 [N2.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 546 2001. 548 [N3.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 549 Mail Extensions (MIME) Part One: Format of Internet 550 Message Bodies", RFC 2045, November 1996. 552 [N4.RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet 553 Mail Extensions (MIME) Part Two: Media Types", 554 RFC 2046, November 1996. 556 [N5.BCP9] Bradner, S., "The Internet Standards Process -- 557 Revision 3", BCP 9, RFC 2026, October 1996. 559 [N6.BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 560 Procedures for Message Header Fields", BCP 90, 561 RFC 3864, September 2004. 563 [N7.RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 564 Specifications: ABNF", RFC 2234, November 1997. 566 [N8.CKLIST] "Checklist for Internet-Drafts (IDs) submitted for RFC 567 publication", http://www.ietf.org/ID-Checklist.html 569 [N9.BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing 570 an IANA Considerations Section in RFCs", BCP 26, 571 RFC 2434, October 1998. 573 [N10.BCP82] Narten, T., "Assigning Experimental and Testing Numbers 574 Considered Useful", BCP 82, RFC 3692, January 2004. 576 [N11.BCP18] Alvestrand, H., "IETF Policy on Character Sets and 577 Languages", BCP 18, RFC 2277, January 1998. 579 [N12.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC 580 Authors", RFC 2223, October 1997. 582 Informative References 584 [I1.FYI18] Malkin, G., "Internet Users' Glossary", RFC 1983, 585 August 1996. 587 [I2.RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 588 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 589 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 591 [I3.RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 592 May 2002. 594 [I4.RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as 595 Meta-Syntax for Core Mail List Commands and their 596 Transport through Message Header Fields", RFC 2369, 597 July 1998. 599 [I5.RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured 600 Field and Namespace for the Identification of Mailing 601 Lists", RFC 2919, March 2001. 603 [I6.RFC886] Rose, M., "Proposed standard for message header 604 munging", RFC 886, December 1983. 606 [I7.RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 607 Notification", RFC 3798, May 2004. 609 [I8.RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 610 Negotiation for Messaging Services based on Email", 611 RFC 3297, July 2002. 613 [I9.RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 614 Mapping between X.400 and RFC 822/MIME", RFC 2156, 615 January 1998. 617 [I10.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message 618 Format for Delivery Status Notifications", RFC 3464, 619 January 2003. 621 [I11.RFC987] Kille, S., "Mapping between X.400 and RFC 822", 622 RFC 987, June 1986. 624 [I12.Errata] RFC-Editor errata page, 625 http://www.rfc-editor.org/errata.html 627 [I13.RFC2533] Klyne, G., "A Syntax for Describing Media Feature 628 Sets", RFC 2533, March 1999. 630 [I14.RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 631 "Uniform Resource Identifier (URI): Generic Syntax", 632 STD 66, RFC 3986, January 2005. 634 [I15.RFC1958] Carpenter, B., "Architectural Principles of the 635 Internet", RFC 1958, June 1996. 637 [I16.RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 638 Considered Useful", BCP 82, RFC 3692, January 2004. 640 [I17.RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 641 Extensions) Part Three: Message Header Extensions for 642 Non-ASCII Text", RFC 2047, November 1996. 644 [I18.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and 645 Encoded Word Extensions: Character Sets, Languages, and 646 Continuations", RFC 2231, November 1997. 648 [I19.Syntax] Carpenter, B., "Syntax for format definitions", 649 http://ietf.org/IESG/STATEMENTS/syntax-format-def.txt 651 [I20.Arch] Crocker, D., "Internet Mail Architecture" 652 (draft-crocker-email-arch-04.txt), March 2005. 654 [I21.BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 655 Text on Security Considerations", BCP 72, RFC 3552, 656 July 2003. 658 Author's Address 660 Bruce Lilly 662 Email: blilly@erols.com 664 Full Copyright Statement 666 Copyright (C) The Internet Society (2005). 668 This document is subject to the rights, licenses and restrictions 669 contained in BCP 78, and except as set forth therein, the authors 670 retain all their rights. 672 This document and the information contained herein are provided on an 673 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 674 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 675 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 676 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 677 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 678 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 680 Intellectual Property Statement 682 The IETF takes no position regarding the validity or scope of any 683 Intellectual Property Rights or other rights that might be claimed to 684 pertain to the implementation or use of the technology described in 685 this document or the extent to which any license under such rights 686 might or might not be available; nor does it represent that it has 687 made any independent effort to identify any such rights. Information 688 on the procedures with respect to rights in RFC documents can be 689 found in BCP 78 and BCP 79. 691 Copies of IPR disclosures made to the IETF Secretariat and any 692 assurances of licenses to be made available, or the result of an 693 attempt made to obtain a general license or permission for the use of 694 such proprietary rights by implementers or users of this 695 specification can be obtained from the IETF on-line IPR repository at 696 http://www.ietf.org/ipr. 698 The IETF invites any interested party to bring to its attention any 699 copyrights, patents or patent applications, or other proprietary 700 rights that may cover technology that may be required to implement 701 this standard. Please address the information to the IETF at 702 ietf-ipr@ietf.org. 704 Acknowledgment 706 Funding for the RFC Editor function is currently provided by the 707 Internet Society.