Subject: [MMUSIC] Naming of RTP payload formats within SDP

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Jun 2005 17:25:34 +0100

I'd like to draw the attention of the working group to the IESG draft  
"A question on Media Type Registrations" which has recently been  
submitted:

     http://www.ietf.org/internet-drafts/draft-iesg-media-type-00.txt

There has been considerable controversy on the <[email-masked]>  
mailing list over the use of MIME media types to identify RTP payload  
formats within SDP, triggered by our attempted registration of RTP  
payload formats for real-time text conversation. This has led some in  
the community to review the use of media types to identify RTP  
payload formats, and to suggest it is inappropriate to use the  
existing media types registry for this purpose. The above mentioned  
draft summarises the issues, suggests three possible future  
directions for use of media types, and solicits feedback from the  
community. The three directions are (from section 2 of the draft):

"All media type protocols may specify handling" -- this is  
essentially the status quo, requiring no changes to RTP payload  
format naming in SDP.

"MIME handling is the model for other using protocols" -- this would  
prevent registrations for media types which cannot be passed directly  
to a MIME parser, in effect preventing RTP payload types from using  
the media types namespace and requiring (at least a partial) registry  
split.

"Registry split" -- the media types registry is split into two, with  
all RTP payload formats moving to a new registry. This would require  
updates to all RFCs that define RTP payload formats, reference the  
SDP "m=" and "a=rtpmap:" lines to name RTP payload formats or other  
media types, or reference MIME media types to name RTP payload formats.

I would strongly urge you to read the draft, and to consider the  
effects of either of the latter two directions on RTP, SDP, SIP and  
RTSP. Comments should be sent to either <[email-masked]> or  
<[email-masked]> before 1st July 2005.

Colin

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

---

From: Dave Singer <[email-masked]>
Date: Tue, 21 Jun 2005 16:31:36 -0700

I have not (yet) replied to the IESG or IETF.  But I thought maybe 
some discussion here was worthwhile before doing so (you might set me 
straight).

I have been repeatedly troubled by people who want to use MIME types 
intended for RTP payloads as types for files.  This is especially 
acute in the case of MPEG-4 where the file MIME type is still not 
registered, but the RTP payload is.  Thus we find people trying to 
use video/mpeg4-generic or video/mp4v-es for MP4 files, though in 
fact they are for RTP payloads.  (video/mp4 is intended to be 
registered for files, by the way).  Even if the latter were 
registered, it's still confusing having them in the same registry.

Also, the restrictions on 'true' MIME types are, as noted in the I-D, 
a stumbling block for RTP.  No-one I know expects to be able to treat 
an RTP TEXT payload as text/plain, for example.

So, I tend to solution (3).  Split the registry.  Are there *any* 
types valid both for a mail message and an RTP payload?  If not, 
splitting is harmless.  We can start the RTP 'tree' with video/, 
audio/, text/ etc. so the actual 'bits on the wire' (e.g. in an 
RTPMAP) don't change, right?
-- 
David Singer
Apple Computer/QuickTime

---

From: Colin Perkins <[email-masked]>
Date: Wed, 22 Jun 2005 09:56:02 +0100

On 22 Jun 2005, at 00:31, Dave Singer wrote:
> some discussion here was worthwhile before doing so (you might set  
> me straight).
>
> I have been repeatedly troubled by people who want to use MIME  
> types intended for RTP payloads as types for files.  This is  
> especially acute in the case of MPEG-4 where the file MIME type is  
> still not registered, but the RTP payload is.  Thus we find people  
> trying to use video/mpeg4-generic or video/mp4v-es for MP4 files,  
> though in fact they are for RTP payloads.  (video/mp4 is intended  
> to be registered for files, by the way).  Even if the latter were  

Would it be any less confusing to have similar looking names in a  
different registry? Especially since there would be the potential for  
conflicting use of names between the two registries.

> Also, the restrictions on 'true' MIME types are, as noted in the I- 
> D, a stumbling block for RTP.  No-one I know expects to be able to  
> treat an RTP TEXT payload as text/plain, for example.

This discussion was started because some in the MIME community think  
there is a real concern that some will expect to treat RTP text  
formats as text/plain.

> types valid both for a mail message and an RTP payload?

Yes. Several of the audio types are defined for use in both RTP and  
as a file format: audio/amr, audio/amr-wb, audio/L16, audio/smv,  
audio/evrc, audio/ilbc

> If not, splitting is harmless.  We can start the RTP 'tree' with  
> video/, audio/, text/ etc. so the actual 'bits on the wire' (e.g.  
> in an RTPMAP) don't change, right?

The bits wouldn't change, but there would be a pretty big semantic  
difference. Do we really want to restrict SDP to negotiating only RTP  
payload formats? We can use SDP to signal a session using the  
"application/bfcp" media type now - because there is a single  
namespace for all types. With a split registry we'd either have to  
give up this capability, or rework SDP to indicate which name space  
was intended.

Colin

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Jun 2005 09:04:29 -0400

Would it ever make sense to just convey a file type in SDP? I can't see 
how application/pdf or application/powerpoint or text/xml would be 
particularly useful. Thus, I'm not sure why one would ever need to 
indicate the namespace.

I agree that unplanned name collisions would be confusing, but the 
registries could be set up so that the two are coupled, i.e., a new one 
in either registry can't duplicate the name unless they are indeed the 
same bits on the wire.

Henning

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Jun 2005 15:24:44 +0200

Hi Henning,

A quick comment on your suggestion to be taken into consideration.

> in either registry can't duplicate the name unless they are indeed the 

Me and Colin has been involved in discussion on what is considered the 
same bits on the wire with some of the APPS area folks. For example Ned 
Freed has been quite clear that he doesn't consider a solution like that 
for AMR to be the same media type between the file format and RTP 
payload format. Despite them producing the same basic output of a FT + Q 
header byte and a speech data frame. Sure in some cases the RTP payload 
format makes strange sorting of the bit, but the basic information is 
always there and is recovered after depacketization.

Especially problematic was that the files has a magic word in this 
beginning. That make them clearly different from interpreter point of view.

We also have some serious backwards compatibility issues. The audio/amr 
media type are probably supported in around a 100 million devices, most 
actually supporting both file format and RTP payload format. This being 
devices not easily upgraded as most are mobile phones.

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: Colin Perkins <[email-masked]>
Date: Wed, 22 Jun 2005 16:01:46 +0100

On 22 Jun 2005, at 14:04, Henning Schulzrinne wrote:
> Would it ever make sense to just convey a file type in SDP? I can't  
> see how application/pdf or application/powerpoint or text/xml would  
> be particularly useful. Thus, I'm not sure why one would ever need  
> to indicate the namespace.

Because otherwise we're restricted to using the RTP payload format  
namespace with SDP, and can't use non-RTP formats (or vice versa)?

> registries could be set up so that the two are coupled, i.e., a new  
> one in either registry can't duplicate the name unless they are  
> indeed the same bits on the wire.

So why not use the same namespace, and define restrictions on use?  
(i.e. the way  the registry has been managed for the last 7 years or  
so...)

What is the benefit of a change?

Colin

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Jun 2005 12:47:56 -0400

> namespace with SDP, and can't use non-RTP formats (or vice versa)?

Let's assume for a moment that we're only talking about identifying RTP 
payload types for now, not using SDP to convey some other media exchange 
(e.g., support of media types over MSRP). In that case, there are 
several sub-cases, assuming a split registry, if somebody wants to 
stream some data type X over RTP:

(1) Registrations exist in both --> no issue

(2) Registration exist in the "email" registry, but not in the RTP registry

   (2a) The very same bit pattern could be used for both and there are 
no special SDP parameters needed.

   (2b) A payload format is needed or RTP-specific parameters are needed.

We want to avoid case (2), in particular (2a). This case arises if 
somebody registers a new media type for "email", but the MMUSIC/AVT 
community doesn't find out until there are problems in implementations. 
Making sure that such registrations are passed on to an appropriate 
expert review in AVT/MMUSIC would allow us to catch this case and then 
decide whether an RTP version makes sense or not. My perception is that 
this is not currently happening, i.e., somebody could register an 
"email" type for audio/* and AVT would never find out (except by accident).

> What is the benefit of a change?

I see no major benefit to change the current setup, but I don't see that 
this would be a big deal, either.

I'd be curious as to whether there was a specific issue or incident that 
caused the movement to change the status quo.

---

From: Dave Singer <[email-masked]>
Date: Wed, 22 Jun 2005 11:24:38 -0700

>What is the benefit of a change?

For me, if the IANA is managing two spaces, it can be clear which one 
is which and we can avoid arguments like -- "audio/whatever" may make 
sense as a file format (i.e. MIME) but none as an RTP format, or 
vice-versa.

Logically we then have
mime/audio/midi
rtp/audio/amr

(where mime/ and rtp/ are separate IANA entry points).

and so on.  There's no reason why one shouldn't request that 
something be inserted into both mime/ and rtp/, of course.  But then 
it's explicit and an intent, and both communities get to review.

It makes no sense to me that we are currently populating the MIME 
tree with types that can't be used in a MIME context (e.g. email).

This changes no bits on the wire;  we initially populate rtp/ from 
the mime/ tree, using those types that make sense.  We amend the 
appropriate spec. to say that RTPMAP lines reference the rtp/ tree.
-- 
David Singer
Apple Computer/QuickTime

---

From: Colin Perkins <[email-masked]>
Date: Thu, 30 Jun 2005 16:55:14 +0100

Henning,

[back from vacation, hence the slow response]

On 22 Jun 2005, at 17:47, Henning Schulzrinne wrote:
>> Because otherwise we're restricted to using the RTP payload  
>> format  namespace with SDP, and can't use non-RTP formats (or vice  
>> versa)?
>
> Let's assume for a moment that we're only talking about identifying  
> RTP payload types for now, not using SDP to convey some other media  
> exchange (e.g., support of media types over MSRP).

Don't forget that SDP can be used to signal other protocols than RTP.

> In that case, there are several sub-cases, assuming a split  
> registry, if somebody wants to stream some data type X over RTP:
>
>   (2a) The very same bit pattern could be used for both and there  
> are no special SDP parameters needed.
>
> community doesn't find out until there are problems in  
> implementations. Making sure that such registrations are passed on  
> to an appropriate expert review in AVT/MMUSIC would allow us to  
> catch this case and then decide whether an RTP version makes sense  
> or not. My perception is that this is not currently happening,  
> i.e., somebody could register an "email" type for audio/* and AVT  
> would never find out (except by accident).

All new media types are supposed to be reviewed on the <ietf- 
[email-masked]> mailing list. Both AVT chairs are on that list, so we  
would find out that way. This is one of the good things of the  
combined registry: it's very easy to do cross area review, since  
there's a single list.

>>> I agree that unplanned name collisions would be confusing, but  
>>> the  registries could be set up so that the two are coupled,  
>>> i.e., a new  one in either registry can't duplicate the name  
>>> unless they are  indeed the same bits on the wire.
>>>
>> So why not use the same namespace, and define restrictions on  
>> use?  (i.e. the way  the registry has been managed for the last 7  
>> years or  so...)
> I see no major benefit to change the current setup, but I don't see  
> that this would be a big deal, either.

You don't consider having to change 70+ registrations, dozens of  
RFCs, books, articles, and code to be a big deal? Likely to cause  
confusion?

> I'd be curious as to whether there was a specific issue or incident  
> that caused the movement to change the status quo.

The attempt to register RTP payload formats under the "text" top- 
level media type worried some people. In particular, there was  
concern that text mode email clients might accidentally receive an  
RTP stream which they wouldn't be able to process.

Colin

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Jun 2005 12:04:28 -0400

> You don't consider having to change 70+ registrations, dozens of  RFCs, 
> books, articles, and code to be a big deal? Likely to cause  confusion?

I don't know the intent here, but I was assuming that none of the 
over-the-wire bits would change and that the old audio/* and video/* 
registrations would simply be copied wholesale to the new list. Thus, 
unless the RFC or book talks in detail about registration procedures for 
new media types, I don't see how this changes the world all that much, 
except that IANA needs to do some editing.

Again, I don't see the need to create work for anybody ("ain't broke"), 
but I'm not sure if the discussion is helped by exaggerating the work 
involved.

> The attempt to register RTP payload formats under the "text" top- level 
> media type worried some people. In particular, there was  concern that 
> text mode email clients might accidentally receive an  RTP stream which 
> they wouldn't be able to process.

Is this a valid concern? Are there other good ways to address this concern?

(My vague recollection is that a system should be able to usefully 
render any text/* stream, so this sounds like a vaguely plausible concern.)

---

From: Colin Perkins <[email-masked]>
Date: Thu, 30 Jun 2005 17:32:19 +0100

On 30 Jun 2005, at 17:04, Henning Schulzrinne wrote:
> over-the-wire bits would change and that the old audio/* and video/ 
> * registrations would simply be copied wholesale to the new list.  
> Thus, unless the RFC or book talks in detail about registration  
> procedures for new media types, I don't see how this changes the  
> world all that much, except that IANA needs to do some editing.
>
> Again, I don't see the need to create work for anybody ("ain't  
> broke"), but I'm not sure if the discussion is helped by  
> exaggerating the work involved.

RTP payload types contain a MIME registration form. We'd need to  
update 22 such RFCs if the change went ahead. This could be done as a  
single new RFC (like RFC 3555), or as part of the usual update cycle.  
This is a lot of work for someone, but is clearly possible. It  
creates a lot of confusion, however, since the old references will be  
around for a long time.

>>> I'd be curious as to whether there was a specific issue or  
>>> incident  that caused the movement to change the status quo.
>>>
>> concern that text mode email clients might accidentally receive  
>> an  RTP stream which they wouldn't be able to process.
>

It's a vaguely plausible concern, which I believe is addressed by the  
concept of framed media types which have restricted applicability.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Thu, 30 Jun 2005 17:34:22 +0100

On 22 Jun 2005, at 19:24, Dave Singer wrote:
...
> For me, if the IANA is managing two spaces, it can be clear which  
> one is which and we can avoid arguments like -- "audio/whatever"  
> may make sense as a file format (i.e. MIME) but none as an RTP  
> format, or vice-versa.
>
> Logically we then have
> mime/audio/midi
> rtp/audio/amr
>
> something be inserted into both mime/ and rtp/, of course.  But  
> then it's explicit and an intent, and both communities get to review.

Both communities can review existing media type registrations:  
there's a single dedicated mailing list for the purpose; it seems to  
work quite well.

> tree with types that can't be used in a MIME context (e.g. email).

The decision to convert the MIME tree into a general purpose media  
types registry was made in AVT at the 40th IETF, with help from the  
applications area directors. At the time it was thought that a single  
registry was important to avoid confusion from overlapping names in  
different registries. Indeed, the use of conflicting names for the  
same data format ("audio/basic" versus "audio/pcmu") was one of the  
primary drivers for the unification.

Colin