Network Working Group T. Hardie Internet-Draft Qualcomm, Inc. Expires: November 25, 2005 Editor A question on Media Type Registrations draft-iesg-media-type-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 17, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document poses a question to the community on the future of the IANA Media Type Registry. It presents three potential future courses of development and asks that feedback on these be provided to the IESG. Hardie Expires November 17, 2005 [Page 1] Internet-Draft Media-Type-Registry May 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Possible Registry Futures . . . . . . . . . . . . . . . . . . 5 2.1 All media type protocols may specify handling. . . . . . . 5 2.2 MIME handling is the model for other using protocols . . . 5 2.3 Registry split . . . . . . . . . . . . . . . . . . . . . . 5 3. Comments solicitied . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Hardie Expires November 17, 2005 [Page 2] Internet-Draft Media-Type-Registry May 2005 1. Introduction The Media type registry currently maintained by IANA at http://www.iana.org/assignments/media-types/ was originally developed in order to handle the needs of MIME [2]. It has since expanded to handle media types that are carried primarily by RTP; these RTP payloads do not have MIME boundaries and there are cases in which the formats appropriate for RTP cannot be used in traditional MIME contexts. In particular, some of the text types have been contentious because their appearance within a MIME e-mail message would have unexpected results if the MIME parser treated the unknown text type as text/plain. In a recent proposed update to the registration documents draft-freed-media-type-reg-04.txt [1], the authors described the history and aim of the update as follows: "Historical Note The media types registration process was initially defined for the purpose of registering media types for use in the context of the asynchronous Internet mail environment. In this mail environment there is a need to limit the number of possible media types to increase the likelihood of interoperability when the capabilities of the remote mail system are not known. As media types are used in new environments, where the proliferation of media types is not a hindrance to interoperability, the original procedure was excessively restrictive and had to be generalized. This was initially done in RFC2048, but the procedure was still part of the MIME document set. In this revision the media type specification and registration procedure has been moved to this separate document to make it clear it is independent of MIME. It may be desirable to restrict the use of media types to specific environments or to prohibit their use in other environments. This revision attempts for the first time to incorporate such restrictions into media type registrations in a systematic way. See Section 4.9 for additional discussion." It goes on to say in section 4.9: "As such, universal support and implementation of a media type is NOT a requirement for registration. If, however, a media type is explicitly intended for limited use, this MUST be noted in its registration. The "Restrictions on Usage" field is provided for this purpose." The IESG notes that there have been several cases of attempted registration where there was considerable resistance to proposed types where the basic principles of usage by MIME parsers would be violated, even where the "Restrictions on Usage" indicated that the Hardie Expires November 17, 2005 [Page 3] Internet-Draft Media-Type-Registry May 2005 media type was not intended for use by MIME. This has been manifested most recently and most strongly for proposed text media types which cannot be treated as text/plain by a parser attempting to fall back in the face of an unknown text type. This is, of course, in advance of publication of the revision as a BCP, and practice may change after publication. The IESG is concerned, however, that there appears to be a disconnect between the expectations of a community that expects all registrations may be treated similarly and a community that expects protocol-specfic registrations to be able to use rules specific to the using protocol. The IESG would like to solicit further comment on this issue. We put forward the following registry futures as strawmen to prompt discussion, but this document is not intended in this or any revision to create or modify registries; that job is left to BCP candidates that have gone through the usual IETF processes. Hardie Expires November 17, 2005 [Page 4] Internet-Draft Media-Type-Registry May 2005 2. Possible Registry Futures 2.1 All media type protocols may specify handling. In the simplest future, this registry retains the current structure and the registration document as currently written becomes a BCP. The IESG expects that in this case registrations written with usage limitations may indicate protocol handling that varies from that originally associated with MIME and the MIME-based registrations. In the text case, for example, a using protocol like RTP could have a text type not appropriate for direct display to a user. If the handling is general, rather than specific to a registration, a document discussing that using protocol's relationship to the registration may be written; an updated RFC 3555 [3], for example, might serve this purpose. 2.2 MIME handling is the model for other using protocols In this future, the registry retains the current structure, and the registration document remains largely the same, but there is a more explicit statement that all using protocols registering media types must use them in ways consonant with the handling by MIME. Any request for registration for which the media type could not be passed with minimal change to a MIME parser would be denied. The registrations would still retain "Usage Limitation" sections, but these could only restrict, not modify, MIME usage. 2.3 Registry split In this future, the registry is reverted to a pure MIME registry; other protocols could re-use types that MIME uses but could not propose new types without describing them as part of MIME. A second or multiple other registries are created with their own registration documents and rules. IANA and the registry reviewers would maintain a policy to avoid collisions between the registries, but there would be no other interconnect. Hardie Expires November 17, 2005 [Page 5] Internet-Draft Media-Type-Registry May 2005 3. Comments solicitied Comments on this document should be sent to iesg@ietf.org or to ietf@ietf.org. The IESG will consider responses at least until July 1, 2005. Hardie Expires November 17, 2005 [Page 6] Internet-Draft Media-Type-Registry May 2005 4. Security Considerations This document poses a question to the community and does not specify a protocol subject to attack. Hardie Expires November 17, 2005 [Page 7] Internet-Draft Media-Type-Registry May 2005 5. IANA Considerations This document has no IANA considerations of its own, though it may affect documents that govern registrations in own or more IANA registries. 6. Normative References [1] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", draft-freed-media-type-reg-04 (work in progress), April 2005. [2] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [3] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003. Editor's Address Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Campbell, CA USA Email: hardie@qualcomm.com Hardie Expires November 17, 2005 [Page 8] Internet-Draft Media-Type-Registry May 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hardie Expires November 17, 2005 [Page 9]