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: Thu, 02 Jun 2005 16:23:23 +0200

Hi,

After having discussed this with the authors and Colin we have the below 
proposed changes. So does this resolve the issues with the media type 
and the confusing statement around TCP?

Please note that the WG last call ends today.

PROPOSED CHANGES:

- Section 2.1, p.4: remove paragraph that causes confusion

REMOVED:

     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.

- Section 8:
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'.

     The receiver MUST ignore any unrecognized parameter.

     Media type: text

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

     The receiver MUST ignore any unrecognized parameter.

     Media type: video

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.

     Restrictions on usage:

          This type is only defined for transfer via RTP.

NEW:
     Encoding considerations:

          This media type is framed (see section 4.8 in [34]) and 
partially contains binary data.

     Restrictions on usage:

	   This media type depends on RTP framing, and hence is only defined for
      	   transfer via RTP [RFC 3550]. Transport within other framing 
protocols
      	   is not defined at this time.

OLD:
     Interoperability considerations:

          The 3GPP Timed Text media format and its storage is specified in
          Release 6 of 3GPP TS 26.245 "Transparent end-to-end packet
          switched streaming service (PSS); Timed Text Format (Release
          6)".  The 3GPP file format (3GP) and the SMIL language profile
          used can be found in Release 5 of 3GPP TS 26.234 and in the
          corresponding specifications for later Releases.  Note also that
          3GPP may in future Releases specify extensions or updates to the
          timed text media format in a backwards-compatible way, e.g. new
          modifier boxes or extensions to the sample descriptions.  The
          payload format defined in RFCXXXX allows for such extensions.
          For future 3GPP Releases of the Timed Text Format, the parameter
          "sver" is used to identify the exact specification used.

NEW:
     Interoperability considerations:

          The 3GPP Timed Text media format and its file storage is
          specified in Release 6 of 3GPP TS 26.245 "Transparent end-to-end
          packet switched streaming service (PSS); Timed Text Format
          (Release 6)".  Note also that 3GPP may in future Releases
          specify extensions or updates to the timed text media format in
          a backwards-compatible way, e.g. new modifier boxes or
          extensions to the sample descriptions.  The payload format
          defined in RFCXXXX allows for such extensions.  For future 3GPP
          Releases of the Timed Text Format, the parameter "sver" is used
          to identify the exact specification used.

          The defined storage format for 3GPP Timed Text format is the 
3GPP File
	   Format (3GP) [35].  3GP files may be transferred using the media type
          video/3gpp as registered by RFC 3839 [36].  The 3GPP File 
Format is a container
          file that may contain, e.g., audio and video which may be 
synchronized with the
          3GPP Timed Text.

- Section 12.2: New informative references

NEW:

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

     [34] Freed, N. and J. Klensin, "Media Type Specifications and
          Registration Procedures", draft-freed-media-type-reg-04,
          April 2005.

     [35] Transparent end-to-end packet switched streaming service (PSS);
          3GPP file format (3GP) (Release 6), TS 26.244 V6.3. March 2005.

     [36] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd
          Generation Partnership Project (3GPP) Multimedia files",
          RFC 3839, July 2004.

Magnus Westerlund wrote:
> 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
> 
> 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]
> 

-- 

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: Ned Freed <[email-masked]>
Date: Thu, 02 Jun 2005 07:39:17 -0700 (PDT)

> and the confusing statement around TCP?

IMO this looks good. I only have one wordsmithing nit and a question.

> ...

>      Media type: video

I'm delighted to see this moved to video.

> partially contains binary data.

This seems a bit awkward. How about "This media type is framed (see section 4.8
in [34]) and has both binary and textual components."

>       	   transfer via RTP [RFC 3550]. Transport within other framing protocols

Nicely put.

At one point I suggest it might be appropriate to map the U bit to a charset
parameter. Does this make any sense to do?

				Ned

---

From: Dave Singer <[email-masked]>
Date: Thu, 2 Jun 2005 08:47:24 -0700

I'd like to push back gently on the change from 'text' to 'video', 
just to test the waters.

The media types 'video' and 'audio' express what you *get* if you 
decode the stream, not how it is *encoded*.  They're not call 'float' 
or 'integer' or 'huffman', for example.  Yet for some reason we want 
to reserve the media type 'text' for those that express their 
encoding in printable text, without regard for what they are 
expressing;  this seems inconsistent.  I don't believe that 
everything expressed in say XML ought to be considered a 'text' media 
type, for example.  The fact that an (enthusiastic) human might be 
able to read the text is kinda irrelevant (especially given how 
readable much machine-generated HTML and XML is, in fact).

At 16:23  +0200 2/06/05, Magnus Westerlund wrote:
>Hi,
>
>After having discussed this with the authors and Colin we have the 
>below proposed changes. So does this resolve the issues with the 
>media type and the confusing statement around TCP?
>
>          The defined storage format for 3GPP Timed Text format is 
>the 3GPP File
>>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.
>>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
>>

-- 
David Singer
Apple Computer/QuickTime

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 02 Jun 2005 18:16:06 +0200

Hi Ned,

The word smithing looks fine and is say that we go with your proposal.

> parameter. Does this make any sense to do?

I would say no. If there was a possibility to move beyond UTF-8 and 
UTF-16 I would probably agree. However as these are the only charsets 
allowed and both are mandatory I don't see that it would provide any 
benefit at all.

Cheers

Magnus Westerlund

---

From: Ned Freed <[email-masked]>
Date: Thu, 02 Jun 2005 09:11:36 -0700 (PDT)

> expressing;  this seems inconsistent.

No, that's not it at all. The restrictions on the text type have to do with the
nature of the underlying data, not with how it is encoded. For example, there's
plenty of use of text types, including text/plain, that requires binary
encoding and cannot be accomodated by either 7bit or 8bit encodings.

There are, however, more restrictions on text that then are on other top-level
types. The fact that there are more restrictions may seem inconsistent, but
that's how this stuff was defined long ago and it is way too late to change it.

> I don't believe that
> type, for example.

It's more likely that *nothing* expressed in XML would be considered to
be a text media type.

				Ned

---

From: Dave Singer <[email-masked]>
Date: Thu, 2 Jun 2005 09:24:48 -0700

>It's more likely that *nothing* expressed in XML would be considered to

Thanks, but now I am lost.  Why is this a 'video' stream and not a 
'text' stream, then?
-- 
David Singer
Apple Computer/QuickTime

---

From: Ned Freed <[email-masked]>
Date: Thu, 02 Jun 2005 09:25:41 -0700 (PDT)

> allowed and both are mandatory I don't see that it would provide any

Then why do you need the U bit?

Let me be clear here. I have no problem with not defining the parameter, but
I don't understand why the number of charsets involved forms a criteria
for whether or not it is needed. I'm just trying to understand a bit more
about the nature of the underlying transport, I guess.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 02 Jun 2005 09:32:45 -0700 (PDT)

> Thanks, but now I am lost.  Why is this a 'video' stream and not a

Presumably because the intent is to display this as video. The rules for what
can fit under video are pretty loose; this is certainly an acceptable use of
the video top-level type. Text, OTOH, is usually thought of as a series of
lines and not as a stream of characters.

My (incorrect) understanding was that video was an unacceptable choice due to
SDP constraints. Without that constraint I would have been pushing for this
to go under video from the beginning.

				Ned

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 02 Jun 2005 18:55:26 +0200

> Then why do you need the U bit?

 From TS 26.245, section 5.1:

Text strings for display and font names are uniformly coded in UTF-8, or 
start with a UTF-16 BYTE ORDER MARK (\uFEFF) and by that indicate that 
the string which starts with the byte order mark is in UTF-16. 
Terminals shall recognise the byte-order mark in this byte order; they 
are not required to recognise byte-reversed UTF-16, indicated by a 
byte-reversed byte-order mark.

However this payload format removes the Byte Order Mark and requires a 
specific byte order. Thus to be able to provide the same information 
that a string is encoded in UTF-8 or UTF-16, it is explicitly indicated 
using the U bit.

> about the nature of the underlying transport, I guess.

Sorry, I might have misunderstood what charsets are. Are they all 
character encodings, i.e. mapping a value to a specific character? Or 
are there cases where charsets are sub-sets of a specific character 
encoding? For example, are there a charset that uses UTF-8 encoding but 
only contains a subset of the total characters?

If it is the seconds, there might be a benefit to define a charset 
character parameter to allow session participants to negotiate that set 
of used characters or at least know which will be used. However I guess 
it will be a parameter to which it will be hell to define the 
offer/answer usage for.

Cheers

Magnus Westerlund

---

From: Ned Freed <[email-masked]>
Date: Thu, 02 Jun 2005 10:01:05 -0700 (PDT)

> There is probably a need for a more reasonably defined top level type,
> like textual/* or something, but the timescales and amount of effort to
> establish such a thing are non-negligible.

Agreed.

				Ned

---

From: Dave Singer <[email-masked]>
Date: Thu, 2 Jun 2005 09:58:48 -0700

At 18:47  +0200 2/06/05, Chris Lilley wrote:
>On Thursday, June 2, 2005, 6:32:45 PM, Ned wrote:
>
>NF> Presumably because the intent is to display this as video. The 
>rules for what
>NF> can fit under video are pretty loose; this is certainly an 
>acceptable use of
>NF> the video top-level type. Text, OTOH, is usually thought of as a series of
>NF> lines and not as a stream of characters.
>
>Text is certainly a sequence of characters, which may or may not be
>preformatted into 'lines'. Other characteristics of text are that
>spell-checking and translation to a different language are reasonable
>things to do with it.
>
>Whether the text/* top level type is like that is another matter again,
>of course;  that type having sufficient problems that it should really
>not be used for anything much beyond text/plain; charset=us-ascii.
>
>
>NF> My (incorrect) understanding was that video was an unacceptable 
>choice due to
>NF> SDP constraints. Without that constraint I would have been 
>pushing for this
>NF> to go under video from the beginning.
>
>Timed text, because of its time dependent nature, is an arguable fit for
>video (but something of a stretch).
>

Thanks guys.  This is clearly a sticky area, and as you say, timed 
text is presumed to be visually presented (though I guess it could be 
read aloud) so I guess 'video' is OK.

I suspect that the true distinction lies in considering presentation; 
'text' types should be presentable by a text-to-speech system (for 
the vision impaired, for example), whereas 'video' would not be 
expected to be capable of this.  This in turn would suggest moving 
back to 'text' here, but only if the rules and maybe name of the 
'text' type were clarified, and I agree that that is a long road to 
hoe.

I rest my case, let video rule (though I still doubt its true correctness).
-- 
David Singer
Apple Computer/QuickTime

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 02 Jun 2005 19:04:06 +0200

> to go under video from the beginning.

You are correct it is not SDP that limits the usage, the question is 
what the right type is. 3GPP Timed text is clearly text and it is 
displayed as lines. However it also has connections to video by being 
specified to placed as an overlay in a specific part of the video 
display. In addition certain of the modifiers create video-like 
modifications of the text strings. Especially the karaoke modifier that 
repaint the characters with a time dependent speed.

So it is text, but with a twist. My opinion is that this still is text 
and many streams will be possible to display on a text only device. You 
can could in fact make a stock ticker that receives this format.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Jun 2005 18:12:07 +0100

On 2 Jun 2005, at 18:04, Magnus Westerlund wrote:
> You are correct it is not SDP that limits the usage, the question  
> is what the right type is. 3GPP Timed text is clearly text and it  
> is displayed as lines. However it also has connections to video by  
> being specified to placed as an overlay in a specific part of the  
> video display. In addition certain of the modifiers create video- 
> like modifications of the text strings. Especially the karaoke  
> modifier that repaint the characters with a time dependent speed.
>
> So it is text, but with a twist. My opinion is that this still is  
> text and many streams will be possible to display on a text only  
> device. You can could in fact make a stock ticker that receives  
> this format.

And, it's straightforward to strip the formatting, and display as  
generic text.

Colin

---

From: Ned Freed <[email-masked]>
Date: Thu, 02 Jun 2005 10:50:21 -0700 (PDT)

> that a string is encoded in UTF-8 or UTF-16, it is explicitly indicated

Does the U bit appear in the same context as the media type itself or is
it part of the payload or some other aspect of the  protocol? It seems
appropriate to define a mapping to a parameter if it appears alongside
the media type, but not if it doesn't.

> character encodings, i.e. mapping a value to a specific character?

A charset is defined as a mapping from bytes to characters.

Howevr, we're talking about a media type parameter here, not charsets
per se. The media type parameter could be expressed in a number of
different ways, e.g. u=8 vs u=16 would be one way to write it. I only
suggested writing it as "charset=utf-8" and "charset=utf-16" because
that corresponds to what's been done before.

> Or

I don't know of one of these specifically, but nothing would prevent one
from being defined.

Similarly, nothing prevents a charset parameter from being defined that
only accepts a small subset of the world's charsets. Or having different
default rules when it is missing. The only restriction here is on the
meaning of charset in conjunction with text media types, and we're no
longer talking about text types here.

> it will be a parameter to which it will be hell to define the

I'm not suggesting defining additional parameters. I'm only asking if
it makes sense to map and existing session parameter to a media type
parameter.

				Ned

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 2 Jun 2005 11:01:11 -0400

> and the confusing statement around TCP?

From my perspective, and within the framework at it now exists, yes.
I do intend to comment on draft-iesg-media-type-00, recently announced.

> Please note that the WG last call ends today.

FYI, one small nit with the -14 draft, unrelated to the media type
registration: first use of an abbreviation or acronym should be
accompanied by a full expansion; I believe SDP, possibly others,
in the draft does not.

Best regards,
  Bruce Lilly

---

From: Chris Lilley <[email-masked]>
Date: Thu, 2 Jun 2005 18:47:48 +0200

>> Thanks, but now I am lost.  Why is this a 'video' stream and not a

NF> Presumably because the intent is to display this as video. The rules for what
NF> can fit under video are pretty loose; this is certainly an acceptable use of
NF> the video top-level type. Text, OTOH, is usually thought of as a series of
NF> lines and not as a stream of characters.

NF> My (incorrect) understanding was that video was an unacceptable choice due to
NF> SDP constraints. Without that constraint I would have been pushing for this
NF> to go under video from the beginning.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

---

From: Larry Masinter <[email-masked]>
Date: Thu, 02 Jun 2005 12:20:56 -0700

(I trimmed the 'to' list down to the two lists)

I think lots of "application" types contain text,
have the feature that "spell-checking and translation
to a different language" is a reasonable thing to do.

I think these are suitable content features (attributes),
not content-type (category), and the top level media
type category isn't a good place to add more differentiation.

Larry

---

From: Randell Jesup <[email-masked]>
Date: 02 Jun 2005 17:27:31 -0400

Magnus Westerlund <[email-masked]> writes:
>You are correct it is not SDP that limits the usage, the question is what
>the right type is. 3GPP Timed text is clearly text and it is displayed as
>lines. However it also has connections to video by being specified to
>placed as an overlay in a specific part of the video display.

        Ummm.  So anything that can be eventually displayed (on a monitor or
other screen, since text could be displayed on a text-only display or beeper,
etc) is "video"?  This really, really rubs me the wrong way.  It just
feels "wrong".

        Now, it can be under anything.  But what's the _purpose_ and
effect?  Often, applications using SDP limit the number of streams of a
type (1 audio, 1 video, etc).  Now, they could relax that, but it starts
adding complexity to the negotiations ("1 video but 2 if one (and only one)
of the streams selects a text payload type").

        It makes sense for it to be video if it's intended to be 
in the same stream as "real" video as an alternate payload type (as an
overlay on video).  Maybe that's the case, in which case I partly withdraw
my objection.

>In addition certain of the modifiers create video-like modifications of
>the text strings. Especially the karaoke modifier that repaint the
>characters with a time dependent speed.

        I wouldn't consider that "video-like".  Non-static, but not
video-like. 

>So it is text, but with a twist. My opinion is that this still is text and
>many streams will be possible to display on a text only device. You can
>could in fact make a stock ticker that receives this format.

Stock ticker, "beeper", IM-specific device, cell SMS messages, scrolling-text
displays in stores, etc, etc.

Note: I really haven't been following this, so take my comments with a
block of salt.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
[email-masked]