- Ietf-types - alvestrand.no

Request for review of DMB Application format media types: video/dmb
by Houari 04 Dec '07

04 Dec '07

Dear all The following is the request for review for Digital Multimedia Broadcasting Application Format, on behalf of editors of ISO/IEC 23000-9 (MPEG-A Part 9: Digital Multimedia Broadcasting Application Format). There will be also another two requests for audio/dmb and application/dmb. Please feel free to comment. Thank you in advance. MIME media type name : Video MIME subtype name : Standards Tree -dmb Required parameters : none Optional parameters : none Encoding considerations : binary This media type may require encoding on transports not capable of handling binary. Security considerations : It is not possible to inject supported components other than those are specified in the DMB AF specification (ISO/IEC 23000-9) in the dmb file. This might prevent to crash the receiver or temporarily make it unavailable. The authentication mechanism can be used to validate of the sender and the data to prevent security problems due to non-compliant malignant dmb file. Interoperability considerations : A number of interoperating implementations exist within the ISO/IEC 23000 community, and that community has reference software for reading and writing the file format. Published specification : Not published yet. However, ISO/IEC 23000-9 is currently at FDIS stage and expected to be published in Jan. 2008. Applications which use this media : Multimedia Additional information : 1. Magic number(s) : none 2. File extension(s) : dmb 3. Macintosh file type code : dmb 4. Object Identifiers: none Person to contact for further information : 1. Name : Hui Yong Kim 2. Email : hykim5(a)etri.re.kr Intended usage : Common Author/Change controller : Hui Yong Kim, editor of ISO/IEC 23000-9 Digital Multimedia Broadcasting Application Format Regards, - Houari Send instant messages to your online friends http://uk.messenger.yahoo.com

2 1

Request for review of DMB Application format media types: application/dmb
by Houari 04 Dec '07

04 Dec '07

MIME media type name : Application MIME subtype name : Standards Tree -dmb Required parameters : none Optional parameters : none Encoding considerations : binary This media type may require encoding on transports not capable of handling binary. Security considerations : It is not possible to inject supported components other than those are specified in the DMB AF specification (ISO/IEC 23000-9) in the dmb file. This might prevent to crash the receiver or temporarily make it unavailable. The authentication mechanism can be used to validate of the sender and the data to prevent security problems due to non-compliant malignant dmb file. Interoperability considerations : A number of interoperating implementations exist within the ISO/IEC 23000 community, and that community has reference software for reading and writing the file format. Published specification : Not published yet. However, ISO/IEC 23000-9 is currently at FDIS stage and expected to be published in Jan. 2008. Applications which use this media : Multimedia Additional information : 1. Magic number(s) : none 2. File extension(s) : dmb 3. Macintosh file type code : dmb 4. Object Identifiers: none Person to contact for further information : 1. Name : Hui Yong Kim 2. Email : hykim5(a)etri.re.kr Intended usage : Common Author/Change controller : Hui Yong Kim, editor of ISO/IEC 23000-9 Digital Multimedia Broadcasting Application Format - Houari Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Request for review of DMB Application format media types: audio/dmb
by Houari 04 Dec '07

04 Dec '07

MIME media type name : Audio MIME subtype name : Standards Tree -dmb Required parameters : none Optional parameters : none Encoding considerations : binary This media type may require encoding on transports not capable of handling binary. Security considerations : It is not possible to inject supported components other than those are specified in the DMB AF specification (ISO/IEC 23000-9) in the dmb file. This might prevent to crash the receiver or temporarily make it unavailable. The authentication mechanism can be used to validate of the sender and the data to prevent security problems due to non-compliant malignant dmb file. Interoperability considerations : A number of interoperating implementations exist within the ISO/IEC 23000 community, and that community has reference software for reading and writing the file format. Published specification : Not published yet. However, ISO/IEC 23000-9 is currently at FDIS stage and expected to be published in Jan. 2008. Applications which use this media : Multimedia Additional information : 1. Magic number(s) : none 2. File extension(s) : dmb 3. Macintosh file type code : dmb 4. Object Identifiers: none Person to contact for further information : 1. Name : Hui Yong Kim 2. Email : hykim5(a)etri.re.kr Intended usage : Common Author/Change controller : Hui Yong Kim, editor of ISO/IEC 23000-9 Digital Multimedia Broadcasting Application Format - Houari Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re: Review of application/lost+xml
by Mark Baker 26 Nov '07

26 Nov '07

On 11/13/07, Ted Hardie <hardie(a)qualcomm.com> wrote: > This is a request for review application/lost+xml, which is > described in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt . > Comments to the authors or the working group mailing list (ecrit(a)ietf.org) > would be welcome; cc'ing any comments to the AD (Jon Peterson, > jon.peterson(a)neustar.biz) would also be welcome since this is currently > also in his review queue. The media type registration itself is pretty straightforward, though the security considerations section needs work. I have some other comments too, while I'm here. It's unfortunate that HTTP continues to be referred to, and used as, a "transport" protocol. This draft isn't as bad as some others in that respect, but I have some concerns. Chief amoungst these is that LoST errors are returned with HTTP success status codes, which they should not be: even SOAP managed to get this one right 8-). Also, the names of the root XML elements seem to conflate data and protocol, i.e. "findService" and "findServiceResponse". It's the application protocol that determines what constitutes a request and a response, as well as whether the operation is "find" or not (it's not, it's POST). If I were doing this, I'd use "serviceDescription" and "service" or something like that. This is largely aesthetic right now, but in my experience such a change can prevent problems down the line, such as suggesting the use of new root elements for new services that might be added in the future, instead of the proper HTTP-friendly way, new URIs. More generally, I think it would be useful to show evidence that BCP 56 has been consulted in the preparation of the HTTP binding. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com

2 1

Review of application/lost+xml
by Ted Hardie 22 Nov '07

22 Nov '07

This is a request for review application/lost+xml, which is described in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt . Comments to the authors or the working group mailing list (ecrit(a)ietf.org) would be welcome; cc'ing any comments to the AD (Jon Peterson, jon.peterson(a)neustar.biz) would also be welcome since this is currently also in his review queue. thanks, Ted

2 1

Parameters named 'q'
by Bjoern Hoehrmann 22 Nov '07

22 Nov '07

Hi, RFC 2616 discourages naming media type parameters "q" as it uses the name for content negotiation in the Accept header. Unfortunately this never made its way into the registration procedures document. Is there anything we can and should do to transfer the discouragement into BCP 13 (errata, let RFC 2616bis update BCP 13, ...)? regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

1 0

Registration of media type application/vnd.multiad.creator.cif
by Steve Mills 03 Oct '07

03 Oct '07

Type name: application Subtype name: vnd.multiad.creator.cif Required parameters: None. Optional parameters: None. Encoding considerations: Creator CIF files are binary and should be encoded where binary data is not handled. Security considerations: No textual content is encoded and is clearly readable in the binary data. This includes and is not limited to the author's name, pathnames to image files, and text content of text flows. All text data is in Mac ASCII format. Interoperability considerations: None. Published specification: The CIF format is only available to developers who submit requests. Use <creator_support(a)multi-ad.com> as the initial contact. Applications that use this media type: MultiAd Creator Professional Additional information: Magic number(s): First four bytes of CIF document are 0x00640004. File extension(s): cif Macintosh file type code(s): Application signature: Cr40, Cr38, maybe others. CIF document type: 'CIF '. (Note space at end!) Person & email address to contact for further information: Steve Mills. Use <creator_support(a)multi-ad.com> as the initial contact. Intended usage: Common. Restrictions on usage: None. Author: Steve Mills, see contact info above. Change controller: Steve Mills, see contact info above. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd smills(a)multiad.com www.multi-ad.com

1 1

Registration of media type application/vnd.multiad.creator
by Steve Mills 03 Oct '07

03 Oct '07

Type name: application Subtype name: vnd.multiad.creator Required parameters: None. Optional parameters: None. Encoding considerations: Creator files are binary and should be encoded where binary data is not handled. Security considerations: No textual content is encoded and is clearly readable in the binary data. This includes and is not limited to the author's name, pathnames to image files, and text content of text flows. Most text data is in UTF16 format. Interoperability considerations: None. Published specification: The Creator file format is only available to developers who submit requests. Use <creator_support(a)multi-ad.com> as the initial contact. Applications that use this media type: MultiAd Creator Professional Additional information: This specification is for Creator version 6.0 or higher. Earlier releases of Creator use different Mac type codes and did not use file name extensions. Magic number(s): First four bytes of Creator document are "Ctr6". File extension(s): crtr Macintosh file type code(s): Application signature: Crtr. Creator document type: Crtr. Person & email address to contact for further information: Steve Mills. Use <creator_support(a)multi-ad.com> as the initial contact. Intended usage: Common. Restrictions on usage: None. Author: Steve Mills, see contact info above. Change controller: Steve Mills, see contact info above. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd smills(a)multiad.com www.multi-ad.com

1 0

Request for review of video/jpeg2000 media type
by Colin Perkins 24 Sep '07

24 Sep '07

The AVT working group requests media type review for the video/ jpeg2000 media type defined in section 8.1 of draft-ietf-avt-rtp- jpeg2000-18.txt and section 7.1 of draft-ietf-avt-rtp-jpeg2000- beam-09.txt. These drafts have recently completed working group last call. We would be grateful if any comments could be made by 8th October 2007. Thanks, Colin Perkins (AVT co-chair)

1 0

RE: Media Type Registration for OCF (application/epub+zip) - Review of Informational RFC
by Nick Bogaty 12 Sep '07

12 Sep '07

To whom it may concern, We apologize for the errors in our previous submissions. Please see the below URL pointing to a Media Type Registration for the Open Container Format (OCF), "application/epub+zip", to be processed as an informational RFC. It has gone through a two week community review period via the iesg(a)ietf.org and ietf-types(a)iana.org. The application/template is located at: http://www.idpf.org/draft-conboy-mime-opf-00.txt The published epub specification can be found at: http://www.idpf.org/ocf/ocf1.0/download/ocf10.htm Please send any questions to myself, Nick Bogaty, at nbogaty(a)idpf.org. Thanks, Nick -- Nick Bogaty Executive Director International Digital Publishing Forum (IDPF) nbogaty(a)idpf.org www.idpf.org (212) 924-9081 direct (212) 208-0978 fax

4 7