[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Nits]
Versions: 00                                                            
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]