idnits 2.17.1 draft-freed-mime-p4-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 459. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2048, but the abstract doesn't seem to mention this, which it should. 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.) -- The document date (August 5, 2005) is 6832 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) == Unused Reference: 'RFC3023' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC2048' is defined on line 388, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 2048 (Obsoleted by RFC 4288, RFC 4289) -- Obsolete informational reference (is this intentional?): RFC 2278 (Obsoleted by RFC 2978) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Freed 3 Internet-Draft Sun Microsystems 4 Obsoletes: 2048 (if approved) J. Klensin 5 Expires: February 6, 2006 August 5, 2005 7 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration 8 Procedures 9 draft-freed-mime-p4-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 6, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies IANA registration procedures for MIME 43 external body access types and content-transfer-encodings. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Conventions Used In This Document . . . . . . . . . . . . 3 49 2. External Body Access Types . . . . . . . . . . . . . . . . . . 4 50 2.1 Registration Requirements . . . . . . . . . . . . . . . . 4 51 2.1.1 Naming Requirements . . . . . . . . . . . . . . . . . 4 52 2.1.2 Mechanism Specification Requirements . . . . . . . . . 4 53 2.1.3 Publication Requirements . . . . . . . . . . . . . . . 4 54 2.1.4 Security Requirements . . . . . . . . . . . . . . . . 4 55 2.2 Registration Procedure . . . . . . . . . . . . . . . . . . 5 56 2.2.1 Present the Access Type to the Community . . . . . . . 5 57 2.2.2 Access Type Reviewer . . . . . . . . . . . . . . . . . 5 58 2.2.3 IANA Registration . . . . . . . . . . . . . . . . . . 5 59 2.3 Location of Registered Access Type List . . . . . . . . . 5 60 2.4 IANA Procedures for Registering Access Types . . . . . . . 5 61 3. Transfer Encodings . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1 Transfer Encoding Requirements . . . . . . . . . . . . . . 7 63 3.1.1 Naming Requirements . . . . . . . . . . . . . . . . . 7 64 3.1.2 Algorithm Specification Requirements . . . . . . . . . 7 65 3.1.3 Input Domain Requirements . . . . . . . . . . . . . . 8 66 3.1.4 Output Range Requirements . . . . . . . . . . . . . . 8 67 3.1.5 Data Integrity and Generality Requirements . . . . . . 8 68 3.1.6 New Functionality Requirements . . . . . . . . . . . . 8 69 3.1.7 Security Requirements . . . . . . . . . . . . . . . . 8 70 3.2 Transfer Encoding Definition Procedure . . . . . . . . . . 9 71 3.3 IANA Procedures for Transfer Encoding Registration . . . . 9 72 3.4 Location of Registered Transfer Encodings List . . . . . . 9 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 7.1 Normative References . . . . . . . . . . . . . . . . . . . 13 78 7.2 Informative References . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 80 A. Changes made since RFC 2048 . . . . . . . . . . . . . . . . . 15 81 Intellectual Property and Copyright Statements . . . . . . . . 16 83 1. Introduction 85 Recent Internet protocols have been carefully designed to be easily 86 extensible in certain areas. In particular, MIME [RFC2045] is an 87 open-ended framework and can accommodate additional object types, 88 charsets, and access methods without any changes to the basic 89 protocol. A registration process is needed, however, to ensure that 90 the set of such values is developed in an orderly, well-specified, 91 and public manner. 93 This document defines registration procedures which use the Internet 94 Assigned Numbers Authority (IANA) as a central registry for such 95 values. 97 Note 99 Registration of media types and charsets for use in MIME are now 100 specified in separate documents and are no longer addressed here. 102 1.1 Conventions Used In This Document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. External Body Access Types 110 [RFC2046] defines the message/external-body media type, whereby a 111 MIME entity can act as pointer to the actual body data in lieu of 112 including the data directly in the entity body. Each message/ 113 external-body reference specifies an access type, which determines 114 the mechanism used to retrieve the actual body data. RFC 2046 115 defines an initial set of access types, but allows for the 116 registration of additional access types to accommodate new retrieval 117 mechanisms. 119 2.1 Registration Requirements 121 New access type specifications MUST conform to a number of 122 requirements as described below. 124 2.1.1 Naming Requirements 126 Each access type MUST have a unique name. This name appears in the 127 access-type parameter in the message/external-body content-type 128 header field, and MUST conform to MIME content type parameter syntax. 130 2.1.2 Mechanism Specification Requirements 132 All of the protocols, transports, and procedures used by a given 133 access type MUST be described, either in the specification of the 134 access type itself or in some other publicly available specification, 135 in sufficient detail for the access type to be implemented by any 136 competent implementor. Use of secret and/or proprietary methods in 137 access types is expressly prohibited. The restrictions imposed by 138 [RFC2026] on the standardization of patented algorithms must be 139 respected as well. 141 2.1.3 Publication Requirements 143 All access types MUST be described by an RFC. The RFC may be 144 informational rather than standards-track, although standard-track 145 review and approval are encouraged for all access types. 147 2.1.4 Security Requirements 149 Any known security issues that arise from the use of the access type 150 MUST be completely and fully described. It is not required that the 151 access type be secure or that it be free from risks, but that the 152 known risks be identified. Publication of a new access type does not 153 require an exhaustive security review, and the security 154 considerations section is subject to continuing evaluation. 155 Additional security considerations SHOULD be addressed by publishing 156 revised versions of the access type specification. 158 2.2 Registration Procedure 160 Registration of a new access type starts with the the publication of 161 the specification as an internet-draft. 163 2.2.1 Present the Access Type to the Community 165 Send a proposed access type specification to the 166 "ietf-types@iana.org" mailing list for a two week review period. 167 This mailing list has been established for the purpose of reviewing 168 proposed access and media types. Proposed access types are not 169 formally registered and must not be used. 171 The intent of the public posting is to solicit comments and feedback 172 on the access type specification and a review of any security 173 considerations. 175 2.2.2 Access Type Reviewer 177 When the two week period has passed, the access type reviewer, who is 178 appointed by the IETF Applications Area Director(s), either forwards 179 the request to iana@iana.org, or rejects it because of significant 180 objections raised on the list. 182 Decisions made by the reviewer must be posted to the ietf-types 183 mailing list within 14 days. Decisions made by the reviewer may be 184 appealed to the IESG as specified in [RFC2026]. 186 2.2.3 IANA Registration 188 Provided that the access type has either passed review or has been 189 successfully appealed to the IESG, the IANA will register the access 190 type and make the registration available to the community. The 191 specification of the access type must also be published as an RFC. 193 2.3 Location of Registered Access Type List 195 Access type registrations are listed by the IANA on the web page: 197 http://www.iana.org/assignments/access-types 199 2.4 IANA Procedures for Registering Access Types 201 The identity of the access type reviewer is communicated to the IANA 202 by the IESG. The IANA then only acts in response to access type 203 definitions that either are approved by the access type reviewer and 204 forwarded by the reviewer to the IANA for registration, or in 205 response to a communication from the IESG that an access type 206 definition appeal has overturned the access type reviewer's ruling. 208 3. Transfer Encodings 210 Transfer encodings are tranformations applied to MIME media types 211 after conversion to the media type's canonical form. Transfer 212 encodings are used for several purposes: 214 o Many transports, especially message transports, can only handle 215 data consisting of relatively short lines of text. There can also 216 be severe restrictions on what characters can be used in these 217 lines of text -- some transports are restricted to a small subset 218 of US-ASCII and others cannot handle certain character sequences. 219 Transfer encodings are used to transform binary data into textual 220 form that can survive such transports. Examples of this sort of 221 transfer encoding include the base64 and quoted-printable transfer 222 encodings defined in [RFC2045]. 224 o Image, audio, video, and even application entities are sometimes 225 quite large. Compression algorithms are often quite effective in 226 reducing the size of large entities. Transfer encodings can be 227 used to apply general-purpose non-lossy compression algorithms to 228 MIME entities. 230 o Transport encodings can be defined as a means of representing 231 existing encoding formats in a MIME context. 233 IMPORTANT: The standardization of a large numbers of different 234 transfer encodings is seen as a significant barrier to widespread 235 interoperability and is expressely discouraged. Nevertheless, the 236 following procedure has been defined to provide a means of defining 237 additional transfer encodings, should standardization actually be 238 justified. 240 3.1 Transfer Encoding Requirements 242 Transfer encoding specifications MUST conform to a number of 243 requirements as described below. 245 3.1.1 Naming Requirements 247 Each transfer encoding MUST have a unique name. This name appears in 248 the Content-Transfer-Encoding header field and MUST conform to the 249 syntax of that field. 251 3.1.2 Algorithm Specification Requirements 253 All of the algorithms used in a transfer encoding (e.g., conversion 254 to printable form, compression) MUST be described in their entirety 255 in the transfer encoding specification. Use of secret and/or 256 proprietary algorithms in standardized transfer encodings is 257 expressly prohibited. The restrictions imposed by [RFC2026] on the 258 standardization of patented algorithms MUST be respected as well. 260 3.1.3 Input Domain Requirements 262 All transfer encodings MUST be applicable to an arbitrary sequence of 263 octets of any length. Dependence on particular input forms is not 264 allowed. 266 It should be noted that the 7bit and 8bit encodings do not conform to 267 this requirement. Aside from the undesireability of having 268 specialized encodings, the intent here is to forbid the addition of 269 additional encodings similar to or redundant with 7bit and 8bit. 271 3.1.4 Output Range Requirements 273 There is no requirement that a particular tranfer encoding produce a 274 particular form of encoded output. However, the output format for 275 each transfer encoding MUST be fully and completely documented. In 276 particular, each specification MUST clearly state whether the output 277 format always lies within the confines of 7bit data, 8bit data, or is 278 simply pure binary data. 280 3.1.5 Data Integrity and Generality Requirements 282 All transfer encodings MUST be fully invertible on any platform; it 283 MUST be possible for anyone to recover the original data by 284 performing the corresponding decoding operation. Note that this 285 requirement effectively excludes all forms of lossy compression as 286 well as all forms of encryption from use as a transfer encoding. 288 3.1.6 New Functionality Requirements 290 All transfer encodings MUST provide some sort of new functionality. 291 Some degree of functionality overlap with previously defined transfer 292 encodings is acceptable, but any new transfer encoding MUST also 293 offer something no other transfer encoding provides. 295 3.1.7 Security Requirements 297 To the greatest extent possible transfer encodings SHOULD NOT contain 298 known security issues. Regardless, any known security issues that 299 arise from the use of the transfer encoding MUST be completely and 300 fully described. If additional security issues come to light after 301 initial publication and registration they SHOULD be addressed by 302 publishing revised versions of the transfer encoding pecification. 304 3.2 Transfer Encoding Definition Procedure 306 Definition of a new transfer encoding starts with the the publication 307 of the specification as an internet-draft. The draft MUST define the 308 transfer encoding precisely and completely, and MUST also provide 309 substantial justification for defining and standardizing a new 310 transfer encoding. This specification MUST then be presented to the 311 IESG for consideration. The IESG can 313 o reject the specification outright as being inappropriate for 314 standardization, 316 o assign the specification to an existing IETF working group for 317 further work, 319 o approve the formation of an IETF working group to work on the 320 specification in accordance with IETF procedures, or, 322 o accept the specification as-is for processing as an individual 323 standards track submission. 325 Transfer encoding specifications on the standards track follow normal 326 IETF rules for standards track documents. A transfer encoding is 327 considered to be defined and available for use once it is on the 328 standards track. 330 3.3 IANA Procedures for Transfer Encoding Registration 332 There is no need for a special procedure for registering Transfer 333 Encodings with the IANA. All legitimate transfer encoding 334 registrations MUST appear as a standards-track RFC, so it is the 335 IESG's responsibility to notify the IANA when a new transfer encoding 336 has been approved. 338 3.4 Location of Registered Transfer Encodings List 340 The list of transfer encoding registrations can be found at: 342 http://www.iana.org/assignments/transfer-encodings 344 4. Security Considerations 346 Security requirements for access types are discussed in 347 Section 2.1.4. Security requirements for transfer encodings are 348 discussed in Section 3.1.7. 350 5. IANA Considerations 352 The sole purpose of this document is to define IANA registries for 353 access types and transfer encodings. The IANA procedures for these 354 registries are specified in Section 2.4 and Section 3.3 respectively. 356 6. Acknowledgements 358 The current authors would like to acknowledge their debt to the late 359 Dr. Jon Postel, whose general model of IANA registration procedures 360 and specific contributions shaped the predecessors of this document. 361 We hope that the current version is one with which he would have 362 agreed but, since it is impossible to verify that agreement, we have 363 regretfully removed his name as a co-author. 365 7. References 367 7.1 Normative References 369 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 370 Extensions (MIME) Part One: Format of Internet Message 371 Bodies", RFC 2045, November 1996. 373 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 374 Extensions (MIME) Part Two: Media Types", RFC 2046, 375 November 1996. 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, March 1997. 380 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 381 Types", RFC 3023, January 2001. 383 7.2 Informative References 385 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 386 3", BCP 9, RFC 2026, October 1996. 388 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 389 Internet Mail Extensions (MIME) Part Four: Registration 390 Procedures", BCP 13, RFC 2048, November 1996. 392 [RFC2278] Freed, N. and J. Postel, "IANA Charset Registration 393 Procedures", BCP 19, RFC 2278, January 1998. 395 Authors' Addresses 397 Ned Freed 398 Sun Microsystems 399 3401 Centrelake Drive, Suite 410 400 Ontario, CA 92761-1205 401 USA 403 Phone: +1 909 457 4293 404 Email: ned.freed@mrochek.com 405 John C Klensin 406 1770 Massachusetts Ave, #322 407 Cambridge, MA 02140 409 Email: klensin@jck.com 411 Appendix A. Changes made since RFC 2048 413 o Media type registration procedures are now described in a separate 414 document. 416 o The various URLs and addresses in this document have been changed 417 so they all refer to iana.org rather than isi.edu. Additionally, 418 many of the URLs have been changed to use HTTP; formerly they used 419 FTP. 421 o Much of the document has been clarified in the light of 422 operational experience with these procedures. 424 o Several of the references in this document have been updated to 425 refer to current versions of the relevant specifications. 427 o The option of assigning the task of working on a new transfer 428 encoding to an existing working group has been added to the list 429 of possible actions the IESG can take. 431 o Security considerations and IANA considerations sections have been 432 added. 434 o Registration of charsets for use in MIME is specified in [RFC2278] 435 and is no longer addressed by this document. 437 Intellectual Property Statement 439 The IETF takes no position regarding the validity or scope of any 440 Intellectual Property Rights or other rights that might be claimed to 441 pertain to the implementation or use of the technology described in 442 this document or the extent to which any license under such rights 443 might or might not be available; nor does it represent that it has 444 made any independent effort to identify any such rights. Information 445 on the procedures with respect to rights in RFC documents can be 446 found in BCP 78 and BCP 79. 448 Copies of IPR disclosures made to the IETF Secretariat and any 449 assurances of licenses to be made available, or the result of an 450 attempt made to obtain a general license or permission for the use of 451 such proprietary rights by implementers or users of this 452 specification can be obtained from the IETF on-line IPR repository at 453 http://www.ietf.org/ipr. 455 The IETF invites any interested party to bring to its attention any 456 copyrights, patents or patent applications, or other proprietary 457 rights that may cover technology that may be required to implement 458 this standard. Please address the information to the IETF at 459 ietf-ipr@ietf.org. 461 Disclaimer of Validity 463 This document and the information contained herein are provided on an 464 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 465 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 466 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 467 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 468 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 469 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 471 Copyright Statement 473 Copyright (C) The Internet Society (2005). This document is subject 474 to the rights, licenses and restrictions contained in BCP 78, and 475 except as set forth therein, the authors retain all their rights. 477 Acknowledgment 479 Funding for the RFC Editor function is currently provided by the 480 Internet Society.