- Ietf-types - example.com

Registration of media type image/svg+xml
by Chris Lilley 20 Dec '05

20 Dec '05

Hello ietf-types, The SVG WG requests feedback on its standards tree media type registration for image/svg+xml: http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/mimereg.html M.1 Introduction This appendix registers a new MIME media type, "image/svg+xml" in conformance with RegMedia and W3CRegMedia. http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt http://www.w3.org/2002/06/registering-mediatype.html M.2 Registration of Media Type image/svg+xml MIME media type name: image MIME subtype name: svg+xml Required parameters: None. Optional parameters: None The encoding of an SVG document shall be determined by the XML encoding declaration. This has identical semantics to the application/xml media type in the case where the charset parameter is omitted, as specified in RFC3023 sections 8.9, 8.10 and 8.11. Encoding considerations: Same as for application/xml. See RFC3023, section 3.2. Restrictions on usage: None Security considerations: As with other XML types and as noted in RFC3023 section 10, repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in constrained environments to fail. SVG documents may be transmitted in compressed form using gzip compression. For systems which employ MIME-like mechanisms, such as HTTP, this is indicated by the Content-Transfer-Encoding header; for systems which do not, such as direct filesystem access, this is indicated by the filename extension and by the Macintosh File Type Codes. In addition, gzip compressed content is readily recognised by the initial byte sequence as described in RFC1952 section 2.3.1. Several SVG elements may cause arbitrary URIs to be referenced. In this case, the security issues of RFC3986, section 7, should be considered. In common with HTML, SVG documents may reference external media such as images, audio, video, style sheets, and scripting languages. Scripting languages are executable content. In this case, the security considerations in the Media Type registrations for those formats shall apply. In addition, because of the extensibility features for SVG and of XML in general, it is possible that "image/svg+xml" may describe content that has security implications beyond those described here. However, if the processor follows only the normative semantics of this specification, this content will be outside the SVG namespace and shall be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document. Interoperability considerations: This specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements and attributes, both in the SVG namespace and in other namespaces. Because SVG is extensible, conformant "image/svg+xml" processors must expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document. SVG has a published Test Suite and associated implementation report showing which implementations passed which tests at the time of the report. This information is periodically updated as new tests are added or as implementations improve. Published specification: This media type registration is extracted from Appendix M of the SVG 1.2 Tiny specification. http://www.w3.org/TR/SVGMobile12 Additional information: Person & email address to contact for further information: Dean Jackson, Chris Lilley (member-svg-media-type(a)w3.org) Intended usage: COMMON Author/Change controller: The SVG specification is a work product of the World Wide Web Consortium's SVG Working Group. The W3C has change control over these specifications. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG

4 5

Review of DLS media type
by Magnus Westerlund 14 Dec '05

14 Dec '05

Hi, I would like to request review of the DLS media type documented in: http://www.ietf.org/internet-drafts/draft-westerlund-mime-dls-00.txt Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

2 2

Problem with IANA MIME media types registry
by Bruce Lilly 13 Dec '05

13 Dec '05

[CC'd to IETF discussion list and ietf-types discussion list] Hello, Recent changes to the page at http://www.iana.org/assignments/media-types/index.html accessed via the link from the IANA Assigned numbers page http://www.iana.org/numbers.html#M have rendered the registry of assigned media types useless. Prior to the recent change, the media types registry listed the assigned MIME top-level media types, viz. application, audio, image, message, model, multipart, text, and video. Since the change, only the application top-level type is listed (audio, image, message, model, multipart, text, and video have vanished without a trace) and superfluous repetition of the application subtypes listed in http://www.iana.org/assignments/media-types/application has appeared (these of course are not top-level media types). Could you please investigate what has gone awry and regenerate a page that provides top-level media types.

3 3

FW: [blilly@erols.com: Re: Problem with IANA MIME media types registry]
by Michelle Cotton 13 Dec '05

13 Dec '05

Bruce, This has been fixed. The index file was accidentally overwritten with the application media types page. Thank you for letting us know. Best regards, Michelle Cotton IANA ----- Forwarded message from Bruce Lilly <blilly(a)erols.com> ----- Date: Sun, 11 Dec 2005 10:42:22 -0500 Subject: Re: Problem with IANA MIME media types registry From: Bruce Lilly <blilly(a)erols.com> To: mankin(a)psg.com Cc: iana(a)iana.org, webmaster(a)iana.org, ietf(a)ietf.org, ietf-types(a)alvestrand.no On Sun December 11 2005 10:06, Allison Mankin wrote: > Bruce, > > FYI, the other top-level media types are still there on their > FTP site, so this looks like something went wrong with their web > generating approach, whatever that is... > > ftp://ftp.iana.org/assignments/media-types/ > > Allison > > P.S. I happened to have the FTP version on my radar. Thanks for the information -- the index.html file at the ftp site has a revision date of 23-Aug-2005, whereas the file served via HTTP is dated 30-November-2005. I would have expected the same file to be served by both protocols, with index.html being the default for HTTP. That that is evidently not happening is yet another cause for concern, as it means that different access methods yield different registration information. Possibly the IANA HTTP server is sending the application data (only) instead of index.html. I've taken the liberty of copying the lists and IANA to update the information regarding the registry. Best regards, Bruce Lilly _______________________________________________ Ietf mailing list Ietf(a)ietf.org https://www1.ietf.org/mailman/listinfo/ietf ----- End forwarded message ----- -- Kent Crispin kent(a)icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent(a)songbird.com SIP: 81202(a)fwd.pulver.com

1 0

Transport Area requests Media Type review of draft-ietf-avt-ulp-14.txt
by Allison Mankin 12 Dec '05

12 Dec '05

The Transport Area requests a Media Type review for the four proposed new media types, intended for the IETF tree, which are in the document, draft-ietf-avt-ulp-14.txt, intended for Proposed Standard. The types are audio/ulpfec, video/ulpfec, text/ulpfec and application/ulpfec This document takes as its normative base RFC 3555 and the now approved and operative updated Media Types Registration document, draft-freed-media-type-reg-05.txt Please provide any comments before 5 January 2006. Thanks, Allison

1 0

draft-hoschka-smil-media-type vs +xml
by Bjoern Hoehrmann 12 Dec '05

12 Dec '05

Hi, http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-12.txt is a bit old by now, but I don't think application/smil should be COMMON as it does not use the +xml convention for XML media types. Instead, it should be OBSOLETE and application/smil+xml, defined in the same draft, should be used instead. http://www.w3.org/TR/2005/PR-SMIL2-20050927/ only has application/smil (which is not currently registered), it should use application/smil+xml and point out that application/smil is obsolete, assuming that the +xml version will be registered in the not too distant future. 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/

2 1

Re: Problem with IANA MIME media types registry
by Bruce Lilly 11 Dec '05

11 Dec '05

On Sun December 11 2005 10:06, Allison Mankin wrote: > Bruce, > > FYI, the other top-level media types are still there on their > FTP site, so this looks like something went wrong with their web > generating approach, whatever that is... > > ftp://ftp.iana.org/assignments/media-types/ > > Allison > > P.S. I happened to have the FTP version on my radar. Thanks for the information -- the index.html file at the ftp site has a revision date of 23-Aug-2005, whereas the file served via HTTP is dated 30-November-2005. I would have expected the same file to be served by both protocols, with index.html being the default for HTTP. That that is evidently not happening is yet another cause for concern, as it means that different access methods yield different registration information. Possibly the IANA HTTP server is sending the application data (only) instead of index.html. I've taken the liberty of copying the lists and IANA to update the information regarding the registry. Best regards, Bruce Lilly

1 0

Request for media type review of audio/mobile-xmf
by timo.kosonen＠nokia.com 30 Nov '05

30 Nov '05

Nokia requests Media Type review for a proposal to add media type audio/mobile-xmf, intended for the standards tree, and specified in http://www.ietf.org/internet-drafts/draft-kosonen-mobile-xmf-mediatype-00.t… Best Regards, Timo Kosonen --------------------------- Nokia Research Center phone: +358 504835206 email: timo.kosonen(a)nokia.com address: P.O. Box 100, 33721 Tampere, Finland visiting: Visiokatu 1, Tampere, Finland

1 0

Request for media type review of audio/sp-midi
by timo.kosonen＠nokia.com 30 Nov '05

30 Nov '05

Nokia requests Media Type review for a proposal to add media type audio/sp-midi, intended for the standards tree, and specified in http://www.ietf.org/internet-drafts/draft-kosonen-sp-midi-mediatype-00.txt Best Regards, Timo Kosonen --------------------------- Nokia Research Center phone: +358 504835206 email: timo.kosonen(a)nokia.com address: P.O. Box 100, 33721 Tampere, Finland visiting: Visiokatu 1, Tampere, Finland

1 0

Request for media type review of video/h263-1998 and video/h263-2000
by Magnus Westerlund 30 Nov '05

30 Nov '05

The AVT WG requests Media Type review for two proposals to update media types video/h263-1998 and video/h263-2000, intended for the standards tree, and specified in http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2429-bis-06.txt The above document is currently in WG last call. Please provide any comments to this list before 14th of December. Thanks Magnus Westerlund AVT WG Chair Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

2 3