- Ietf-types - alvestrand.no

Transport Area requests Media Type review for 3GPP2 MIME registrations
by Allison Mankin 05 Jul '05

05 Jul '05

The Transport Area requests a Media Type review for the registrations in draft-garudadri-avt-3gpp2-mime-02.txt, intended for the standards tree. The draft is submitted for Proposed Standard. One change is known: The reference to [bucket] will be updated to draft-gellens-mime-bucket-04.txt, which is now on the RFC Editor Queue. Please provide any comments as soon as possible, and before July 20, 2005. Thanks, Allison Transport Area Director

1 0

Request to review Media type registration in draft-ietf-avt-rtp-ac3-07.txt
by Magnus Westerlund 29 Jun '05

29 Jun '05

Hi, Please review the media type registration for the AC-3 RTP payload format before 20th of July. http://ietf.levkowetz.com/drafts/avt/rtp-ac3/draft-ietf-avt-rtp-ac3-07.txt Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

1 0

Input Needed: Media Type Registry Structure
by Scott Hollenbeck 24 Jun '05

24 Jun '05

Community input needed: During IESG evaluation of draft-hoehrmann-script-types, one of the General Area reviewers provided this comment: "IANA seems to have figured out that the types to be registered are MIME media types but probably should be told how to indicate that the two text/ registrations are obsolete, or at least that it is important to mark these registrations as obsolete in the registry (unless the OBSOLETE intended usage field in the registration suffices, but marking the registry entry will be more effective)." Follow-up discussion within the IESG has prompted this query. The templates in draft-hoehrmann-script-types use the "Intended Usage" field in the templates to note that two of the types are obsolete. The reviewer is suggesting that this status be displayed more obviously at a higher level within the registry. This isn't exactly an issue for the document being reviewed, but it might be an issue for the structure of the registry. Should the registry structure be changed to display the status of obsolete (or any other) types more prominently? If so, we might need a new document or a revision to draft-freed-media-type-reg to describe whatever changes are needed. -Scott-

6 6

Fwd: [AVT] I-D ACTION:draft-ietf-avt-rtp-3gpp-timed-text-15.txt
by Colin Perkins 14 Jun '05

14 Jun '05

The AVT working group requests a media types review for the updated 3GPP timed text draft. There was much recent discussion on this subject, and this draft is intended to address the concerns expressed. Colin (AVT co-chair) Begin forwarded message: > From: "Jose Rey" <Jose.Rey(a)eu.panasonic.com> > Date: 14 June 2005 08:33:16 BDT > To: <avt(a)ietf.org> > Subject: FW: [AVT] I-D ACTION:draft-ietf-avt-rtp-3gpp-timed- > text-15.txt > > Hi all, > > A new version is out. This update includes some very minor > editorial changes as well as those changes agreed during the Media > Type discussions (below.) > > Looking forward to WGLC! > > José > > ---------------------------------------------------------------------- > ----- > > - Section 2.1, p.4: remove paragraph that causes confusion > > REMOVED: > > The scope of the 3GPP PSS specification (in the following > referred to > as PSS) includes both downloading and streaming of multimedia > content > over 3G packet-switched networks. PSS adopts multimedia codecs > such > as MPEG-4 Visual [22], AMR wide-band [23] or MPEG-4 AAC [24] for > encoding content. Other protocols like RTSP [15] for session > set-up > and control, or SMIL [9] for handling presentation layouts. For > transport, HTTP over TCP is used for downloading and RTP for > streaming. > > > - Section 8: > OLD: > The media subtype for the 3GPP Timed Text codec is allocated > from the > IETF tree. The top-level media type under which this payload > format > is registered is 'text'. > > The receiver MUST ignore any unrecognized parameter. > > Media type: text > > NEW: > The media subtype for the 3GPP Timed Text codec is allocated > from the > standards tree. The top-level media type under which this payload > format is registered is 'video'. This registration is done > using the > template defined in [31] and following RFC 3555 [30]. > > The receiver MUST ignore any unrecognized parameter. > > Media type: video > > > OLD: > Encoding considerations: > > RTP payloads complying with this payload format contain > binary > data. > > Note that this type is incompatible with the use of text > media > types in other protocols, e.g. text/html. This is because in > order to extract and decode any of the timed text media it is > necessary understand the (binary) payload headers defined in > RFCXXXX. > > Restrictions on usage: > > This type is only defined for transfer via RTP. > > > NEW: > Encoding considerations: > > This media type is framed (see section 4.8 in [31]) and > partially contains binary data. > > Restrictions on usage: > > This media type depends on RTP framing, and hence is only > defined for > transfer via RTP [RFC 3550]. Transport within other > framing protocols > is not defined at this time. > > OLD: > Interoperability considerations: > > The 3GPP Timed Text media format and its storage is > specified in > Release 6 of 3GPP TS 26.245 "Transparent end-to-end packet > switched streaming service (PSS); Timed Text Format (Release > 6)". The 3GPP file format (3GP) and the SMIL language > profile > used can be found in Release 5 of 3GPP TS 26.234 and in the > corresponding specifications for later Releases. Note > also that > 3GPP may in future Releases specify extensions or updates > to the > timed text media format in a backwards-compatible way, > e.g. new > modifier boxes or extensions to the sample descriptions. The > payload format defined in RFCXXXX allows for such extensions. > For future 3GPP Releases of the Timed Text Format, the > parameter > "sver" is used to identify the exact specification used. > > NEW: > Interoperability considerations: > > The 3GPP Timed Text media format and its file storage is > specified in Release 6 of 3GPP TS 26.245 "Transparent end- > to-end > packet switched streaming service (PSS); Timed Text Format > (Release 6)". Note also that 3GPP may in future Releases > specify extensions or updates to the timed text media > format in > a backwards-compatible way, e.g. new modifier boxes or > extensions to the sample descriptions. The payload format > defined in RFCXXXX allows for such extensions. For future > 3GPP > Releases of the Timed Text Format, the parameter "sver" is > used > to identify the exact specification used. > > The defined storage format for 3GPP Timed Text format is > the 3GPP File > Format (3GP) [32]. 3GP files may be transferred using the > media type > video/3gpp as registered by RFC 3839 [33]. The 3GPP File > Format is a container > file that may contain, e.g., audio and video which may be > synchronized with the > 3GPP Timed Text. > > > - Section 12.2: New informative references > > REMOVED: > > References 22, 23 and 24 > > NEW: > > [30] Casner, S. and P. Hoschka, "MIME Type Registration of RTP > Payload Formats", RFC 3555, July 2003. > > [31] Freed, N. and J. Klensin, "Media Type Specifications and > Registration Procedures", draft-freed-media-type-reg-04, > April 2005. > > [32] Transparent end-to-end packet switched streaming service > (PSS); > 3GPP file format (3GP) (Release 6), TS 26.244 V6.3. March > 2005. > > [33] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd > Generation Partnership Project (3GPP) Multimedia files", > RFC 3839, July 2004. > > -- >> -----Original Message----- >> From: avt-bounces(a)ietf.org [mailto:avt-bounces@ietf.org] On >> Behalf Of Internet-Drafts(a)ietf.org >> Sent: Monday, June 13, 2005 9:37 PM >> To: i-d-announce(a)ietf.org >> Cc: avt(a)ietf.org >> Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-3gpp-timed-text-15.txt >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Audio/Video Transport >> Working Group of the IETF. >> >> Title : RTP Payload Format for 3GPP Timed Text >> Author(s) : J. Rey, Y. Matsui >> Filename : draft-ietf-avt-rtp-3gpp-timed-text-15.txt >> Pages : 59 >> Date : 2005-6-13 >> >> This document specifies an RTP payload format for the transmission of >> 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed >> text is a time-lined decorated text media format with >> defined storage >> in a 3GP file. Timed Text can be synchronized with audio/video >> contents and used in application such as captioning, titling and >> multimedia presentations. In the following sections the >> problems of >> streaming timed text are addressed and a payload format >> for streaming >> 3GPP timed text over RTP is specified. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed- >> text-15.txt >

1 0

Registration of MIME media type application/rnc
by MURATA Makoto 11 Jun '05

11 Jun '05

This is a request for registration in the standard tree. The compact syntax for RELAX NG (a schema language for XML) will be published as a Final Draft Amendment (FDAM) of ISO/IEC 19757-4 soon. The FDAM will contain this registation information. If this FDAM passes a two-month FDAM ballot, it will become an Amendment of ISO/IEC 197575-4. Since this FDAM ballot does not allow any technical comments and many member bodies of ISO/IEC JTC1 simply say yes, the FDAM is extremely likely to pass the ballot. The compact syntax was first published as an OASIS committee specification. MIME media type name: application MIME subtype name: rnc Required parameters: none Optional parameters: none Encoding considerations: UTF-8 or UTF-16 shall be used for this media type. Security considerations: When the RELAX NG validator retrieves a schema in the RELAX NG compact syntax, it may further retrieve external schemas that are referenced from the schema directly or indirectly. Although the RELAX NG validator is required not to retrieve an infinite number of schemas, a large number of external schemas may be retrieved, thus wasting the network, disk, and CPU power. Interoperability considerations: RELAX NG has been widely used as an XML schema language. A notable example is the Open Document specification of OASIS. Published specification: ISO/IEC 19757-2, Document Schema Definition Language (DSDL) Part 2 - Regular-grammar-based validation -- RELAX NG, Amendment 1: Compact Syntax OASIS Committee Specification, RELAX NG Compact Syntax 21 November 2002 Applications which use this media type: validators, schema authoring tools, and so forth Additional information: Magic number(s): none File extension(s): rnc Macintosh File Type Code(s): "TEXT" Person & email address to contact for further information: MURATA Makoto (FAMILY Given), International University of Japan, eb2m-mrt(a)asahi-net.or.jp Intended usage: COMMON Author/Change controller: ISO/IEC JTC1/SC34 -- MURATA Makoto <murata(a)hokkaido.email.ne.jp>

5 18

Re: [AVT] Re: Request to review media type in AVT working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Magnus Westerlund 05 Jun '05

05 Jun '05

Hi Tom, Tom Taylor wrote: > Simple question: do you expect a given session to consist of just one > character encoding (UTF-8 or UTF-16) or do you want the possibility for > it to contain a mixture? If the encoding is a per-session attribute it > makes more sense for it to be negotiated out-of-band, as a parameter of > the MIME type (and hence as an SDP "a=fmtp" parameter). > To my understanding a session may contain a mixture of UTF-8 and UTF-16. Note also, that removing the bit wouldn't result in any byte savings. So I see it as necessary to have the U bit. Duplicating the information is mostly a recipe for confusion when it doesn't agree. Thus, I propose to leave it out. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

3 2

RE: [AVT] Re: Request to review media type in AVT working grouplastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Jose Rey 03 Jun '05

03 Jun '05

[sorry for delay.. I am travelling] Ned, Tom, > > > Hi Tom, > > > Tom Taylor wrote: > > > Simple question: do you expect a given session to consist of just > > > one character encoding (UTF-8 or UTF-16) or do you want the > > > possibility for it to contain a mixture? If the encoding is a > > > per-session attribute it makes more sense for it to be negotiated > > > out-of-band, as a parameter of the MIME type (and hence > as an SDP "a=fmtp" parameter). > > > > > > To my understanding a session may contain a mixture of > UTF-8 and UTF-16. This is correct. > > That implies that the bit isn't aligned with where media > types appear. And that in turn makes it inappropriate to map > to a media type parameter, irrespective of whether or not it > is used for negotiation. > Yes. Since all is fine now, I will make the changes and send a new draft in the next days. José

1 0

Re: [AVT] Re: Request to review media type in AVT working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Ned Freed 03 Jun '05

03 Jun '05

> Simple question: do you expect a given session to consist of just one > character encoding (UTF-8 or UTF-16) or do you want the possibility for > it to contain a mixture? If the encoding is a per-session attribute it > makes more sense for it to be negotiated out-of-band, as a parameter of > the MIME type (and hence as an SDP "a=fmtp" parameter). Yes, this is what I was trying to get at when I asked if the bit appears in the same context as the media type or not. Ned

1 0

RE: [AVT] Re: Request to review media type in AVT working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Jose Rey 02 Jun '05

02 Jun '05

Ned, > -----Original Message----- > From: avt-bounces(a)ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ned Freed > Sent: Thursday, June 02, 2005 7:50 PM > To: Magnus Westerlund > Cc: Ned Freed; IETF AVT WG; Allison Mankin; Bruce Lilly; > Colin Perkins; ietf-types(a)alvestrand.no > Subject: Re: [AVT] Re: Request to review media type in AVT > working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt > > > Ned Freed wrote: > > > > > > Then why do you need the U bit? > > > From TS 26.245, section 5.1: > > > Text strings for display and font names are uniformly coded > in UTF-8, > > or start with a UTF-16 BYTE ORDER MARK (\uFEFF) and by that > indicate > > that the string which starts with the byte order mark is in UTF-16. > > Terminals shall recognise the byte-order mark in this byte > order; they > > are not required to recognise byte-reversed UTF-16, indicated by a > > byte-reversed byte-order mark. > > > However this payload format removes the Byte Order Mark and > requires a > > specific byte order. Thus to be able to provide the same > information > > that a string is encoded in UTF-8 or UTF-16, it is explicitly > > indicated using the U bit. > > Does the U bit appear in the same context as the media type > itself or is it part of the payload or some other aspect of > the protocol? I don't know what exactly is meant by the latter, but the former is not the case. Besides, apart from complicating session negotiation (O/A, as Magnus mentions) it is really not necessary because both charsets are required by the TT media format. > It seems appropriate to define a mapping to a > parameter if it appears alongside the media type, but not if > it doesn't. [snip] > I'm not suggesting defining additional parameters. I'm only > asking if it makes sense to map and existing session > parameter to a media type parameter. > It doesn't make sense, it is not a negotiable thing. Cheers, José

1 0

Re: [AVT] Re: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Ned Freed 02 Jun '05

02 Jun '05

> I'd like to push back gently on the change from 'text' to 'video', > just to test the waters. > The media types 'video' and 'audio' express what you *get* if you > decode the stream, not how it is *encoded*. They're not call 'float' > or 'integer' or 'huffman', for example. Yet for some reason we want > to reserve the media type 'text' for those that express their > encoding in printable text, without regard for what they are > expressing; this seems inconsistent. No, that's not it at all. The restrictions on the text type have to do with the nature of the underlying data, not with how it is encoded. For example, there's plenty of use of text types, including text/plain, that requires binary encoding and cannot be accomodated by either 7bit or 8bit encodings. There are, however, more restrictions on text that then are on other top-level types. The fact that there are more restrictions may seem inconsistent, but that's how this stuff was defined long ago and it is way too late to change it. > I don't believe that > everything expressed in say XML ought to be considered a 'text' media > type, for example. It's more likely that *nothing* expressed in XML would be considered to be a text media type. Ned

7 9