Re: I-D ACTION:draft-iesg-media-type-00.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 31 May 2005, at 20:50, Internet-Drafts@xxxxxxxx wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Engineering Steering Group Working Group of the IETF.

    Title        : A question on Media Type Registrations
    Author(s)    : T. Hardie
    Filename    : draft-iesg-media-type-00.txt
    Pages        : 9
    Date        : 2005-5-31

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.

The idea of using the MIME media types registry to identify types that are carried predominantly by RTP was suggested at a meeting of the AVT working group, with participation from the applications area directors, in December 1997 [1]. The subject was discussed at several following meetings, with an initial internet-draft being submitted in February 1999 [2]. A later draft was reviewed on the <ietf- types@xxxxxxxx> mailing list [3], and eventually published as RFC 3555. At present, there are 71 media types registered for use predominantly with RTP. These media types are widely used in the voice over IP and media streaming communities, signalled within SIP and RTSP.

There has recently been concern expressed in some quarters about the use of media under the "text" top level media type within RTP. In particular, the update to RFC 2793 for Draft Standard RFC status was contentious, although it used the same text media type within RTP framing as the original RFC. Much of the concern seems to stem from the use of framed text media types, where the plain text media data is embedded within some binary wrapper for transport, since there is a belief that such data might "leak" into areas which don't understand the transport protocol in which the data is framed.

I do not find this argument persuasive, since the media types in question have been deliberately specified as framed types to avoid this issue. The types are defined only in terms of transport within RTP, and rely heavily on RTP framing and knowledge of the transport protocol. An implementation that does not understand RTP will be unable to receive the data: the type is simply not defined in a manner that allows implementation independent of the RTP transport protocol. Such framed text media types have been in use for over 5 years now, with no history of problems.

This does not, of course, preclude an incorrect implementation producing data in some unspecified format which it labels with the media type of one of these framed formats, and transmits within some other transport protocol. The receiver of such data would clearly have to be robust in the face of the malformed content, but that robustness is needed whether or not framed media types exist. Indeed, reliance on the property that unknown text formats can be treated as "text/plain" and displayed directly to the user would seem to be a security risk, unless those formats are carefully validated as actually containing plain text of an appropriate character set, without malicious control characters. The use of framed media types does not change this property.

With this in mind, I turn to the three possible registry futures presented in draft-iesg-media-type-00.txt. The second and third proposals in section 2 of the draft ("MIME handling is the model for other using protocols" and "Registry split") are both large and backwards incompatible changes. Either change would register the 71 existing media types defined primarily for use with RTP framing obsolete. These changes would require significant amounts of new standards work, and would cause enormous confusion for users of RTP payload formats and SDP. It would also affect the extremely large deployed base of implementations. I see no benefit from either of these changes, and many disadvantages.

The other option, "All media type protocols may specify handling", is the status quo. I believe this is the appropriate direction for the registry, although clarifications should be made to the registration rules, perhaps updating RFC 3555, to better explain how framed types are used. There are well defined and tested procedures for registering media types, an extremely large deployed base, and no history of problems with this approach.

The media types registry works well as currently specified. We have a large installed base, and well developed procedures. I do not believe it would be appropriate to make fundamental changes to these procedures or the registry at this late stage.

Colin




[1] Minutes of AVT working group at the 40th IETF

[2] P. Hoschka, "MIME Type Registration of RTP Payload Types", February 1999, draft-hoschka-rtp-mime-00.txt.

[3] Steve Casner, "Registration of RTP payload format names", message to the <ietf-types@xxxxxxxx> mailing list, 20 October 1999. Message ID: <Pine.WNT.4.10.9910201144190.494-100000@xxxxxxxxxxxxxxxxxxx>



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]