February 2008 - Ietf-types

Re: Request for review of InkML media type: application/inkml+xml
by Frank Ellermann 25 Aug '08

25 Aug '08

Kazuyuki Ashimura wrote: > the security issues of RFC1738, section 6, should be considered. Please s/RFC1738, section 6/RFC3986, section 7/ if you have no special reasons to use the almost completely obsolete RFC 1738. > Published specification: > ------------------------- > > This media type registration is for InkML documents as described > by this specification. IMO you need a reference for "this" specification, IANA publishes only your registration template, where "this" would make no sense. Frank

2 2

review of audio media subtype UEMCLIP
by Even, Roni 07 Apr '08

07 Apr '08

Hi, The AVT working group requests media type review for the audio/UEMCLIP media subtype defined in section 6.1 of http://tools.ietf.org/html/draft-ietf-avt-rtp-uemclip-04 . This draft is currently in AVT working group last call. We would be grateful if any comments could be made by 21 March 2008. Thanks, Roni Even (AVT co-chair)

3 2

Request and Review of application for addition of ddms+xml MIME Type
by Safa, Pouya 17 Mar '08

17 Mar '08

All, let me begin by mentioning that I am new to the IETF and the registration process and so I am soliciting the group for not only feedback for the proposed addition of "application/ddms+xml" MIME type but also the application process. the below application provides general background and pertinent information. If there's a need for further information, please let me know; your input is greatly appreciated. Name : Pouya Safa Email : psafa(a)fgm.com MIME media type name : Application MIME subtype name : (Standards Tree) ddms+xml Required parameters : identifier, title, creator, subjectCoverage, security Optional parameters : subtitle, description, language, dates, rights, source, type,publisher, contributor, pointOfContact, format, virtualCoverage, temporalCoverage, geospatialCoverage Encoding considerations : 7bit Security considerations : the DDMS utilizes the xs:any tag which may potentially be a security liability. Interoperability considerations : Published specification : The United States DoD Discovery Metadata Specification (DDMS) defines discovery metadata elements for resources posted to community and organizational shared spaces. "Discovery" is the ability to locate data assets through a consistent and flexible search. Visibility, accessibility, and understandability are the high priority goals of the DoD Net-Centric Data Strategy and publicizing DDMS promotes reusability of existing DoD XML based data. Applications which use this media : Any DoD or Intelligence Community XML based application utilizing data interchange and reusability. Additional information : 1. Magic number(s) : none 2. File extension(s) : xml 3. Macintosh file type code : none 4. Object Identifiers: none DDMS specification: https://metadata.dod.mil/mdr/irs/DDMS/index.html <https://metadata.dod.mil/mdr/irs/DDMS/index.html> Person to contact for further information : 1. Name : Pouya Safa 2. Email : psafa(a)fgm.com Intended usage : Common Intended for data interoperability and reuse for the United States DoD and IC applications. Author/Change controller : DoD Data Services Office ____________________________________________ Pouya Safa | FGM Inc. | Direct: 703.885.1403

3 2

Re: Review requested: audio/atrac3 media type registration
by Mark Baker 07 Mar '08

07 Mar '08

Hi, On 2/27/08, actech <actech(a)jp.sony.com> wrote: > Hi Mark, > > We think it is very useful that the all of decoding parameters > are available before decoding, without any parsing of payload data. > For example, if the receiver has only 48000Hz D/A clock, the > receiver can activate sampling rate converter before 44100Hz decoding, > or send back decoder capability(refusal of 44100Hz streaming) to > sender side in SDP offer-answer exchange. > > In addition, we made a discuss with AVT chair that also ATRAC3 > media type registration should have a bit-rate parameter > even if it can be only 44100, considering the consistency > that ATRAC-X and ATRAC Advanced Lossless media type have > bit-rate parameter. Ok, so there seems to be some kind of generic processing model here. Can you describe how that works? I ask because I'm trying to figure out a) how a recipient should interpret the content when either a required parameter is missing or ATRAC3 content is transferred with an ATRAC media type, and b) if the generic processing model is of a variety that might benefit from a "+atrac" extension on media type names similar to "+xml" for XML content. Keep in mind I know nothing about audio formats. Thanks. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com

4 5

Review requested: audio/atrac3 media type registration
by Tom Taylor 27 Feb '08

27 Feb '08

Please review the following media type registration. The source document is http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-13.txt, which is currently undergoing Working Group Last Call in the AVT Working Group. Tom Taylor AVT co-Chair The media subtype for the Adaptive TRansform Codec version 3 (ATRAC3) uses the template defined in RFC 4855 [6]. Note, any unknown parameter MUST be ignored by the receiver. Type name: audio Subtype name: atrac3 Required parameters: rate: Represents the sampling frequency in Hz of the original audio data. Permissible value is 44100 only. baseLayer: Indicates the encoded bit-rate in kbps for the audio data to be streamed. Permissible values are 66, 105 and 132. Optional parameters: ptime: see RFC4566[2] maxptime: see RFC4566[2] The value of the parameter MUST be a multiple of 23.2(ms). If this parameter is not present, the sender MAY encapsulate a maximum of 6 encoded frames into one RTP packet, in streaming of ATRAC3. maxRedundantFrames: The maximum number of redundant frames that may be sent during a session in any given packet under the redundant framing mechanism detailed in the draft. Allowed values are integers in the range of 0 to 15, inclusive. If this parameter is not used, a default of 15 MUST be assumed. Encoding considerations: This media type is framed and contains binary data. Security considerations: See Section 9 of this document. Interoperability considerations: none Published specification: none Applications that use this media type: Audio and video streaming and conferencing tools. Additional information: none Magic number(s): none File extension(s): 'at3', 'aa3', and 'omg' Macintosh file type code(s): none Person & email address to contact for further information: Mitsuyuki Hatanaka actech(a)jp.sony.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP. Author/Change controller: Mitsuyuki Hatanaka actech(a)jp.sony.com

4 5

Re: Review requested: audio/atrac3 media type registration
by Mark Baker 27 Feb '08

27 Feb '08

On 2/26/08, actech <actech(a)jp.sony.com> wrote: > Hi Mark, > > In ATRAC receiver side, it is required to know sampling frequency, bit-rate and > channel configuration in order to switch and initialize the decoder and > associated hardware for immediate starting of ATRAC3, ATRAC-X or ATRAC Advanced > Lossless decoding. > > We think it is the best way to signal above parameters in SDP session with > media type registarion procedure. Hi Jun. I suppose that answers my question about a recipient being able to determine those parameters from the data itself, but I'm still not clear why a parameter is marked as required when it can only have a single value. Is it perhaps because other values may be supported in the future? Some other reason? Mark.

3 2

More on media types for IBE
by Luther Martin 20 Feb '08

20 Feb '08

(Ah, it looks like I'm finally getting list messages, although not anything related to my initial posts yet.) The purpose of my initial post was to address the comments that came up in last call for the two IBE drafts. We used the generic application/octet-stream and application/xhtml+xml, and comments clearly indicated that this was Bad. Thus I've proposed the three additional media types to cover this. All of the other comments on the drafts were easily addressable, and getting these media types is essentially all that's left to do to move the two drafts to RFCs.

2 1

Review requested: audio/atrac-advanced-lossless media type registration
by Tom Taylor 19 Feb '08

19 Feb '08

Please review the following media type registration. The source document is http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-13.txt, which is currently undergoing Working Group Last Call in the AVT Working Group. Tom Taylor AVT co-Chair The media subtype for the Adaptive TRansform Codec Lossless version (ATRAC Advanced Lossless) uses the template defined in RFC 4855 [6]. Note, any unknown parameter MUST be ignored by the receiver. Type name: audio Subtype name: atrac-advanced-lossless Required parameters: rate: Represents the sampling frequency in Hz of the original audio data. Permissible value is 44100 only. baseLayer: Indicates the encoded bit-rate in kbps for the base layer in High-Speed Transfer mode lossless encodings. For Standard lossless mode this value MUST be 0. The Permissible values for ATRAC3 baselayer are 66, 105 and 132. For ATRAC-X baselayer, they are 32, 48, 64, 96, 128, 160, 192, 256, 320 and 352. blockLength: Indicates the block length. In High-speed Transfer mode, the value of 1024 and 2048 is used for ATRAC3 and ATRAC-X based ATRAC Advanced Lossless streaming, respectively. Any value of 512, 1024 and 2048 can be used for Standard mode. channelID: Indicates the number of channels and channel layout according to the table1 in Section 7.4. Note that this layout is different from that proposed in RFC 3551 [3]. However, as channelID = 0 defines an ambiguous channel layout, the channel mapping defined in Section 4.1 of [3] could be used. Permissible values are 0, 1, 2, 3, 4, 5, 6, 7. ptime: see RFC4566[2] maxptime: see RFC4566[2] In streaming of ATRAC Advanced Lossless, a multiple frames can not be transmitted in a single RTP packet, as the frame size is large. So it SHOULD be regarded as the time of one encoded frame in both of the sender and the reciever side. The value of the parameter MUST be 11.5, 23.2 or 46.4(ms). Encoding considerations: This media type is framed and contains binary data. Security considerations: See Section 9 of this document. Interoperability considerations: none Published specification: none Applications that use this media type: Audio and video streaming and conferencing tools. Additional information: none Magic number(s): none File extension(s): 'aal', 'aa3', and 'omg' Macintosh file type code(s): none Person & email address to contact for further information: Mitsuyuki Hatanaka actech(a)jp.sony.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP. Author/Change controller: Mitsuyuki Hatanaka actech(a)jp.sony.com

1 0

Review requested: audio/atrac-x media type registration
by Tom Taylor 19 Feb '08

19 Feb '08

Please review the following media type registration. The source document is http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-13.txt, which is currently undergoing Working Group Last Call in the AVT Working Group. Tom Taylor AVT co-Chair The media subtype for the Adaptive TRansform Codec version X (ATRAC-X) uses the template defined in RFC 4855 [6]. Note, any unknown parameter MUST be ignored by the receiver. Type name: audio Subtype name: atrac-x Required parameters: rate: Represents the sampling frequency in Hz of the original audio data. Permissible values are 44100 and 48000. baseLayer: Indicates the encoded bit-rate in kbps for the audio data to be streamed. Permissible values are 32, 48, 64, 96, 128, 160, 192, 256, 320 and 352. channelID: Indicates the number of channels and channel layout according to the table1 in Section 7.4. Note that this layout is different from that proposed in RFC 3551 [3]. However, as channelID = 0 defines an ambiguous channel layout, the channel mapping defined in Section 4.1 of [3] could be used. Permissible values are 0, 1, 2, 3, 4, 5, 6, 7. Optional parameters: ptime: see RFC4566[2] maxptime: see RFC4566[2] The value of the parameter MUST be a multiple of 46.4(ms) when rate parameter is 44100, and 42.6(ms) when rate parameter is 48000. If this parameter is not present, the sender MAY encapsulate a maximum of 16 encoded frames into one RTP packet, in streaming of ATRAC-X. maxRedundantFrames: The maximum number of redundant frames that may be sent during a session in any given packet under the redundant framing mechanism detailed in the draft. Allowed values are integers in the range 0 to 15, inclusive. If this parameter is not used, a default of 15 MUST be assumed. delayMode: Indicates a desire to use low-delay features, in which case the decoder will process received data accordingly based on this value. Permissible values are 2 and 4. Encoding considerations: This media type is framed and contains binary data. Security considerations: See Section 9 of this document. Interoperability considerations: none Published specification: none Applications that use this media type: Audio and video streaming and conferencing tools. Additional information: none Magic number(s): none File extension(s): 'atx', 'aa3', and 'omg' Macintosh file type code(s): none Person & email address to contact for further information: Mitsuyuki Hatanaka actech(a)jp.sony.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP. Author/Change controller: Mitsuyuki Hatanaka actech(a)jp.sony.com

1 0

registration out of date for multipart/byteranges
by Julian Reschke 16 Feb '08

16 Feb '08

Hi, I just noticed that the registration for multipart/byteranges is out of date. <http://www.iana.org/assignments/media-types/multipart/> points to RFC2068, but it *should* point to RFC2616, Section 19.2. What's the right procedure for raising this issue? BR, Julian

3 2