Further clarifications inline.
Robert Elz wrote:
Date: Fri, 01 Jul 2005 17:38:19 +0200
From: Magnus Westerlund
<magnus(_dot_)westerlund(_at_)ericsson(_dot_)com>
Message-ID: <42C5636B(_dot_)7090208(_at_)ericsson(_dot_)com>
I understand everything you're saying, except this part...
| 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.
OK, that part too...
| This also
| ensures that different media types are not multiplexed on the same RTP
| session.
And that...
Due to what is written in section 5.2 of RFC 3550 different media types
(audio, video, text) should be separated into different RTP sessions. To
achieve this each RTP payload format has a top level media type it
belongs to. This assignment binds it to which other media types it is
possible to multiplex. This top-level type is also explicitly provided
in SDP for each RTP session which is helping us to ensure that RTP
payload are only used in RTP sessions of the correct media top level.
| Thus we need to be able to register RTP payload formats also in
| text top-level type.
Now, I'm lost. You just finished explaining how the RTP media types are
all different from all other media types, because they necessarily need to
retain the RTP packet info (or I'd guess perhaps some of that, but it
doesn't matter) as an essential part of a data.
Yes, information in the RTP header is essential part of the data.
Now you seem to be
saying that it is OK to multiplex a text/plain or a text/html into the
same data stream. How? Those don't contain the RTP packet info, do they?
What you are suggesting isn't possible as neither text/plain or
text/html has any defined RTP payload format and are not likely to get
one as they have no real-time properties. Nothing is transported in RTP
without an defined RTP payload format.
What I like to stress in regards to the text top level type is the
following.
- From an RTP perspective all the media types (audio, video and text)
are all needed, but non are special or have special rules. The only
things that matters is the media types general properties and that they
provide appropriate grouping.
- Text is different in its properties from audio and video and should
therefore be using its own media type.
- When new RTP payload formats are defined for carrying text with
real-time properties we will need to register them in the text top-level
not any other top-level media type.
Or is this just because you have some text/x types already, and want to
be able to add new ones to the same set? If that's it, would it be possible
to rename the existing text/* (RTP) types into something else, like rtp-text/*
so that the confusion goes away?
I think Colin responded to that. However, yes you are correct we do
already have text/x types and we expect there will be a small but
increasing set of type that are text. Renaming the current into another
top-level domain does not reduce the confusion, it only increases it. It
is also something that makes millions of deployed devices interoperable.
Please understand that what we are discussing is something that has been
done for a long time and have very many deployed implementations (on the
order of 100 million instances). This usage of media types are in every
Windows or Apple box that has Quicktime, Real, or Windows media players,
it is in many mobile phones sold the last 2-3 years. So please remember
that any change that would jeopardize interoperability has the same
impact as when people touches the email system in a non backwards
compatible way. So changing a top-level media type from text to rtp-text
would be bad, really bad.
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