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

[Biot Olivier]

How about registering it in the "application" tree, under "vnd.3gpp"?
You will already find some 3GPP registrations there.

See for instance:
http://www.iana.org/assignments/media-types/application/

Best regards,

Olivier

|-----Original Message-----
|From: 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"
|>
|> 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: Colin Perkins
|>>
|>>
|>> 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