Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)

From: Colin Perkins <[email-masked]>
Date: Tue, 7 Sep 2004 11:02:33 +0100

Jose,

On 17 Aug 2004, at 14:42, Jose Rey wrote:
> Dave and I have been discussing this offline and come to the following
> conclusions:
>
> 1.- it is not envisioned that the 3GPP Timed Text payload format will 
> be
> used for applications such as instant messaging or text conversation, 
> which do not precise of text decoration for working properly, since 
> there are other more appropriate media types covering these usages, 
> like text/t140. Hence,  video/ is enough.

I agree that this is not likely to be used for instant messaging or 
text conversation, although I don't understand why that would be 
relevant? Is this fundamentally text or a video codec? If it's a video 
codec, it should be under "video/", otherwise under "text/".

> 2.- we are not clear on what exactly means to "relax rules for media
> registration under text/".  I.e. is text/t140 an example of these 
> "relaxed" rules or does it comply with the traditional rules as per 
> rfc 2046?  Does the relaxed rules just mean that besides text also 
> payload headers of that media type are udnerstood?

My understanding is that the new rules are intended to allow formats 
such as 3GPP timed text to be registered under the text top-level media 
type, if appropriate, provided their domain of applicability is clearly 
specified (e.g. the domain of applicability might be that the type is 
defined for transfer via RTP only).

Colin

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

---

From: "Jose Rey" <[email-masked]>
Date: Tue, 7 Sep 2004 13:56:26 +0200

Colin,

Thanks for your answers. See inline.

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, September 07, 2004 12:03 PM
> To: Jose Rey
> Cc: IETF AVT WG; Dave Singer; Magnus Westerlund; IETF-Types
> Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
> andMediaTypes)
>
>
> Jose,
>
> relevant?

below..

> Is this fundamentally text or a video codec? If it's a video

I think it is a video codec, since without the video capabilities
(modifiers) it would just provide the same services as , e.g.,
conversational text=just plain timed text, for which it is not thought to be
used.

> defined for transfer via RTP only).

The MIME subtype /3gpp-tt cannot be used for HTML download since for that
purpose a 3gp file and therefore the video/3gp MIME type is used.  So I
think this is indeed restricted to RTP.  However,  what is the gain of doing
that?   Given the answer to the first question I think registering under
text/ would not be of any use?

Cheers,

Jose

---

From: Dave Singer <[email-masked]>
Date: Tue, 7 Sep 2004 13:55:21 +0200

At 11:02 AM +0100 9/7/04, Colin Perkins wrote:
>>1.- it is not envisioned that the 3GPP Timed Text payload format will be
>>used for applications such as instant messaging or text 
>>conversation, which do not precise of text decoration for working 
>>properly, since there are other more appropriate media types 
>>covering these usages, like text/t140. Hence,  video/ is enough.
>
>relevant? Is this fundamentally text or a video codec? If it's a 
>video codec, it should be under "video/", otherwise under "text/".

It's fundamentally for presenting visual information, but that visual 
information is achieved by rendering text.  It all depends on what 
the meaning of "text codec" is...

>such as 3GPP timed text to be registered under the text top-level 
>media type, if appropriate, provided their domain of applicability 
>is clearly specified (e.g. the domain of applicability might be that 
>the type is defined for transfer via RTP only).
>
>Colin

ah, OK.

for me, I don't mind which of text/ or video/ is chosen, provided it 
is only one of them!
-- 
David Singer
Apple Computer/QuickTime

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 07 Sep 2004 14:26:23 +0200

Hi Jose,

See below.

> conversational text=just plain timed text, for which it is not thought to be

I would argue that it is in fact text. It is Rich text, that has both 
different types of decoration, like colors and fonts, and also time 
based modifications, like karaoke markings. However it is in the bottom 
always text. It can't show anything else than the charsets from Unicode 
that is defined in section 5.3 of 3GPP TS 26.245. It is also readable 
with a minimal effort by simply extracting it from the RTP payload. I 
would think that basic extraction in complete text blocks is really 
equal to the capability of reading something with CAT when it comes to RTP.

> text/ would not be of any use?

I think there is a purpose of separating something that is of a 
different media type. It is clear that text and video might not be as 
well separated as video and audio. However there is some difference in 
what is needed to present text and video when it comes to devices. Text 
is generally much less complex, and do not require the same resolution, 
color support, etc., to be appropriately interpreted. Sure it can 
benefit from having the same capability, however not necessary to avoid 
losing information in many cases. Thus I would argue that there is a 
purpose to express that difference using different media types.

A 3GPP timed text session is also a complementing medium to a video 
stream, or it may be the other way around, that video is complementing 
the text. So from an AVT perspective I would expect it common that you 
will actually have the video and timed text in different RTP sessions. 
This due to selectability, adaptation and pure simplicity in handling. 
However this is not really a argument either way for choosing text over 
video or vice versa.

I do however agree with Dave that we should only select one media type. 
I was bringing up the potential usage of having two, simply to see if 
there is any merit. However I don't think there is any gain, only 
trouble on that road.

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]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 7 Sep 2004 13:25:52 +0100

Jose,

On 7 Sep 2004, at 12:56, Jose Rey wrote:
> conversational text=just plain timed text, for which it is not thought 
> to be used.

There are other text formats that include formatting modifiers, for 
example "text/html". I don't understand why their presence would make 
this a video format.

>> media
> think this is indeed restricted to RTP.  However,  what is the gain of 
> doing that?

My point was that, since this is restricted to transport via RTP, it 
can be registered under the "text" top-level media type.

> Given the answer to the first question I think registering under

Why not? It would seem to be the natural home for a timed text format.

Colin

---

From: "Jose Rey" <[email-masked]>
Date: Tue, 7 Sep 2004 14:54:39 +0200

> Sent: Tuesday, September 07, 2004 2:26 PM
> To: Jose Rey
> Cc: Magnus Westerlund; IETF-Types; IETF AVT WG; Dave Singer

Ok, I was guiding myself more by the what I understood as type of apps.
However, just for my clarity: if we wouldn't use the "relaxed rules" could I
still use text/? Is text/t140 conformat to the 'traditional rules'?

> can be registered under the "text" top-level media type.

What I mean is what would be the use of having two, not one or the other.

I think that as Magnus says there may be more motivation to go for text/
because of the selectability. That and the above are good reasons for me.

Summarising, it seems that we agree to choose text/.  Great! I can change
the registration to text/ if this settles it and submit the new revision and
let the MIME people review it.

Cheers,

Jose

---

From: Colin Perkins <[email-masked]>
Date: Tue, 7 Sep 2004 13:58:31 +0100

On 7 Sep 2004, at 13:54, Jose Rey wrote:
...
> However, just for my clarity: if we wouldn't use the "relaxed rules" 
> could I still use text/? Is text/t140 conformat to the 'traditional 
> rules'?

None of the RTP payload formats -- not text, audio or video -- can be 
used with the 'traditional' rules. This is the reason why the MIME 
registration rules are being updated.

> What I mean is what would be the use of having two, not one or the 

The media type for the file format may well be different than that for 
the RTP payload format, if that's what you mean.

Colin

---

From: "Jose Rey" <[email-masked]>
Date: Tue, 7 Sep 2004 15:35:57 +0200

--cut--
> registration rules are being updated.

It is just that in the MIME presentation in SD it says that text/t140 does
'arguably' comply with the traditional rules...what this 'arguably' means
was not clear to us.

--cut--
> the RTP payload format, if that's what you mean.

No. What I mean is what would be the use of having two for RTP, which in
this case is just confusing.

Jose

---

From: Dave Singer <[email-masked]>
Date: Tue, 7 Sep 2004 15:37:41 +0200

At 1:25 PM +0100 9/7/04, Colin Perkins wrote:
>>>Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] 
>>>RTP andMediaTypes)
>>>
>>conversational text=just plain timed text, for which it is not 
>>thought to be used.
>
>example "text/html". I don't understand why their presence would 
>make this a video format.

But text/html is not only rendering text, it is expressed in text. 
3GPP renders text, but it is expressed in binary.

>>think this is indeed restricted to RTP.  However,  what is the gain 
>>of doing that?
>

-- 
David Singer
Apple Computer/QuickTime

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 07 Sep 2004 15:46:24 +0200

Dave Singer wrote:

> But text/html is not only rendering text, it is expressed in text. 3GPP 
> renders text, but it is expressed in binary.
> 

Not really. In my view timed text is expressed in binary framing and 
UTF-8 or UTF-16 encoded text (which might be argued is binary). But the 
framing issues, are true for basically all RTP payload formats. You need 
to understand the RTP payload format to do anything.

Cheers

Magnus Westerlund

---

From: Dave Singer <[email-masked]>
Date: Tue, 7 Sep 2004 15:50:15 +0200

At 3:46 PM +0200 9/7/04, Magnus Westerlund wrote:
>UTF-8 or UTF-16 encoded text (which might be argued is binary). But 
>the framing issues, are true for basically all RTP payload formats. 
>You need to understand the RTP payload format to do anything.

agreed.  if you don't understand the payload-specific headers, it is 
no help to know that some of what you are looking at is expressed in 
textual format.

-- 
David Singer
Apple Computer/QuickTime