March 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

Review request of media type application/richmediacommand+xml
by Torkel Hambraeus 01 Apr '08

01 Apr '08

Please review the following media type registration. Type name: application Subtype name: richmediacommand+xml Required parameters: none Optional parameters: charset useFullRequestHost pathComponents Encoding considerations: Same as for application/xml. See [7]RFC3023 , section 3.2. Security considerations: The media type defines update commands to data viewed by an end user. Updates from an mallicious source can performe harmful changes to the image viewed by the end user. A specific form of updates consists of scripts executed by the reciever of the media type. If the scripting language so permitts access to data can be given allowing this data to be disclosed to unintended parties. It is allso possible for content to surge computational and memory resources from the reciever. Interoperability considerations: none Published specification: OMA Rich Media Enabler Technical Specification The latest version of the specification can be found at: http://member.openmobilealliance.org/ftp/public_documents/bt/MAE/Permanent_… Applications that use this media type: Applications implementing the Rich Media Enable Technical Specification. Typically these are rich media environments on mobile devices. Additional information: Magic number(s): None File extension(s): scg Macintosh file type code(s): None Person & email address to contact for further information: torkel.hambraeus(a)ikivo.com Intended usage: COMMON Restrictions on usage: none Author: The author of this specification is the Open Mobile Alliance working group Browsers Technology. See http://www.openmobilealliance.org/Technical/browser_technologies.aspx. Change controller: Change control of this specificaiton is done by Open Mobile Alliance working group Browsers Technology. See http://www.openmobilealliance.org/Technical/browser_technologies.aspx. Torkel Hambraeus Senior Technical Lead ________________________________________________ Ikivo AB Östermalmsgatan 87 C SE-114 59 Stockholm Sweden Email: torkel.hambraeus(a)ikivo.com <mailto:torkel.hambraeus@ikivo.com> http://www.ikivo.com <http://www.ikivo.com/> The information transmitted in this email and any attachment(s) is intended solely for the addressee(s) and may contain confidential, proprietary or privileged material. Any review, retransmission, dissemination, reproduction, disclosure, reliance upon or any other use of this information by persons or entities other than the intended recipient(s) is strictly prohibited. If you received this email in error, please notify the sender and delete all related material forthwith.

2 2

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