Robert Elz wrote:
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.
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.
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.
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: magnus.westerlund@xxxxxxxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf