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