On 1 Jul 2005, at 14:02, Robert Elz wrote:
Date: Fri, 1 Jul 2005 12:57:15 +0100
From: Colin Perkins <csp@xxxxxxxxxxxxx>
Message-ID: <D1DC9E64-B6C8-40DD-9CCC-F6C62DA89E54@xxxxxxxxxxxxx>
| 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.
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).
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.
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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf