- Ietf-types - alvestrand.no

Request review: draft-ietf-avt-rtp-speex-05.txt
by Colin Perkins 31 Mar '08

31 Mar '08

The AVT working group requests media type review for the audio/speex media subtype defined in section 4.1 of draft-ietf-avt-rtp- speex-05.txt. This is currently in working group last call. We would be grateful if comments could be made by 14 April 2008. Thanks, Colin (AVT co-chair)

1 0

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

Proposed media types
by Luther Martin 14 Feb '08

14 Feb '08

Summary: three media types are proposed: application/ibe-pp-request, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml. Background Identity-based encryption (IBE) is a public key technology in which public keys are calculated from an arbitrary string instead of being generated randomly or calculated from random components. This string typically represents the identity of a user. The user then receives the private key corresponding to a public key from a secure server called a private key generator (PKG). The technology is fairly widely deployed, being used by multiple vendors and roughly 6 million users worldwide. A set of global public parameters are required that define the mathematical operations that IBE calculations require. These parameters are downloaded from a server as specified in draft-smime-ibearch-07 and its successors. Once a client has these parameters, it can then calculate IBE public keys and can use both IBE public and private keys in cryptographic operations. The calculation of such public and private keys and their use to encrypt and decrypt is described in RFC 5091. To request an IBE private key, a user passes the parameters that are defined in draft-smime-ibearch-07 and its successors to a PKG. If the user can successfully authenticate to the PKG according to the PKG's security policy then the corresponding private key is calculated and provided to the user as defined in draft-smime-ibearch-07 and its successors. To support the use of IBE, we propose the definition of three new media types: application/ibe-pp-request, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml. These are further described below. ----- MIME media type name: application MIME subtype name: ibe-pp-request Mandatory parameters: The single required parameter is a base64-encoded DER-encoded IBESysParams structure as defined in draft-ieft-smime-ibearch-07 and its successors. Optional parameters: There are no optional parameters. Encoding considerations: This media type MUST be encoded as 7bit (us-ascii text). Security considerations: The data conveyed as this media type are the public parameters needed for the operation of a cryptographic system. To ensure that the parameters can be trusted, the request for these parameters must take place over a secure protocol, TLS 1.1 or its successors. To ensure the validity of the server, the client must verify the server certificate and must abort the parameter request if the server certificate of the TLS connection fails. This proposed media type contains no active content and does not use compression. Interoperability considerations: There are no known interoperability considerations for this proposed media type. Published specification: This media type is defined in draft-ietf-smime-ibearch-07 and its successors. Applications that use this media type: Applications that implement IBE in compliance with draft-ietf-smime-ibearch-07 and its successors will use this media type. The most commonly-used of these applications are encrypted email and file encryption. Additional information: This media type is used for the response from a public parameter server after receiving a request for IBE public parameters. This proposed media type contains no active content and does not use compression. Person and email address for further information: Luther Martin, martin(a)voltage.com. Intended usage: COMMON. Author/Change controller: Luther Martin, martin(a)voltage.com. ----- MIME media type name: application MIME subtype name: ibe-key-request+xml Mandatory parameters: The required parameters are the identity for which an IBE private key is being requested and an object identifier that identifies which cryptographic algorithm the key is being requested for. The identity is the base64-encoding of a DER-encoded ibeIdentityInfo structure as defined in draft-ietf-smime-ibearch-07 and its successors. The object identifier is the base64-encoding of a DER-encoded object identifier, like those defined in RFC 5091. Optional parameters: Any optional parameters may be defined by an administrator of a particular PKG. The most common optional parameter is an authentication credential. As described in draft-ietf-smime-ibearch-07 and its successors, a PKG may redirect a request for an IBE private key to an external authentication mechanism, the reply from which is then included as this optional parameter in a subsequent key request. Other optional parameters may include other information as required by particular implementations. An example of this from an existing implementation is a bank that has clients pass branding information along with a key request so that mortgage customers see a different user interface than non-mortgage customers do, for example. Encoding considerations: This media type MUST be encoded as us-ascii. Security considerations: The data conveyed in this media type may contain authentication credentials. Because of this, its confidentiality and integrity is extremely important. To ensure this, the request for an IBE private key must take place over a secure protocol, TLS 1.1 or its successors. To ensure the validity of the server, the client must verify the server certificate and must abort the parameter request if the server certificate of the TLS connection fails. This proposed media type contains no active content and does not use compression. Interoperability considerations: There are no known interoperability considerations for this proposed media type. Published specification: This is defined in draft-ietf-smime-ibearch-07 and its successors. Applications that use this media type: Applications that implement IBE in compliance with draft-ietf-smime-ibearch-07 and its successors will use this media type. The most commonly-used of these applications are encrypted email and file encryption. Additional information: This media type is used for the data that is passed to an IBE PKG by a client requesting an IBE private key. This proposed media type contains no active content and does not use compression. Person and email address for further information: Luther Martin, martin(a)voltage.com. Intended usage: COMMON. Author/Change controller: Luther Martin, martin(a)voltage.com. ----- MIME media type name: application MIME subtype name: ibe-pkg-reply+xml Mandatory parameters: The only required parameter is a response code which indicates the status of a key request. Other parameters may be also required, depending on the nature of the response from the PKG. For example, for the responseCode IBE100 ("key follows"), an IBE private key is also a required parameter. The list of defined responses is given in draft-ietf-smime-ibearch-07 and its successors. Optional parameters: None. Encoding considerations: This media type MUST be encoded as us-ascii. Security considerations: The data conveyed as this media type is an IBE private key, so its confidentiality and integrity is extremely important. To ensure this, the response from the server that contains an IBE private key must take place over a secure protocol, TLS 1.1 or its successors. To ensure the validity of the server, the client must verify the server certificate and must abort the parameter request if the server certificate of the TLS connection fails. This proposed media type contains no active content and does not use compression. Interoperability considerations: There are no known interoperability considerations for this proposed media type. Published specification: This media type is defined in draft-ietf-smime-ibearch-07 and its successors. Applications that use this media type: Applications that implement IBE in compliance with draft-ietf-smime-ibearch-07 and its successors will use this media type. The most commonly-used of these applications are encrypted email and file encryption. Additional information: This media type is used for the response from a PKG after receiving a request for an IBE private key. This proposed media type contains no active content and does not use compression. Person and email address for further information: Luther Martin, martin(a)voltage.com. Intended usage: COMMON. Author/Change controller: Luther Martin, martin(a)voltage.com.

2 3