April 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 application held+xml type
by Cullen Jennings 28 Apr '08

28 Apr '08

Could folks please review the type defined in http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-07 and sends comments before May 18th. Thanks, Cullen

4 3

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