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]