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

On 31 May 2005, at 20:50, Internet-Drafts(_at_)ietf(_dot_)org 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(_at_)iana(_dot_)org> 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(_at_)iana(_dot_)org> mailing list, 20 October 1999. Message  
ID: <Pine(_dot_)WNT(_dot_)4(_dot_)10(_dot_)9910201144190(_dot_)494-100000(_at_)casner-pc(_dot_)cisco(_dot_)com>


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf