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(_dot_)westerlund(_at_)ericsson(_dot_)com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf