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@panasonic.de> Date: 5 August 2004 19:13:39 BST To: "Colin Perkins" <csp@csperkins.org>, "IETF AVT WG" <avt@ietf.org> Cc: Jan van der Meer <jan.vandermeer@philips.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Dave Singer <singer@apple.com>, Yoshinori Matsui <matsui.yoshinori@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@ietf.org [mailto:avt-bounces@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@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@ietf.org https://www1.ietf.org/mailman/listinfo/avt