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

From: Colin Perkins <[email-masked]>
Date: Fri, 1 Jul 2005 12:57:15 +0100

On 31 May 2005, at 20:50, [email-masked] 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- 
[email-masked]> 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 <[email-masked]> mailing list, 20 October 1999. Message  
ID: <[email-masked]>

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Robert Elz <[email-masked]>
Date: Fri, 01 Jul 2005 20:02:04 +0700

Date:        Fri, 1 Jul 2005 12:57:15 +0100
    From:        Colin Perkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | I do not find this argument persuasive, since the media types in  
  | question have been deliberately specified as framed types to avoid  
  | this issue.

I believe that you're both seeing, and missing the point, at the
same time there.

I'd expect that much of the problem is that media types should
depend upon the data that is carried, and how that is to be represented,
and should not depend in any way upon the mechanism used to carry them.

Some of the objections may have been from people who simply assumed that,
and could not believe that a parameter that is intended to specify the
format of data was instead (or additionally) being used to specify a
format for the transport protocol used to carry the data, or being linked
to such a thing.

It is simply the wrong parameter to be using for that purpose.

For example, if I receive an RTP stream carrying a text/whatever, and
store the content (unchanged, but removed from its RTP transport) into a
file, what media type do I use to identify the file?   If it remains
text/whatever (same value) then it will appear as that when I send it
via e-mail, or a web browser fetches it.   If it isn't to be text/whatever
then what on earth is it?   Something random and unidentified?  If there
is a media type for it, that is what should be being used by RTP.

kre

---

From: Colin Perkins <[email-masked]>
Date: Fri, 1 Jul 2005 16:35:53 +0100

> format for the transport protocol used to carry the data, or being  

You're misunderstanding what is being done. The media type does  
specify the format of the data, not of the transport protocol. In  
addition to this, the specification defines how to populate the RTP  
framing based on the implicit properties of the media (e.g. timing).

> is a media type for it, that is what should be being used by RTP.

The media type registrations explain what is to be done. There are  
three possibilities:

1) In some cases, you use the exact same media type for the file  
format as for the RTP payload format, since they contain the same  
data formatted in the same way. I don't believe this is in the least  
controversial.

2) In some cases, the media type registration says "defined only for  
transfer via RTP". This usually means no-one saw the need for a file  
format at the time the registration was done, and didn't spend the  
effort to decide how the media should be stored. This should probably  
be rectified at some point.

3) In some cases, there was a pre-existing file format defined in  
such a way that makes it impossible to use within RTP. This is  
usually the case when the file format requires reliable delivery.  
Since the media format differs in the two cases, they use different  
media types. This case is the controversial case, since it is where  
types may leak outside their domain of applicability.

The question becomes: will the leakage go away if we separate the  
registries? I do not believe it will. People will continue to ignore  
the specifications, and will continue to use names in the wrong  
context. The split will remove one problem (people use the wrong  
media type when converting between RTP and a stored file) and cause  
another (people use the RTP name instead of the MIME media type when  
converting between RTP and a stored file). It's a lot of work, for no  
benefit.

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 01 Jul 2005 17:38:19 +0200

> and should not depend in any way upon the mechanism used to carry them.

My interpretation of what you try to express is that things should be 
have different names when they have different representations, but not 
when they are transported over different protocols.

In response to that I do agree, however RTP is part of the 
representation of data. You can't remove RTP without loosing part of the 
data or converting it into another representation where RTP isn't 
included. I would like to point out that the same RTP payload media 
types are used independently if we send RTP over UDP, DCCP or TCP.

> is a media type for it, that is what should be being used by RTP.

Your first error in this example is the "(unchanged, but removed from 
its RTP transport)" which directly relates to its representation. To 
remove the data from its RTP transport would not be possible without 
conversion. You will have to do some processing going from RTP to a file 
format. To be able to write it as a file you will need a file format. 
That file format will have its own media type that can be used to name 
what you have saved. Thus lets say you have an 3GPP Timed Text media 
stream in its RTP payload format (video/3gpp-tt). This media formats is 
only specified to be stored within a 3GP file (video/3GPP). Thus you 
have to perform a conversion with a clear mapping.

If you wouldn't perform the removal of RTP you could possibly store the 
sequence of RTP packets. However that would be an RTP dump file. That 
file also needs its corresponding configuration data. Otherwise it is 
simply an stream of RTP packets containg something unknown.

So please understand that RTP is part of the representation and it can't 
escape into another representation without deliberate processing. Thus 
defining media types that is explicitly called out as being RTP only and 
being framed does not represent a risk for ending up in a MIME processor 
  unless someone has missused the type. Someting which could just as 
well happen with the media types intended for MIME.

I do want to point out that how we RTP uses the top-part of the media 
type name. They are used to explicitly identify which other media 
formats they are okay to multiplex in the same session. This also 
ensures that different media types are not multiplexed on the same RTP 
session. The reason for this practice can be read in secton 5.2 of RFC 
3550. Thus we need to be able to register RTP payload formats also in 
text top-level type. So if the conclusion is to go with keeping one 
registry I hope people understand we can't receive the same flak every 
time we writes text/.

I think there are good reasons for keeping the registry as one. Both in 
RTP and MIME usage the types are after all media formats with specified 
represenations. Having one registry with all representation instead of 
separating does not simplify the process of maintaining good usage of 
that registry and avoid duplicating entires when there actually are two 
different representations.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Sat, 02 Jul 2005 00:22:12 +0700

Date:        Fri, 1 Jul 2005 16:35:53 +0100
    From:        Colin Perkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | You're misunderstanding what is being done.

Thanks for the explanations, that helps.

  | The question becomes: will the leakage go away if we separate the  
  | registries?

I didn't know that was the suggestion.   I wouldn't suggest that.  What I'd
prefer would be for the specifications to indicate how to send media type X
over RTP.   That is, for data types where that makes sense.   The data type
should stand alone as something useful.

Where I first came into this was with a text/something type.  If I gathered
correctly, for RTP, the type includes timing information, as well as some
character type data.   That's fine.  But it isn't a text/* data type
according to the normal meaning of text, unless the timimg information is
expressed in some kind of printable representation (XML tags, or something)
which is not what I am assuming.

That is, my understanding of a text type, was something where it is
perfectly safe (if not always pleasant) to simply dump the file at a
user, with no processing, and the user (perhaps an astute user, with
knowledge of the meanings of any markup that's included) can work out
what is going on (the user can act as text processor).

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 02 Jul 2005 00:30:38 +0700

Date:        Fri, 01 Jul 2005 17:38:19 +0200
    From:        Magnus Westerlund <[email-masked]>
    Message-ID:  <[email-masked]>

I understand everything you're saying, except this part...

  | I do want to point out that how we RTP uses the top-part of the media 
  | type name. They are used to explicitly identify which other media 
  | formats they are okay to multiplex in the same session.

OK, that part too...

  | This also 
  | ensures that different media types are not multiplexed on the same RTP 
  | session.

And that...

  | The reason for this practice can be read in secton 5.2 of RFC 3550.

OK.

  | Thus we need to be able to register RTP payload formats also in 
  | text top-level type.

Now, I'm lost.   You just finished explaining how the RTP media types are
all different from all other media types, because they necessarily need to
retain the RTP packet info (or I'd guess perhaps some of that, but it
doesn't matter) as an essential part of a data.   Now you seem to be
saying that it is OK to multiplex a text/plain or a text/html into the
same data stream.  How?   Those don't contain the RTP packet info, do they?

Or is this just because you have some text/x types already, and want to
be able to add new ones to the same set?   If that's it, would it be possible
to rename the existing text/* (RTP) types into something else, like rtp-text/*
so that the confusion goes away?

kre

---

From: Stephen Casner <[email-masked]>
Date: Fri, 1 Jul 2005 10:57:09 -0700 (PDT)

> same data stream.  How?   Those don't contain the RTP packet info, do they?

No, there is no payload format specification for packetizing either
text/plain or text/html in RTP, so neiher can be sent in RTP, let
alone multiplexed.  For those types (in text or in audio or video)
that do have payload format specification, the answer to your question
about how two streams within the same major type would be multiplexed
is this: the RTP header contains a "payload type" field that
identifies the type with a small number dynamically mapped to the type
for the duration of the session.

Someonecould write a simple specification for putting text/plain into
RTP, but that proposal would not gain consensus in the AVT working
group because RTP is not a reliable transport protocol.  The text
types that are defined include redundancy mechanisms that are
appropriate for text when used in a streaming mode, such as
conversational text.

> be able to add new ones to the same set?

Yes, that is right.  If you think about categories of streaming media,
text is just as logical as audio and video.

> If that's it, would it be possible to rename the existing text/*
> (RTP) types into something else, like rtp-text/* so that the
> confusion goes away?

That would be possible, but only with a lot of work and backwards
compatibility problems.  If the registrations remain in the MIME
namespace, then that implies the definition of a new major type.
There are righly tight constraints on doing that.  Rather than define
rtp-text, it has been proposed to separate all the RTP media types
into their own space, where we could have audio, video and text to use
without any MIME restrictions.  While that might seem attractive in
some circles for some reasons, it gets us back to the question from

> should stand alone as something useful.

That is exactly what we have done for all the data types where it made
sense and there was motivation.

                                                        -- Steve

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 05 Jul 2005 16:13:16 +0200

Further clarifications inline.

>   | ensures that different media types are not multiplexed on the same RTP 

Due to what is written in section 5.2 of RFC 3550 different media types 
(audio, video, text) should be separated into different RTP sessions. To 
achieve this each RTP payload format has a top level media type it 
belongs to. This assignment binds it to which other media types it is 
possible to multiplex. This top-level type is also explicitly provided 
in SDP for each RTP session which is helping us to ensure that RTP 
payload are only used in RTP sessions of the correct media top level.

> doesn't matter) as an essential part of a data.

Yes, information in the RTP header is essential part of the data.

    Now you seem to be
> same data stream.  How?   Those don't contain the RTP packet info, do they?

What you are suggesting isn't possible as neither text/plain or 
text/html has any defined RTP payload format and are not likely to get 
one as they have no real-time properties. Nothing is transported in RTP 
without an defined RTP payload format.

What I like to stress in regards to the text top level type is the 
following.

- From an RTP perspective all the media types (audio, video and text) 
are all needed, but non are special or have special rules. The only 
things that matters is the media types general properties and that they 
provide appropriate grouping.
- Text is different in its properties from audio and video and should 
therefore be using its own media type.
- When new RTP payload formats are defined for carrying text with 
real-time properties we will need to register them in the text top-level 
not any other top-level media type.

> so that the confusion goes away?

I think Colin responded to that. However, yes you are correct we do 
already have text/x types and we expect there will be a small but 
increasing set of type that are text. Renaming the current into another 
top-level domain does not reduce the confusion, it only increases it. It 
is also something that makes millions of deployed devices interoperable.

Please understand that what we are discussing is something that has been 
done for a long time and have very many deployed implementations (on the 
order of 100 million instances). This usage of media types are in every 
Windows or Apple box that has Quicktime, Real, or Windows media players, 
it is in many mobile phones sold the last 2-3 years. So please remember 
that any change that would jeopardize interoperability has the same 
impact as when people touches the email system in a non backwards 
compatible way. So changing a top-level media type from text to rtp-text 
would be bad, really bad.

Cheers

Magnus Westerlund