| < draft-ietf-appsawg-media-type-regs-13.txt | draft-ietf-appsawg-media-type-regs-14.txt > | |||
|---|---|---|---|---|
| Network Working Group N. Freed | Network Working Group N. Freed | |||
| Internet-Draft Oracle | Internet-Draft Oracle | |||
| Obsoletes: 4288 (if approved) J. Klensin | Obsoletes: 4288 (if approved) J. Klensin | |||
| Intended status: BCP | Intended status: BCP | |||
| Expires: December 14, 2012 T. Hansen | Expires: December 22, 2012 T. Hansen | |||
| AT&T Laboratories | AT&T Laboratories | |||
| June 12, 2012 | June 20, 2012 | |||
| Media Type Specifications and Registration Procedures | Media Type Specifications and Registration Procedures | |||
| draft-ietf-appsawg-media-type-regs-13 | draft-ietf-appsawg-media-type-regs-14 | |||
| Abstract | Abstract | |||
| This document defines procedures for the specification and | This document defines procedures for the specification and | |||
| registration of media types for use in HTTP, MIME and other Internet | registration of media types for use in HTTP, MIME and other Internet | |||
| protocols. | protocols. | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on December 14, 2012. | This Internet-Draft will expire on December 22, 2012. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 4, line 44 ¶ | skipping to change at page 4, line 44 ¶ | |||
| registering media types for use in the context of the asynchronous | registering media types for use in the context of the asynchronous | |||
| Internet mail environment. In this mail environment there is a need | Internet mail environment. In this mail environment there is a need | |||
| to limit the number of possible media types, to increase the | to limit the number of possible media types, to increase the | |||
| likelihood of interoperability when the capabilities of the remote | likelihood of interoperability when the capabilities of the remote | |||
| mail system are not known. As media types are used in new | mail system are not known. As media types are used in new | |||
| environments in which the proliferation of media types is not a | environments in which the proliferation of media types is not a | |||
| hindrance to interoperability, the original procedure proved | hindrance to interoperability, the original procedure proved | |||
| excessively restrictive and had to be generalized. This was | excessively restrictive and had to be generalized. This was | |||
| initially done in [RFC2048], but the procedure defined there was | initially done in [RFC2048], but the procedure defined there was | |||
| still part of the MIME document set. The media type specification | still part of the MIME document set. The media type specification | |||
| and registration procedure has now been moved to this separate | and registration procedure is now a separate document, to make it | |||
| document, to make it clear that it is independent of MIME. | clear that it is independent of MIME. | |||
| It may be desirable to restrict the use of media types to specific | It may be desirable to restrict the use of media types to specific | |||
| environments or to prohibit their use in other environments. This | environments or to prohibit their use in other environments. This | |||
| revision incorporates such restrictions into media type registrations | specification incorporates such restrictions into media type | |||
| in a systematic way. See Section 4.9 for additional discussion. | registrations in a systematic way. See Section 4.9 for additional | |||
| discussion. | ||||
| 1.2. Conventions Used in This Document | 1.2. Conventions Used in This Document | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC2119] when they | document are to be interpreted as described in [RFC2119] when they | |||
| appear in ALL CAPS. They may also appear in lower or mixed case as | appear in ALL CAPS. They may also appear in lower or mixed case as | |||
| plain English words, without any normative meaning. | plain English words, without any normative meaning. | |||
| This specification makes use of the Augmented Backus-Naur Form (ABNF) | This specification makes use of the Augmented Backus-Naur Form (ABNF) | |||
| skipping to change at page 5, line 37 ¶ | skipping to change at page 5, line 37 ¶ | |||
| 3. Registration Trees and Subtype Names | 3. Registration Trees and Subtype Names | |||
| In order to increase the efficiency and flexibility of the | In order to increase the efficiency and flexibility of the | |||
| registration process, different structures of subtype names can be | registration process, different structures of subtype names can be | |||
| registered to accommodate the different natural requirements for, | registered to accommodate the different natural requirements for, | |||
| e.g., a subtype that will be recommended for wide support and | e.g., a subtype that will be recommended for wide support and | |||
| implementation by the Internet community, or a subtype that is used | implementation by the Internet community, or a subtype that is used | |||
| to move files associated with proprietary software. The following | to move files associated with proprietary software. The following | |||
| subsections define registration "trees" that are distinguished by the | subsections define registration "trees" that are distinguished by the | |||
| use of faceted names, e.g., names of the form | use of faceted names, e.g., subtype names that begin with a a "tree." | |||
| "tree.subtree...subtype". Note that some media types defined prior | prefix. Note that some media types defined prior to this document do | |||
| to this document do not conform to the naming conventions described | not conform to the naming conventions described below. See Appendix | |||
| below. See Appendix A for a discussion of them. | A for a discussion of them. | |||
| 3.1. Standards Tree | 3.1. Standards Tree | |||
| The standards tree is intended for types of general interest to the | The standards tree is intended for types of general interest to the | |||
| Internet community. Registrations in the standards tree MUST be | Internet community. Registrations in the standards tree MUST be | |||
| either: | either: | |||
| 1. in the case of registrations in IETF specifications, approved | 1. in the case of registrations in IETF specifications, approved | |||
| directly by the IESG, or | directly by the IESG, or | |||
| skipping to change at page 6, line 39 ¶ | skipping to change at page 6, line 39 ¶ | |||
| Media types in the standards tree MUST NOT have faceted names, unless | Media types in the standards tree MUST NOT have faceted names, unless | |||
| they are grandfathered in using the process described in Appendix A. | they are grandfathered in using the process described in Appendix A. | |||
| The "owner" of a media type registered in the standards tree is | The "owner" of a media type registered in the standards tree is | |||
| assumed to be the standards body itself. Modification or alteration | assumed to be the standards body itself. Modification or alteration | |||
| of the specification uses the same level of processing (e.g., a | of the specification uses the same level of processing (e.g., a | |||
| registration submitted on Standards Track can be revised in another | registration submitted on Standards Track can be revised in another | |||
| Standards Track RFC, but cannot be revised in an Informational RFC) | Standards Track RFC, but cannot be revised in an Informational RFC) | |||
| required for the initial registration. | required for the initial registration. | |||
| Standards-tree registrations from recognized standards bodies may be | Standards-tree registrations from recognized standards bodies are | |||
| submitted directly to the IANA, where they will undergo Expert Review | submitted directly to the IANA, where they will undergo Expert Review | |||
| [RFC5226] prior to approval. In this case, the Expert Reviewer(s) | [RFC5226] prior to approval. In this case, the Expert Reviewer(s) | |||
| will, among other things, ensure that the required specification | will, among other things, ensure that the required specification | |||
| provides adequate documentation. | provides adequate documentation. | |||
| 3.2. Vendor Tree | 3.2. Vendor Tree | |||
| The vendor tree is used for media types associated with publicly | The vendor tree is used for media types associated with publicly | |||
| available products. "Vendor" and "producer" are construed very | available products. "Vendor" and "producer" are construed very | |||
| broadly in this context and are considered equivalent. Note that | broadly in this context and are considered equivalent. Note that | |||
| skipping to change at page 8, line 18 ¶ | skipping to change at page 8, line 18 ¶ | |||
| intended exclusively for use in private, local environments. Types | intended exclusively for use in private, local environments. Types | |||
| in this tree cannot be registered and are intended for use only with | in this tree cannot be registered and are intended for use only with | |||
| the active agreement of the parties exchanging them. | the active agreement of the parties exchanging them. | |||
| However, with the simplified registration procedures described above | However, with the simplified registration procedures described above | |||
| for vendor and personal trees, it should rarely, if ever, be | for vendor and personal trees, it should rarely, if ever, be | |||
| necessary to use unregistered types. Therefore, use of types in the | necessary to use unregistered types. Therefore, use of types in the | |||
| "x." tree is strongly discouraged. | "x." tree is strongly discouraged. | |||
| Note that types with names beginning with "x-" are no longer | Note that types with names beginning with "x-" are no longer | |||
| considered to members of this tree (see [I-D.ietf-appsawg-xdash]). | considered to be members of this tree (see [I-D.ietf-appsawg-xdash]). | |||
| Also note that if a generally useful and widely deployed type | Also note that if a generally useful and widely deployed type | |||
| incorrectly ends up with an "x-" name prefix, it MAY be registered | incorrectly ends up with an "x-" name prefix, it MAY be registered | |||
| using its current name in an alternate tree by following the | using its current name in an alternate tree by following the | |||
| procedure defined in Appendix A. | procedure defined in Appendix A. | |||
| 3.5. Additional Registration Trees | 3.5. Additional Registration Trees | |||
| From time to time and as required by the community, new top-level | From time to time and as required by the community, new top-level | |||
| registration trees may be created by IETF Standards Action. It is | registration trees may be created by IETF Standards Action. It is | |||
| explicitly assumed that these trees may be created for external | explicitly assumed that these trees may be created for external | |||
| skipping to change at page 10, line 40 ¶ | skipping to change at page 10, line 40 ¶ | |||
| If a "charset" parameter is specified, it SHOULD be a required | If a "charset" parameter is specified, it SHOULD be a required | |||
| parameter, eliminating the options of specifying a default value. If | parameter, eliminating the options of specifying a default value. If | |||
| there is a strong reason for the parameter to be optional despite | there is a strong reason for the parameter to be optional despite | |||
| this advice, each subtype MAY specify its own default value, or | this advice, each subtype MAY specify its own default value, or | |||
| alternately, it MAY specify that there is no default value. Finally, | alternately, it MAY specify that there is no default value. Finally, | |||
| the "UTF-8" charset [RFC3629] SHOULD be selected as the default. See | the "UTF-8" charset [RFC3629] SHOULD be selected as the default. See | |||
| [I-D.ietf-appsawg-mime-default-charset] for additional information on | [I-D.ietf-appsawg-mime-default-charset] for additional information on | |||
| the use of "charset" parameters in conjunction with subtypes of text. | the use of "charset" parameters in conjunction with subtypes of text. | |||
| Regardless of what approach is chosen, all text/* registrations MUST | Regardless of what approach is chosen, all new text/* registrations | |||
| clearly specify how the charset is determined; relying on the US- | MUST clearly specify how the charset is determined; relying on the | |||
| ASCII default defined in Section 4.1.2 of [RFC2046] is no longer | US-ASCII default defined in Section 4.1.2 of [RFC2046] is no longer | |||
| permitted. If explanatory text is needed this SHOULD be placed in | permitted. If explanatory text is needed this SHOULD be placed in | |||
| the additional information section of the registration. | the additional information section of the registration. | |||
| Plain text does not provide for or allow formatting commands, font | Plain text does not provide for or allow formatting commands, font | |||
| attribute specifications, processing instructions, interpretation | attribute specifications, processing instructions, interpretation | |||
| directives, or content markup. Plain text is seen simply as a linear | directives, or content markup. Plain text is seen simply as a linear | |||
| sequence of characters, possibly interrupted by line breaks or page | sequence of characters, possibly interrupted by line breaks or page | |||
| breaks. Plain text MAY allow the stacking of several characters in | breaks. Plain text MAY allow the stacking of several characters in | |||
| the same position in the text. Plain text in scripts like Arabic and | the same position in the text. Plain text in scripts like Arabic and | |||
| Hebrew may also include facilities that allow the arbitrary mixing of | Hebrew may also include facilities that allow the arbitrary mixing of | |||
| skipping to change at page 12, line 42 ¶ | skipping to change at page 12, line 42 ¶ | |||
| rules and other requirements specified in [RFC2046] and amended by | rules and other requirements specified in [RFC2046] and amended by | |||
| Section 3.5 of [RFC6532]. | Section 3.5 of [RFC6532]. | |||
| 4.2.7. Additional Top-level Types | 4.2.7. Additional Top-level Types | |||
| In some cases a new media type may not "fit" under any currently | In some cases a new media type may not "fit" under any currently | |||
| defined top-level type names. Such cases are expected to be quite | defined top-level type names. Such cases are expected to be quite | |||
| rare. However, if such a case does arise a new type name can be | rare. However, if such a case does arise a new type name can be | |||
| defined to accommodate it. Such a definition MUST be done via | defined to accommodate it. Such a definition MUST be done via | |||
| standards-track RFC; no other mechanism can be used to define | standards-track RFC; no other mechanism can be used to define | |||
| additional type name. | additional type names. | |||
| 4.2.8. Structured Syntax Name Suffixes | 4.2.8. Structured Syntax Name Suffixes | |||
| XML in MIME [RFC3023] defined the first such augmentation to the | XML in MIME [RFC3023] defined the first such augmentation to the | |||
| media type definition to additionally specify the underlying | media type definition to additionally specify the underlying | |||
| structure of that media type. To quote: | structure of that media type. To quote: | |||
| This document also standardizes a convention (using the suffix | This document also standardizes a convention (using the suffix | |||
| '+xml') for naming media types ... when those media types | '+xml') for naming media types ... when those media types | |||
| represent XML MIME (Multipurpose Internet Mail Extensions) | represent XML MIME (Multipurpose Internet Mail Extensions) | |||
| skipping to change at page 15, line 35 ¶ | skipping to change at page 15, line 35 ¶ | |||
| specification of a media type is part of a standards-track protocol. | specification of a media type is part of a standards-track protocol. | |||
| In addition, other standards bodies making use of the standards tree | In addition, other standards bodies making use of the standards tree | |||
| may have their own rules regarding intellectual property that must be | may have their own rules regarding intellectual property that must be | |||
| observed in their registrations. | observed in their registrations. | |||
| IPR disclosures for registrations in the vendor and personal tree are | IPR disclosures for registrations in the vendor and personal tree are | |||
| encouraged but not required. | encouraged but not required. | |||
| 4.5. Interchange Recommendations | 4.5. Interchange Recommendations | |||
| Media types SHOULD interoperate across as many systems and | Ideally media types will be defined so they interoperate across as | |||
| applications as possible. However, some media types will inevitably | many systems and applications as possible. However, some media types | |||
| have problems interoperating across different platforms. Problems | will inevitably have problems interoperating across different | |||
| with different versions, byte ordering, and specifics of gateway | platforms. Problems with different versions, byte ordering, and | |||
| handling can and will arise. | specifics of gateway handling can and will arise. | |||
| Universal interoperability of media types is not required, but known | Universal interoperability of media types is not required, but known | |||
| interoperability issues SHOULD be identified whenever possible. | interoperability issues SHOULD be identified whenever possible. | |||
| Publication of a media type does not require an exhaustive review of | Publication of a media type does not require an exhaustive review of | |||
| interoperability, and the interoperability considerations section is | interoperability, and the interoperability considerations section is | |||
| subject to continuing evaluation. | subject to continuing evaluation. | |||
| These recommendations in this subsection apply regardless of the | These recommendations in this subsection apply regardless of the | |||
| registration tree involved. | registration tree involved. | |||
| 4.6. Security Requirements | 4.6. Security Requirements | |||
| An analysis of security issues MUST be done for all types registered | An analysis of security issues MUST be done for all types registered | |||
| in the standards tree. A similar analysis for media types registered | in the standards tree. A similar analysis for media types registered | |||
| in the vendor or personal trees is encouraged but not required. | in the vendor or personal trees is encouraged but not required. | |||
| However, regardless of what security analysis has or has not been | However, regardless of what security analysis has or has not been | |||
| done, all descriptions of security issues MUST be as accurate as | done, all descriptions of security issues MUST be as accurate as | |||
| possible regardless of registration tree. In particular, a statement | possible regardless of registration tree. In particular, the | |||
| that there are "no security issues associated with this type" MUST | security considerations MUST NOT state that there are "no security | |||
| NOT be confused with "the security issues associates with this type | issues associated with this type". Security considerations for types | |||
| have not been assessed". | in the vendor or personal tree MAY say that "the security issues | |||
| associates with this type have not been assessed". | ||||
| There is absolutely no requirement that media types registered in any | There is absolutely no requirement that media types registered in any | |||
| tree be secure or completely free from risks. Nevertheless, all | tree be secure or completely free from risks. Nevertheless, all | |||
| known security risks MUST be identified in the registration of a | known security risks MUST be identified in the registration of a | |||
| media type, again regardless of registration tree. | media type, again regardless of registration tree. | |||
| The security considerations section of all registrations is subject | The security considerations section of all registrations is subject | |||
| to continuing evaluation and modification, and in particular MAY be | to continuing evaluation and modification, and in particular MAY be | |||
| extended by use of the "comments on media types" mechanism described | extended by use of the "comments on media types" mechanism described | |||
| in Section 5.4 below. | in Section 5.4 below. | |||
| skipping to change at page 25, line 17 ¶ | skipping to change at page 25, line 17 ¶ | |||
| 3. IANA requests Expert Review of the registration request against | 3. IANA requests Expert Review of the registration request against | |||
| the corresponding guidelines. | the corresponding guidelines. | |||
| 4. The Designated Expert may request additional review or | 4. The Designated Expert may request additional review or | |||
| discussion, as necessary. | discussion, as necessary. | |||
| 5. If Expert Review recommends registration, IANA adds the | 5. If Expert Review recommends registration, IANA adds the | |||
| registration to the appropriate registry. | registration to the appropriate registry. | |||
| The initial registry content specification | ||||
| [I-D.appsawg-media-type-suffix-regs] provides examples of structured | ||||
| syntax suffix registrations. | ||||
| 6.1. Change Procedures | 6.1. Change Procedures | |||
| Registrations may be updated in each registry by the same mechanism | Registrations may be updated in each registry by the same mechanism | |||
| as required for an initial registration. In cases where the original | as required for an initial registration. In cases where the original | |||
| definition of the scheme is contained in an IESG-approved document, | definition of the scheme is contained in an IESG-approved document, | |||
| update of the specification also requires IESG approval. | update of the specification also requires IESG approval. | |||
| 6.2. Structured Syntax Suffix Registration Template | 6.2. Structured Syntax Suffix Registration Template | |||
| This template describes the fields that must be supplied in a | This template describes the fields that must be supplied in a | |||
| End of changes. 14 change blocks. | ||||
| 27 lines changed or deleted | 33 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||