Subject: [AVT] Re: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 May 2005 11:49:01 +0200

Hi Ned, Bruce and AVT,

Based on the feedback received on ietf-types list from Ned and Bruce I 
would propose the below updated to the media type registration section 
(8) of the 3GPP timed text payload format. Can Ned and Bruce please look 
at the proposed changes and see if they resolve their comments.

1. Add to the following sentence to the first paragraph:
OLD:
    The media subtype for the 3GPP Timed Text codec is allocated from the
    IETF tree.  The top-level media type under which this payload format
    is registered is 'text'.

NEW;
    The media subtype for the 3GPP Timed Text codec is allocated from the
    IETF tree.  The top-level media type under which this payload format
    is registered is 'text'. This registration is done using the
    procedure defined in RFC 3555 [33].

Section 12.2: New informative reference

New:

    [33] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
         Payload Formats", RFC 3555, July 2003.

2. As I can see the text in the encoding consideration section tries to 
capture what "framed" definition says in section 4.8 of
http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt.

OLD:
Encoding considerations:

         RTP payloads complying with this payload format contain binary
         data.

         Note that this type is incompatible with the use of text media
         types in other protocols, e.g. text/html.  This is because in
         order to extract and decode any of the timed text media it is
         necessary understand the (binary) payload headers defined in
         RFCXXXX.

NEW:
Encoding considerations: Framed

Comments, forgotten things, etc?

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: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 May 2005 16:52:24 +0200

Hi Bruce,

See comments inline.

Bruce Lilly wrote:
> [[email-masked] and [email-masked] map to the same
> mailing list; to prevent duplicates I have elided the latter from the Cc
> list]
> 
> On Mon May 30 2005 05:49, Magnus Westerlund wrote:
> 
> I believe the 12 April IETF discussion list discussion mentioned some
> alleged incompatibilities between RFC 3555 and the actual registration
> procedure.  Also, recent drafts of the proposed successor to RFC 2048
> refer to "standards tree" rather than "IETF tree".  I note that the
> draft makes no reference (either normative nor informative) to either
> RFC 2048 or to the draft successor.  RFC 3555 itself is titled so as
> to indicate that it provides registrations for some types, and it does,
> however it also mentions the RFC 2048 registration procedure, providing
> some specific parameters to be included in RTP-related registrations.
> Normally a registration procedure or an amendment to one would be
> specified in a BCP RFC rather than a Standards Track document like RFC
> 3555.  My reading of RFC 3555 section 2 gives me the impression that it
> isn't so much a registration procedure or amendment to the 2048 procedure
> as a set of guidelines for using the referenced (RFC 2048) registration
> procedure, and probably shouldn't have been labeled a registration
> procedure per se.  RFC 3555 itself does not provide the full registration
> template that is used in the draft under discussion, so at minimum that
> draft should contain an informative (some might say normative) reference
> to either RFC 2048 or to its draft successor depending on the actual form
> used -- I suspect that will be the draft version (and using an
> informative rather than normative reference would prevent blocking
> publication of the AVT draft pending publication of the registration
> procedures update draft; note that blocking publication as an RFC need
> not affect registration of the media type).
> 

Okay, I agree that there are some unclarities in regards to the 
registration descriptions, especially in regards to 3555 and the new 
registration. This is something that will need to be fixed by updating 
RFC 3555. However to do that update, there needs to be closure on some 
other topics around media types that is not relevant fro 3GPP timed 
text. For example the difference in format allowed between different 
domains.

To address your other concerns around reference I would then propose to 
change the text to:

NEW;
    The media subtype for the 3GPP Timed Text codec is allocated from the
    IETF tree.  The top-level media type under which this payload format
    is registered is 'text'. This registration is done using the template
    defined in [34] and following RFC 3555 [33].

And adding reference 34 as to draft-freed-media-type-reg.

> I'll return to the 'text' issue below.
> 
> 
> Good, but as noted above, I think the AVT WG also needs a reference to
> the actual registration procedure per se (in particular, its form) that
> is used by the draft under discussion.

I think that RFC 3555 actual is quite clear on that. From section 2 of 3555:

    Registering an RTP payload type as a MIME type follows the same
    procedures as described in RFC 2048 and uses the registration
    template shown in Section 2.8 of RFC 2048.

If that isn't actually a definition of a procedure, then I don't know 
what is. But being a standard track document is should have used 
normative language.

> If the AVT WG is going to go this route -- and I think that's probably
> a good choice -- then a reference to Ned's draft would be appropriate;
> otherwise a reader won't be able to figure out what "framed" means.  My
> personal opinion is that an informative reference would suffice, but
> that's up to the IESG to decide (I note that there have been a number of
> recent registrations that provide no reference at all to the registration
> procedure/form).  Also, as noted above, the reference to "IETF tree"
> should be changed to "standards tree" for consistency with terminology
> used in Ned's draft.

Sure, including the reference to Ned's draft and changing to standards 
tree is fine.

>  
> I still have a nagging concern about the "RTP-only" nature of the
> registration.  I do not think that's fully addressed by eliding the
> curious reference to text/html media above, because section 2.1 (second
> paragraph) of draft version -14 says:
>    For
>    transport, HTTP over TCP is used for downloading and RTP for
>    streaming.
> That seems to imply that the proposed media type *can* be used with
> other protocols, particularly non-framed protocols like HTTP, contrary
> to the statement in the draft's registration template, or that the
> statement above is referring to two different media types with some sort
> of implied conversion, or that the media type is in fact being treated
> as application media, i.e. opaquely for the purpose of (HTTP) transport,
> like application/octet-stream (the default for unrecognized application
> subtypes).

If you had read the next section it would have been clearer:
   "The scope of the 3GPP PSS specification (in the following referred to
    as PSS) includes both downloading and streaming of multimedia content
    over 3G packet-switched networks.  PSS adopts multimedia codecs such
    as MPEG-4 Visual [22], AMR wide-band [23] or MPEG-4 AAC [24] for
    encoding content.  Other protocols like RTSP [15] for session set-up
    and control, or SMIL [9] for handling presentation layouts. For
    transport, HTTP over TCP is used for downloading and RTP for
    streaming.

    As of today, PSS allows to download 3GPP timed text contents stored
    in 3GP files.  However, due to the lack of a RTP payload format, it
    is not possible to stream 3GPP timed text contents over RTP."

The quoted text applies to the whole service of PSS. This could be 
clarified by changing the last sentence to use "For transport PSS uses, 
...". However if one reads the second paragraph then it should be clear 
that 3GPP timed text has a defined storage format in 3GP files. This 
file format has its own media type (video/3gpp) that definitely is 
intended to be used with Content-Type headers. The only possible 
improvement here would be to add the relevant references for 3GP files, 
namely TS 26.244 and RFC 3839.

> 
> I'm not sure removing "binary" is a good idea; the draft mentions use of
> UTF-16, and other payload considerations aside, that would make the media
> type unsuitable for *MIME* text use, as UTF-16 is not a suitable charset
> for *MIME* text types (primarily because of the requirement for semantics
> of 0x0d (CR), 0x0a (LF), and 0x20 (SP) octets).  I'll let Ned address how
> that relates to the revised not-so-much-MIME registration procedure vs.
> the "text" top-level type.  A related concern is with (e.g.) a 16-bit
> text length (binary) field content of 0x0d0a.  Also, the encoding of a
> choice of two charsets via the single binary digit "U" in the payload
> differs significantly from the usual procedure for specification of
> a charset with text subtypes, viz. a "charset" parameter.

Yes, one could combine the Encoding consideration to say that the 
formats data is both binary and framed.

> 
> My strong impression is that registration under the application top-level
> type would be preferable.  Given the presence of binary data ("32-bit
> (unsigned) integers"), pointers to previously-transmitted data etc.,
> the media type doesn't sound like something that would be "to some
> extent readable even without the software that interprets" it, not
> unlike an application word processor media type which may contain
> compressed or encrypted text along with binary formatting data (e.g.
> application/msword), i.e. "text represented in an unreadable form"
> (quotes from the draft registration procedure, essentially the same
> as MIME RFC 2046).

To repeat myself. To register this under "application" would mean that 
RTP loses its mechanism to help ensure correct multiplexing of media 
types. This is really not good for RTP and its signalling mechanisms.

If we are talking alternatives, then it is actually video for this 
format. The end product of a text string and its modifiers are after all 
images, and with modifiers as karaoke, moving images thus video. This 
was discussed in AVT, where however text was the preferred media type. 
At least my view is that this is more text than video. It contains 
readable text string, at least if you have a UTF-8 and UTF-16 
interpreter. That those text string then is modified (font, size, 
blinking, hyper links, etc.) that is another matter.

> 
> The concerns about "text" and related issues mostly disappear if the
> registration is changed to an "application" type; CRLF, SP, charset, and
> readability-without-software concerns absolutely disappear.  I see no
> particular reason to prohibit transfer of an application media type via
> non-RTP protocols such as HTTP; perhaps a brief statement that transport
> via such protocols treats the media equivalently to the octet-stream
> subtype would be appropriate.

I think you don't understand the restrictions an RTP payload format 
works under. It needs to be following an RTP header that provides it 
with certain crucial information. An RTP payload without its RTP header 
is practically useless as you can't determine where it belongs in a 
sequence of payloads, nor when on the time line it should be played out. 
Therefore there is no direct mapping from RTP payload to a transfer over 
MIME or HTTP. There needs to be extra information written in, including 
the out-of-band signalling mechanism. Therefore there exist no such 
mapping that allows the transport your are suggesting.

The above is also the reason we have seen no problems (except for people 
to understand the division) to have it as it currently works. There has 
not been any leakage between the domains which is clearly one of the 
fears Ned has expressed.

Therefore I don't have any big fear of registering this payload format 
under text with the restriction to RTP only. Because it will not appear 
in any content-type header. And that is because that the format needs to 
be stored in a file to appear there, and that file format has the media 
type video/3gpp.

> 
> In retrospect, given the nature of the RFC 3555 section 2 specification,
> it would have been best to set up a separate top-level type for PSS- or
> RTP-related subtypes.  That might still be a viable option; putting off
> consideration of that option isn't going to make it any easier at a
> later date, after more registrations have been made under existing
> top-level types.
>  

This can of course be discussed. And considering the amount of time I 
have spent discussing this issue, I would really like this to get 
resolved yesterday rather than tomorrow.

Creating a new registry would certainly solve the issues  we are 
discussing. However this joining together of MIME and RTP payload format 
names into the media types registry was something that was discussed 
back in 1999 and they come to the current conclusion. It is after all 
the by the IESG approved way of doing media types registrations for RTP 
payload formats. Thus if things are going to change somebody needs to 
update those documented rules.

So in conclusion, does the proposed changes to the changes looks good?

Can you except this type as "text" with restrictions to RTP only or do 
we change it to "video"?

Cheers

Magnus Westerlund

---

From: Ned Freed <[email-masked]>
Date: Mon, 30 May 2005 07:39:16 -0700 (PDT)

> mailing list; to prevent duplicates I have elided the latter from the Cc

Thank you.

> procedure.

Actually, what was said (by Scott Hollenbeck) was:

  Ned, how would you reconcile the current text in your document with the
  practice specified in RFC 3555?  It's been alleged that the documents are
  not in alignment.

To which I replied:

  Assuming they really are out of alignment, I'd reconcile them by making
  whatever changes are appropriate in a revision to RFC 3555. Changing
  fundamental aspects of how media types are supposed to work and which vast
  tracts of code depend on is just not an option.

Note my use of the term "assuming" here.

No specifics of this misalignment were given at the time, and despite my asking
repeatedly for specifics none have ever been given. I note in passing that RFC
3555 contains no mention of text types at all, so any issue surrounding text
type usage can hardly be the basis for such an assertion.

> Also, recent drafts of the proposed successor to RFC 2048
> refer to "standards tree" rather than "IETF tree".

The primary reason for this revision was to relax the rules for the unfaceted
registrations to allow other standards bodies to use them more easily. It is
hardly appropriate to continue to call this the IETF tree given this change.

And this is noted in the change history.

> I note that the
> 3555.

This may be the theory, but actual practice is much sloppier. In general
it ends up being a judgement call - you have to look at a given reference
to an obsoleted specification and see if it makes sense to use the update
instead.

Xml2rfc may actually help clean this up over time given it's use of reference
libraries that handle these sorts of details for document authors.

> My reading of RFC 3555 section 2 gives me the impression that it
> procedure per se.

Agreed.

> RFC 3555 itself does not provide the full registration

I believe I aleady said a reference to RFC 2048 or its successor is IMO
appropriate.

> otherwise a reader won't be able to figure out what "framed" means.

Very good point. IMO this does make a reference to the revised regiration
procedures necessary.

>  My
 
My personal opinion is the same: An informative reference is sufficient.

> like application/octet-stream (the default for unrecognized application

Interesting. I missed that. It's definitely an inconsistency that needs to
be corrected one way or the other.

> the "text" top-level type.

The "text has to use CRLF" rule is IMO specific to MIME usage of text
types. The language in RFC 2045 section 4.1.1 isn't quite what I'd like
to have in this regard, but it is close enough:

   The canonical form of any MIME "text" subtype MUST always represent a
   line break as a CRLF sequence.  Similarly, any occurrence of CRLF in
   MIME "text" MUST represent a line break.  Use of CR and LF outside of
   line break sequences is also forbidden.

Note the "MIME" and "canonical form" qualifiers here. In any case, HTTP relaxed
the rule about CRLF being the only allowed line break long ago, so any
assertion that this rule applies to all uses of media types in all protocols is
simply silly.

> A related concern is with (e.g.) a 16-bit

> type would be preferable.

In theory I agree. However, as Magnus explained in a separate message, the way
RTP uses types makes this a practical nonstarter.

> later date, after more registrations have been made under existing
 
Having a separate rtp-text top-level time is indeed an interesting
alternative. I don't know if it is a viable course of action to take
at this late stage, however.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 30 May 2005 10:23:24 -0700 (PDT)

> [trimming quoted text to issues that warrant further discussion]

[further trimming done to make this manageable]

> On Mon May 30 2005 10:52, Magnus Westerlund wrote:
> > Bruce Lilly wrote:
> > The quoted text applies to the whole service of PSS.

> I am relatively unconcerned with issues related to PSS.  My concern is
> with the apparent contradiction between "only defined for transfer via RTP"
> in "Restrictions on usage" and "HTTP over TCP is used for downloading" in
> section 2.1.

Exactly so. This sure sounds like this type is in fact independent of RTP. Or
perhaps the stuff being transferred around in HTTP is actually a different
manifestation of the same underlying data, labelled, as you later suggest, with
an entirely different media type label. If so, this needs to be called out in
the text.

> A related point is that -- at least for MIME -- "binary" and "text" are
> incompatible due to the specific requirement for line endings and 0x0d0a
> sequences.
 
This is indeed true for MIME. But we have a history of relaxing this
restriction for other protocols.

> I don't see how the specific place in the registry where the type is
> registered necessarily precludes multiplexing under RTP.  How would
> a hypothetical registration as application/rtp.text or rtp/text prevent
> that?

My understanding is that it is because the multiplexing looks at the top level
type specifically. I don't fully understand the restrictions beyond that.

> > format.

> Registration under the video top-level type would remove objections based
> on presentation-without-software, CRLF, SP, and charset issues.

Indeed. I have no objection to and would prefer for this being placed under
video. However, my understanding is this cannot happen due to RTP constraints.
If that understanding is wrong then the right path forward is obvious.

> > The end product of a text string and its modifiers are after all
> > images, [...]

> Yes, teletext-like (or closed-captioning-like).

Teletext would be good top-level type name, wouldn't it?

> > It contains
> > interpreter.

> And application software that decodes the payload to find the U bit
> to decide which charset to use to display the text.  I don't know of
> any person who is likely to be able to do that without some application
> software.

Given that the only two charsets are UTF-8 and UTF-16, XML at least finds the
right charset can be reliably determined by inspection. I do prefer
having an explicit label.

However, it occurs to me that it is routine for AVT types to specify
one or more media type parametrs (typically stuff like frame rates)
and also specify how these parameters are encoded in RTP. Why not do
this with the U bit, mapping it to a charset parameter that can
either be UTF-8 or UTF-16?

> I feel more strongly about this than Ned apparently does, for reasons
> which I have cited (incidentally, the quote pertaining to presentation
> "without resorting to software that understands the format" in RFC 2046
> is a description of the top-level media types, not implementation
> considerations).

> In order of decreasing preference:
> 1. a new top-level top (strongly support)
> 2. application or video (OK; either one)
> 3. text (many concerns)

My preferences are actually similar. I guess I would prefer 2 to
1, but my understanding is that 2 is a nonstarter. I certainly
prefer either 1 or 2 over 3, but again my understanding is that
RTP really needs to use text.

				Ned

---

From: Bruce Lilly <[email-masked]>
Date: Mon, 30 May 2005 09:22:55 -0400

Best regards,
  Bruce Lilly

---

From: Bruce Lilly <[email-masked]>
Date: Mon, 30 May 2005 11:51:37 -0400

> That those text string then is modified (font, size,  

Agreed.  But the issues are with additional payload content which
interferes with strings (random 0x0d0a sequences that may appear in
binary data), incompatibility of UTF-16 with MIME text, and readability
of the strings (w/o attributes) without interpretive software.
 
> sequence of payloads, nor when on the time line it should be played out. 

I understand that, but view those considerations as irrelevant to the
question "is it really text according to the media type definition of
text?".  Text/plain can be transmitted in TCP packets and in MIME
message/partial fragments, which might arrive in random order and may
need to be reassembled.  That doesn't alter whether the content is
text.  While timing of presentation is important in presentation of
related content, it doesn't affect the media type; it is an external
consideration.  At the heart of the question is whether the media is
text (possibly with attributes) that is then wrapped in a package
with an RTP header for transport, or is a complete RTP application-
specific medium.

> mapping that allows the transport your are suggesting.

It's not my suggestion; the draft explicitly says "HTTP over TCP is
used for downloading".
 
> be stored in a file to appear there, and that file format has the media 

If that means that the stated downloads via HTTP will specify video/3gpp
as the media type, then there are a several questions:
1. How does that then get translated to something else for RTP transport,
   i.e. how does the "video/3gpp" content get changed to the appropriate
   type?
2. if the registered type/subtype name isn't used in a content-type field,
   where exactly does it appear where it supposedly is crucial to
   multiplexing?
3. Why not use "video/3gpp" with an appropriate parameter?

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 May 2005 16:47:32 +0200

Hi,

I think I need to do a better job of explaining how RTP and SDP uses 
media types and how that ties into the restriction I have mentioned.

RTP (RFC 3550) is a "transport" protocol extending the basic port 
multiplexing and datagram functionalities that the normal transport 
protocol provides, primarily UDP. This functionality consist of the 
following features:
- Sequence number to recover transmission order
- Timestamp to indicate when media shall be played out
- Sender source multiplexing to allow multiple sources from the same address
- Identification of format of payload, using the payload type (PT) field

The payload type (PT) field is 7 bits and is only valid within a each 
RTP session for its defined duration. The assignment policy is also 
dependent on the RTP profile in use. All current profiles use the PT 
policy defined in RFC 3551 "RTP Profile for Audio and Video Conferences 
with Minimal Control", also called AVP. AVP has some static mappings to 
specific encodings, but also reserves part of the number space to be 
used for dynamic bindings between an encoding and the payload type.

AVP references RFC 3555 how to register new encodings and defines 
encodings in the following way:

   "This profile lists a set of encodings, each of which is comprised of
    a particular media data compression or representation plus a payload
    format for encapsulation within RTP."

It also says the following:

   "This profile also assigns to each encoding a short name which MAY be
    used by higher-level control protocols, such as the Session
    Description Protocol (SDP), RFC 2327 [6], to identify encodings
    selected for a particular RTP session."

The short names for encodings that we register is media types.

So how is these media types actual bound in SDP to payload types. This 
is done using the SDP media blocks. Each media block, starting with a 
"m=" line may correspond to an RTP session. If it is RTP and AVP then 
that is also indicated. This m= line also indicate the fundamental media 
type, audio, video, text of the RTP session. The structure of an "m=" 
line is the following:

m=<media> <port> <proto> <fmt>

Where <media> is the media type of the session. Port identifies the port 
number the media will be received on. The proto identifies the protocol, 
in these case RTP plus a profile, often AVP (RTP/AVP). The lines ends 
with the <fmt> string, which is dependent on <proto> but for RTP/AVP is 
defined to be a list of used payload types in numeric form. Thus a 
filled in media description ("m=") can look like this:

m=audio 39467 RTP/AVP 96 97

These RTP payload types (96 and 97) would then need to be defined unless 
they are one of the few statically mapped ones. This mapping to an 
actual RTP encoding is done using an SDP attribute named "rtpmap". That 
provides the SDP reader with fundamental information about the encoding. 
  First the encoding format is identified, the top-media level of the 
media type is already provided in the "m=" line, the sub-type is then 
written into the rtpmap line:

a=rtpmap: 96 amr/8000/1

The sub-type is followed by the RTP timestamp rate, in this case an 8kHz 
clock and optionally one piece of encoding information. For any audio 
format that is the number of channels.

If the codec and payload format has further parameters that needs to be 
conveyed they are included in the "a=fmtp" line as a semi-colon 
separated list of type=value pairs.

Having the top-level media type into the "m=" line does enforce that 
only the same media type are used in a RTP session. This is something 
the RTP stresses as important to maintain clean multiplexing. There is a 
page of arguments why this is done in section 5.2 in RFC 3550.

So the above is why RTP encodings needs to be registered in the media 
type it belongs to. Registering everything in the same top-level type, 
like the proposed "application", would result in the loss of this 
separation. That is why we do not accept that.

It is also important to understand that a sequence of RTP packets 
containing dynamically assigned payload type are not decodable without 
the out-of-band information. There must be information about which RTP 
payload format and decoder that should be used. Also a lot of the 
payload formats needs to be correctly configured to be able to correctly 
parse the payload using the parameters defined for the media type. For 
example in the audio/amr payload format the third bytes first bit 
interpretation can be a number of things, and only by knowing which of 
the numerous configurations the payload actually is in, can one 
correctly interpret it.

In the discussion Bruce raised that it was confusing to mention RTP 
transport of 3GPP timed text when also listing the alternative to 
transport 3GPP timed text descriptions as a file over TCP. We from the 
RTP side has hard time to understand the argument as we know there exist 
no simple mapping from an RTP stream to files. As listed earlier in the 
email RTP provides a number of functionalities, one quite important in 
this context is the display timing and transmission order. These are 
required to feed a decoder at the right time and in the right order the 
received data to produce the out-put desired. If one was to simply save 
the RTP payloads in a sequence of a file that file would be practically 
useless. Thus this information need to be reformed into something 
suitable for file storage. In the case of 3GPP timed text, the text 
strings and the modifiers have mostly the same structure inside RTP 
payloads and in the file format. The file format we talk about here is 
the 3GP file format (media type video/3GPP) and defined in 3GPP TS 
26.244. It is based on the ISO multi-media file format which has its 
origin in quicktime file format. So when storing a RTP streamed 3GPP 
timed text into a file, the receiving end will need to do a number of 
things:
- Convert the RTP timestamp into the file formats way of storing time
- Wrap the text string correctly for file storage
- Write everything in the correct structure and add the correct pointers 
into the 3GP file formats sample entry.

If one looks at another format that has a file storage format. There 
always needs to be converting to the actually defined file-format. One 
can't simply write the series of RTP packets to a file an use it, 
because then one is lacking the out-of-band signalling. IF one includes 
the necessary signalling using some format, then one has suddenly 
created a new file format, that should have its own media type.

There has been a few format that has very similar file structure and 
packing inside of RTP payload formats that actually uses the same 
media-type both as file format and RTP payload encoding name. One of the 
examples are AMR, see audio/amr defined in RFC 3267. Here the difference 
between file format and RTP payload is a magic number and exactly how 
the framing is structured. Files uses a table of contents entry directly 
  followed by encoded data, while the RTP payload is one or more TOC 
entry then followed by the encoded data. The reason why this doesn't 
create problems is that the RTP media type version is always clearly 
identified by the context of being for RTP. The file format is used in 
all context where there is content-type headers file objects.

Sorry about the quite long description on how media types is used by 
RTP. However I hope that it can provide some common base of 
understanding for how we RTP folks look at media types.

We are comfortable to write that the media type for an RTP payload 
format is only used in RTP. Because as the type is defined it do require 
RTP and some external signalling identifying the fact that it is RTP to 
be used. It can't be used in another context without being defined for 
that context, either generally or specifically.

See this as input the continuing discussion.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 May 2005 16:57:14 +0200

Hi,

I will try to summarize the proposed edits I and the authors will try to 
incorporate into a updated proposal on how to resolve this specific 
case. The general topic on how to update the RTP registration of RTP 
payload format & encoding names in the future remains. But we have 
deadlines and needs to produce something now.

- We change the top-level media type to video. It is not my personal 
preference, but the media type is a borderline case of being video and 
some in the AVT WG have argued for it becoming video.
- We clarify the restriction on usage that applies and why this is only 
intended for RTP.
- We clarify that the encoding consideration for the payloads are that 
they are framed and contain binary information in certain parts.
- Include the already proposed changes regarding references, etc.

If you think I have forgotten any changes necessary to get at least this 
media type into acceptable shape, please comment.

We will send the updated proposal for the media type registration for 
your review as soon as we have word smithed the text.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Tue, 31 May 2005 18:32:38 +0100

> in "Restrictions on usage" and "HTTP over TCP is used for  

There is no contradiction. In 3GPP PSS one may download timed text  
data over HTTP, in which case it will be formatted within the  
standard ISO file format and identified using an appropriate media  
type ("video/3gpp").

Alternatively, one can stream timed text data over RTP, in which case  
it will be wrapped within RTP packets and identified by the text/3gpp- 
tt media type. Since the format is entirely different in the two  
cases, they have different media type names. In no case is the text/ 
3gpp-tt format conveyed using HTTP, or indeed any means other than  
via RTP.

The simplest fix may be to remove the motivation explaining 3GPP PSS  
from section 2.1, since it is clearly being misinterpreted.

...
>    i.e. how does the "video/3gpp" content get changed to the  

They are both well defined formats. How one implements a piece of  
code that reads one and produces the other is outside the scope of  
this specification: it's an implementation consideration, which has  
no effect on interoperability

>    where exactly does it appear where it supposedly is crucial to

If downloading a 3GPP file using HTTP, the "video/3gpp" type/subtype  
will appear in the content-type field as normal. The receiver will  
need to parse the ISO file to determine its contents, as for other  
container media types. None of this has anything to do with RTP.

If streaming 3GPP timed text via RTP, the RTP session will be  
signalled using a combination of RTSP [RFC 2326] and SDP [RFC 2327].  
The SDP will contain the media type in the "m=" line and the media  
subtype in an "a=rtpmap:" line. For example:

     m=audio 49230 RTP/AVP 96
     a=rtpmap:96 L8/8000

would map the media type "audio/L8" with parameter "rate=8000" onto  
RTP payload type 96. The 3GPP timed text use will be similar.

> 3. Why not use "video/3gpp" with an appropriate parameter?

If you were transmitting a 3GPP ISO file containing video, you would  
clearly use the "video/3gpp" media type. That has nothing to do with  
RTP, however, since RTP cannot convey 3GPP ISO files. This is the  
reason why this new RTP payload format, with its own media type, is  
being defined.

Colin