Fwd: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and Media Types)

[Colin Perkins]

I'm forwarding this question to the IETF-types list since I'm not sure 
we have the experience to decide this in the AVT working grou. The 
question is about draft-ietf-avt-rtp-3gpp-timed-text-04.txt: is it 
appropriate to register the format under the "video" or "text" 
top-level type?

Colin



Begin forwarded message:

> From: "Jose Rey" <rey at panasonic.de>
> Date: 5 August 2004 19:13:39 BST
> To: "Colin Perkins" <csp at csperkins.org>, "IETF AVT WG" <avt at ietf.org>
> Cc: Jan van der Meer <jan.vandermeer at philips.com>, Magnus Westerlund 
> <magnus.westerlund at ericsson.com>, Dave Singer <singer at apple.com>, 
> Yoshinori Matsui <matsui.yoshinori at jp.panasonic.com>
> Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and 
> Media Types)
>
> Colin, Magnus, all,
>
> I would like to take the opportunity to make a call for comments on 
> whether to registrate the 3GPP timed text payload format also under 
> the "text" top level type.  Two observations:
>
> In the 3GPP Timed text format, the text strings in the payload itself 
> are encoded using UTF8 or UTF 16, which should be a sufficiently low 
> requirement.  Of course, all the decoration and nice features such as 
> font/background color, scroll, hyperlinks, blinking text is lost.  
> Since the main target of timed text is exactly applications that do 
> need this, the question is whether it makes sense to do this.  Please 
> comment.
>
> A different issue that addresses another comment from Colin below is 
> the fact that timed text is currently used for download using HTTP in 
> 3GPP unicast streaming service.  So it is used in another domain. 
> However, no MIME type is defined there but just an identifier 
> "Timed-Text", how should this be synchronised?
>
>
> Thanks,
>
> Jose
>
>> -----Original Message-----
>> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]On Behalf Of
>> Colin Perkins
>> Sent: Donnerstag, 5. August 2004 19:09
>> To: IETF AVT WG
>> Cc: Magnus Westerlund
>> Subject: [AVT] RTP and Media Types
>>
>>
>> Folks,
>>
>> The working group recently sent the registration for the text/red 
>> media
>> type <draft-ietf-avt-text-red-05.txt> to the IESG for publication as a
>> Proposed Standard RFC. The IESG asked for expert review of the draft 
>> by
>> MIME experts (as is normal for media type registrations). The 
>> reviewers
>> found a number of problems with the draft, and these issues 
>> potentially
>> affect all other RTP payload types.
>>
>> It was noted that the rules for registering media types under the
>> "text" top level type are stricter than those for audio and video
>> types. In particular, it is expected that text media types are, to 
>> some
>> extent,
>> readable even without the software that interprets them [RFC 2046].
>> This rule is derived from email client behaviour, where one wants to
>> pass the message to a dumb pager if there is no better display option,
>> and have something reasonable happen.
>>
>> This is clearly not the case for the "text/red" or "text/parityfec"
>> media types, which are error correcting codes sent over a stream of
>> unreliable datagrams, and require complex processing at the receiver
>> before text can be recovered.  The "text/t140" format is arguably
>> justified since packets contain plain text in UTF-8 format, and can be
>> directly displayed once they have been received.
>>
>> The discussion of our use of the "text" top level type led to a review
>> of our other uses of media types with RTP. It was noted that the rules
>> for media type registrations don't currently allow for domain specific
>> types: it is not legal to register a media type saying "this type is
>> defined only for use over RTP". This conflicts with the rules in RFC
>> 3555, and affects all the media types registered for use with RTP.
>>
>> After much discussion between the chairs, area directors, and MIME
>> experts, it was concluded that is it appropriate to relax the rules 
>> for
>> media type registrations in two ways:
>>
>>   - Allow domain specific media type registrations
>>
>>   - Allow complex text formats, provided they have restricted domain
>>     of applicability and do not affect backwards compatibility for
>>     email clients
>>
>> This change will be discussed on the <ietf-types at iana.org> mailing 
>> list.
>>
>> These updates will allow us to continue basically unchanged with our
>> use of
>> media types in AVT. However, they will take time to complete, since we
>> must update the media type registration rules for both MIME and RTP.
>>
>> The immediate consequence for the AVT working group is that the
>> publication of draft-ietf-avt-text-red-05.txt may be slightly delayed
>> (we do not expect any change to this draft, but it cannot be published
>> until the MIME type registration rules have changed). In addition, the
>> media type registration guidelines in RFC 3555 will need to be 
>> updated.
>> The chairs will co-ordinate this - please contact us if you have any
>> questions on the change.
>>
>> In future, as new RTP payload formats are developed, we will require
>> expert
>> review of the media type registration as part of the working group 
>> last
>> call process. Please contact the chairs for guidance on the procedure
>> for this review, when you believe your draft is ready for working 
>> group
>> last call. We will not forward drafts to the IESG for publication
>> unless they have received such review.
>>
>> --
>> Colin Perkins
>> http://csperkins.org/
>>
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> avt at ietf.org
>> https://www1.ietf.org/mailman/listinfo/avt