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

[Colin Perkins]

[Please keep the AVT list as a cc, so the authors of the draft get a 
copy]

The aim here is to register the media type for use in RTP sessions, 
which are negotiated using SIP. Registering it under "application" or 
"vnd.3gpp" would complicate the signalling, and it would be preferable 
from our point of view to register this under "text" or "video" (as has 
been done with other RTP payload formats).

That said, I'm not sure how the vnd tree works, so there may be a good 
reason to register it there, and then work out how to change SIP and/or 
SDP to make use of it.

Colin



On 9 Aug 2004, at 16:28, Biot Olivier wrote:
> 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
>
>
-- 
Colin Perkins
http://csperkins.org/