On Sat, 2 Jul 2005, Robert Elz wrote:
> | 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. 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?
No, there is no payload format specification for packetizing either
text/plain or text/html in RTP, so neiher can be sent in RTP, let
alone multiplexed. For those types (in text or in audio or video)
that do have payload format specification, the answer to your question
about how two streams within the same major type would be multiplexed
is this: the RTP header contains a "payload type" field that
identifies the type with a small number dynamically mapped to the type
for the duration of the session.
Someonecould write a simple specification for putting text/plain into
RTP, but that proposal would not gain consensus in the AVT working
group because RTP is not a reliable transport protocol. The text
types that are defined include redundancy mechanisms that are
appropriate for text when used in a streaming mode, such as
conversational text.
> 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?
Yes, that is right. If you think about categories of streaming media,
text is just as logical as audio and video.
> 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?
That would be possible, but only with a lot of work and backwards
compatibility problems. If the registrations remain in the MIME
namespace, then that implies the definition of a new major type.
There are righly tight constraints on doing that. Rather than define
rtp-text, it has been proposed to separate all the RTP media types
into their own space, where we could have audio, video and text to use
without any MIME restrictions. While that might seem attractive in
some circles for some reasons, it gets us back to the question from
Colin to which you responded:
> | The question becomes: will the leakage go away if we separate the
> | registries?
>
> I didn't know that was the suggestion. I wouldn't suggest that. What I'd
> prefer would be for the specifications to indicate how to send media type X
> over RTP. That is, for data types where that makes sense. The data type
> should stand alone as something useful.
That is exactly what we have done for all the data types where it made
sense and there was motivation.
-- Steve
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf