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@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