- Ietf-types - example.com

RE: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
by Jose Rey 17 Aug '04

17 Aug '04

Hi Colin, all, Dave and I have been discussing this offline and come to the following conclusions: 1.- it is not envisioned that the 3GPP Timed Text payload format will be used for applications such as instant messaging or text conversation, which do not precise of text decoration for working properly, since there are other more appropriate media types covering these usages, like text/t140. Hence, video/ is enough. 2.- we are not clear on what exactly means to "relax rules for media registration under text/". I.e. is text/t140 an example of these "relaxed" rules or does it comply with the traditional rules as per rfc 2046? Does the relaxed rules just mean that besides text also payload headers of that media type are udnerstood? We would appreciate your feedback, Jose > -----Original Message----- > From: avt-bounces(a)ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of > Jose Rey > Sent: Monday, August 16, 2004 5:39 PM > To: Dave Singer; Colin Perkins > Cc: Magnus Westerlund; IETF AVT WG > Subject: RE: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP > andMediaTypes) > > > > Dave, Colin, > > --cut-- > > > > > >If this analysis is OK, we could register both and clearly state the > > >scenarios in which each of them is used. This would enable a > client that > > >just understands UTF8/16 and the payload format to receive the > > text/3gpp-tt > > >w/o implementing the more complex timed text decoder, which may > > be useful. > > >A side effect of using this classification is that the > registration *does > > >implicitly* follow the traditional rules. > > > > > >Looking forward to your comments, > > > > > > > Since this payload format always has some binary fields, the text > > cannot be correctly extracted without understanding it, whether or > > not modifiers are present. > > As Colin said, for limited domains of applicability you can also register > under text/, without complying with the traditional rules: > > "The slides you quote are my interpretation of the traditional rules for > media under the "text" top level type. As you know, there has been some > discussion on relaxing these rules for media types with limited domain > of applicability. The RTP Payload Format for 3GPP timed text might fall > into this new category. Accordingly, we have this MIME review to decide > if the format should be "text" or "video"." > > > > I therefore feel that it should be either > > (a) only under text/ or (b) only under video/. I don't see any > > advantage to splitting it like this; the 3gpp-payload-unaware > > terminal can't make any more sense of a packet without modifiers than > > it can one with them. > > Therefore I don't think this is the criteria to judge text/ it appropriate > or not, but rather whether there are differentiated domains of > applicability > for which the timed text format can be used. In my previous email > I tried to > classify intuitively in those that need just text and the ones that need > text AND video. > > The answer to this different question might as well be no ;), but > I had the > feeling we talked past each other. > > Cheers, > > Jose > > PS: Colin, would RTP payload headers be part of the "software that > understands it"?) > > > > _______________________________________________ > Audio/Video Transport Working Group > avt(a)ietf.org > https://www1.ietf.org/mailman/listinfo/avt >

1 0

Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia Types)
by Colin Perkins 13 Aug '04

13 Aug '04

On 12 Aug 2004, at 17:30, Jose Rey wrote: > Dave, Magnus > > --cut-- >>> >>> As I said in my previous email, registering under 'text' top level >>> type would mean that the modifiers cannot be used. >> >> why is that true? does text/* only admit of plain text? so, for >> example, text/html would not be permitted either?? >> > > This is what I understand from the slides from Colin presented during > the > meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip, > "09-RTP-Media-Types.pdf"). Specially slide three where it says: > > ". 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; want to pass the > message > to a dumb pager if there's no better display option" > > Colin or Magnus may please correct me if I got it wrong... The slides you quote are my interpretation of the traditional rules for media under the "text" top level type. As you know, there has been some discussion on relaxing these rules for media types with limited domain of applicability. The RTP Payload Format for 3GPP timed text might fall into this new category. Accordingly, we have this MIME review to decide if the format should be "text" or "video". -- Colin Perkins http://csperkins.org/

3 2

RE: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and Media Types)
by Biot Olivier 12 Aug '04

12 Aug '04

5 6

draft-hoschka-smil-media-type-12.txt
by Larry Masinter 09 Aug '04

09 Aug '04

I think the document should explain why it is that it registers both application/smil and application/smil+xml with exactly the same meaning. I think the answer is likely that this was a mistake, that application/smil+xml is recommended, but that 'application/smil' is in use in some parts of the community already, and it was thought better to register it as a valid alias. But I'm not sure; I'm not even sure it's a good idea to do this. Perhaps we want to separate out 'recommended' practice (as you would find in an IESG approved document or a W3C 'Recommendation') from some other kind of registration, e.g., ask IANA to register 'application/smil' with a notation "MIME type used for what is officially registered as application/smil+xml'. > The definition is based on RFC3023 defining the use of the > "application/xml" media type [3]. Before using the "application/smil" > or "application/smil+xml" media type, implementors must thus be > familiar with [3]. As far as I can tell, [3] has nothing to say about 'application/smil'. > This parameter is meant to be used in MIME media type based content > negotiation (such as that done with the HTTP "Accept" header) to > negotiate for a variety of SMIL based languages. It is modelled after > the "profile" parameter in the application/xhtml+smil MIME type > registration [4], and is motivated by very similar considerations. Presumably you mean xhtml+xml, not xhtml+smil. Is there any positive experience using media type parameters in content negotiation, in general, or in particular with "profile" with xhtml+xml, and not using, say, media features? > It is suggested that the "profile" parameter be > used until the CC/PP protocol work has been finalized. By whom would this parameter be used?

1 0

Fwd: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and Media Types)
by Colin Perkins 09 Aug '04

09 Aug '04

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

1 0

MIME-type Review Request: draft-ietf-avt-rtp-dsr-codecs-03.txt
by Hollenbeck, Scott 09 Aug '04

09 Aug '04

This is a request for MIME-type review for this document: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-dsr-codecs-03.txt Please send comments to both the ietf-types list and the cc recipients listed on this message. Thank you, -Scott-

1 0

Review Request: The Codecs Parameter for "Bucket" Media Types
by Randall Gellens 04 Aug '04

04 Aug '04

draft-gellens-mime-bucket-00 proposes adding a new parameter to certain media types: Abstract Several MIME type/subtype combinations exist which can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from the Content-Type alone if the content can be rendered. This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs required to support the media formats contained within. By labelling content with the specific codecs required to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, etc.)

1 0

Request for MIME media type application/vnd.3gpp.sms-tl
by Biot Olivier 29 Jul '04

29 Jul '04

Name : Olivier Biot Email : olivier.biot(a)siemens.com MIME media type name : Application MIME subtype name : Vendor Tree - vnd.3gpp.sms-tl Required parameters : none Optional parameters : none Encoding considerations : binary This media type is 8-bit binary by design, hence it may require encoding on transports not capable of handling binary. The SMS service allows transport of text messages; however the character encoding used in such an SMS message (including the message text itself) is part of the binary data and must not be specified with a charset parameter. Security considerations : The Short Messaging Service Transfer Layer (SMS-TL) format may contain executable code and user confidential information. The associated media type does not provide mechanisms for detection and prevention of eavesdropping, spoofing and tampering. In situations where tampering, eavesdropping and spoofing are possible and may cause problems, it is advised to use a secure transport protocol (such as HTTP over TLS), and/or to use a safe integrity verification mechanism (such as digital signing of the body). Interoperability considerations : The SMS-TL MIME type allows transport interoperability between the Short Messaging Service (SMS) and other messaging systems supporting SMS-TL, and some transport layer independence for transporting an SMS message. This media type contains headers and a SMS message body. The headers specify among others how the message body has to be interpreted. The message body can for example be a text message, but also a WAP Push message or an Enhanced Message Service (EMS) message for example. In order to be interoperable for these, it makes sense to use the 3GPP SMS-TL as an envelope which you can type and send over a MIME friendly transport where a Content-Type header identifies the data type. Published specification : ETSI TS 123 040 is the technical realization of 3GPP TS 23.040. Note that both specifications follow a similar versioning system. For instance, ETSI TS 123 040 V4.6.0 is the technical realization of 3GPP TS 23.040 V4.6.0. The ETSI specifications can be retrieved from http://pda.etsi.org/pda/queryform.asp (Search for "TS 123 040" and tick "Standard Type and Doc Number" for the search query). The 3GPP specifications can be retrieved from http://www.3gpp.org/ftp/Specs/archive/23_series/23.040/ (choose matching 3GPP and ETSI version). Applications which use this media : Applications that transport and manipulate MIME typed objects (messaging, download etc.). Additional information : This (binary) media type is not intended for file storage. 1. Magic number(s) : n/a 2. File extension(s) : n/a 3. Macintosh file type code : n/a 4. Object Identifiers: n/a Person to contact for further information : 1. Name : Olivier Biot 2. Email : olivier.biot(a)siemens.com Intended usage : Common The Short Messaging Service (SMS) is a very common messaging service available on most mobile networks. SMS is not limited to the popular transport of text-only messages. The registration of the associated MIME type allows a SMS message to be delivered independent of the transport network. Author/Change controller : 3GPP/ETSI The SMS-TL specifications are written and maintained by 3GPP and ETSI.

1 0

RE: Request for MIME media type Application/Vendor Tree - vnd.3gp p.sms-tl
by Biot Olivier 29 Jul '04

29 Jul '04

|From: Martin Duerst | | |At 11:52 04/07/28 +0200, Biot Olivier wrote: | |>The SMS service allows transport of text messages; however |the character set |>used in such an SMS message (including the message text |itself) is part of |>the binary data and must not be specified with the charset parameter. | |Thanks for the clarification. Apart from the change suggested by Ned, |I would change "character set" to "character encoding". I agree. |I would also be interested to know (doesn't necessarily need to show |up in the registration) what kind of encodings are supported. For |example, does SMS allow message text to be encoded in an Unicode- |based encoding? Are all the encodings supported registered as |IANA 'charset's, or are there others? According to 3GPP TS 23.038 (alphabets and language-specific information), the GSM SMS data coding allows GSM 7-bit alphabet (which allows to stuff up to 160 characters in 140 bytes), 8-bit data and 16-bit Unicode UCS-2 character encoding. The used data coding is encoded in binary fashion in the GSM SMS "data coding scheme", and has no relationship with (read: does not use) the "charset" tokens registered at IANA (although the used character encodings are identical). Best regards, Olivier

1 0

RE: Request for MIME media type Application/Vendor Tree - vnd.3gp p.sms-tl
by Biot Olivier 29 Jul '04

29 Jul '04

Hi list, Many thanks to all for your valuable review input. Please find an updated MIME media type registration application for "application/vnd.3gpp.sms-tl". I think I dealt with all the issues raised during the review. Please let me know if the application below is OK! Best regards, Olivier Biot ------------------------------------------------------------ Name : Olivier Biot Email : olivier.biot(a)siemens.com MIME media type name : Application MIME subtype name : Vendor Tree - vnd.3gpp.sms-tl Required parameters : none Optional parameters : none Encoding considerations : binary This media type is 8-bit binary by design, hence it may require encoding on transports not capable of handling binary. The SMS service allows transport of text messages; however the character set used in such an SMS message (including the message text itself) is part of the binary data and must not be specified with the charset parameter. Security considerations : The Short Messaging Service Transfer Layer (SMS-TL) format may contain executable code and user confidential information. The associated media type does not foresee mechanisms for detection and prevention of eavesdropping, spoofing and tampering. In situations where tampering, eavesdropping and spoofing are possible and may cause problems, it is advised to use a secure transport protocol (such as HTTP over TLS), and/or to use a safe integrity verification mechanism (such as digital signing of the body). Interoperability considerations : The SMS-TL MIME type allows transport interoperability between the Short Messaging Service (SMS) and other messaging systems supporting SMS-TL, and some transport layer independence for transporting an SMS message. This media type contains headers and a SMS message body. The headers specify among others how the message body has to be interpreted. The message body can for example be a text message, but also a WAP Push message or an Enhanced Message Service (EMS) message for example. In order to be interoperable for these, it makes sense to use the 3GPP SMS-TL as an envelope which you can type and send over a MIME friendly transport where a Content-Type header identifies the data type. Published specification : ETSI TS 123 040 is the technical realization of 3GPP TS 23.040. Note that both specifications follow a similar versioning system. For instance, ETSI TS 123 040 V4.6.0 is the technical realization of 3GPP TS 23.040 V4.6.0. The ETSI specifications can be retrieved from http://pda.etsi.org/pda/queryform.asp (Search for "TS 123 040" and tick "Standard Type and Doc Number" for the search query). The 3GPP specifications can be retrieved from http://www.3gpp.org/ftp/Specs/archive/23_series/23.040/ (choose matching 3GPP and ETSI version). Applications which use this media : Applications that transport and manipulate MIME typed objects (messaging, download etc.). Additional information : This (binary) media type is not intended for file storage. 1. Magic number(s) : n/a 2. File extension(s) : n/a 3. Macintosh file type code : n/a 4. Object Identifiers: n/a Person to contact for further information : 1. Name : Olivier Biot 2. Email : olivier.biot(a)siemens.com Intended usage : Common The Short Messaging Service (SMS) is a very common messaging service available on most mobile networks. SMS is not limited to the popular transport of text-only messages. The registration of the associated MIME type allows a SMS message to be delivered independent of the transport network. Author/Change controller : 3GPP/ETSI The SMS-TL specifications are written and maintained by 3GPP and ETSI.

3 2