Pre review of 3GPP MIME type for RTP payload format

[Magnus Westerlund (KI/EAB)]

Hi Larry,

Comments below, prefixed with [mw]. 

-----Original Message-----
From: Larry Masinter
To: Magnus Westerlund (KI/EAB)
Cc: ietf-types at iana.org
Sent: 2004-08-16 08:37
Subject: RE: Pre review of 3GPP MIME type for RTP payload format

> The problem is that the RTP payload format this defines is capable of 
> wrapping any other payload format.

Yes, the 'application' is the 'application as a wrapping technology'.

> As any other payload format 
> theoretically has any of the media types, this format needs to handle 
> all of the types. 

This isn't inconsistent with using 'application'.

[mw]
Yes, I would agree with you in the general context. However things are not this simple in the RTP usage domain. I will try to explain reasons why RTP payload formats that apply to different media types needs to be registered in multiple media types. 
[\mw] 

> So from my perspective, I don't see a problem with removing "Image"
and 
> "application" from the registration. The other three are needed.

I think we differ on the meaning of the top level media type. You
imagine that you need to use 'image' when the body is an image,
and I don't think it is necessary at all.

[mw]
The fact is that RTP and its signalling do require the registration in the applicable. For RTP there is a clear explanation in RFC 3550 why it is harmful to mix different media types in the same RTP session. Due to this reason also the signalling in SDP does not allow the mixing of multiple media types in the same RTP session. So due to the above restrictions one can not register an single application/rtp.enc.aes128 to secure all the different media top levels. 
[\mw]

I think it is harmful to register multiple media types when one will
do nicely. It isn't necessary that every MIME label be completely
descriptive of the content, but just that the MIME label contain
sufficient information to find the appropriate reciever.

[mw]
There is actuallly a good thing with registering in each media type for format that applies to one or all. That way one can ensure that a format actually is applicable to that media type. If one only register a single format, then there is not the same foral check that the usage for a certain meda type actually is applicable. For example the audio/RED mime type which we are now registering as text/RED when it has been checked that it is applicable.
[\mw]

And, since you can't do anything with the content without decrypting
it, and leaking information about the content is a concern, why not
just use 'application' all the time? Like with ZIP files or PDF files.

[mw]
In the RTP framework you are required to leak what media type in the signalling path anyway. You will need to secure the signalling path individually to the desired security level. 

I am sorry that the kinks of the RTP payload format MIME registrations procceduers was not worked out years ago. Today when we have several years of baggage, changing things are difficult. Please take a look at RFC 3555 whith outline the RTP MIME registration procedures. We do know that we will need to probably update this document when the new MIME registration rules are agreed on. 
[\mw]

Cheers

Magnus Westerlund