- Ietf-types - alvestrand.no

Re: Registration of media typeimage/svg+xml
by Chris Lilley 18 Jun '10

18 Jun '10

On Friday, June 18, 2010, 5:50:56 PM, Henry wrote: HST> Fragment Identifiers Good point, fragment identifiers. HST> For documents labeled as application/svg+xml, the fragment identifier HST> notation is exactly that for application/xml, as specified in [RFC HST> 3023] or its successors. Except that isn't correct. There is also the SVG view syntax, described at http://dev.w3.org/SVG/profiles/1.1F2/publish/linking.html#LinksIntoSVG -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG

1 0

Registration of media typeimage/svg+xml
by Chris Lilley 18 Jun '10

18 Jun '10

Type name: image Subtype name: svg+xml Required parameters: None. Optional parameters: charset Same as application/xml media type, as specified in RFC3023 or it's successor. Encoding considerations: Same as for application/xml. See RFC3023, section 3.2. 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 recognized 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 P of the SVG 1.1 specification. http://dev.w3.org/SVG/profiles/1.1F2/publish/mimereg.html http://dev.w3.org/SVG/profiles/1.1F2/publish/index.html Applications that use this media type: SVG is used by Web browsers, often in conjunction with HTML; by mobile phones and digital cameras, as a format for interchange of graphical assets in desk top publishing, for industrial process visualization, display signage, and many other applications which require scalable static or interactive graphical capability. Additional information: Magic number(s): File extension(s): svg, svgz (if gzip-compressed) Macintosh file type code(s): "svg " (all lowercase, with a space character as the fourth letter), "svgz" (all lowercase, if gzip-compressed). Person & email address to contact for further information: Chris Lilley, Doug Schepers (member-svg-media-type(a)w3.org) Intended usage: COMMON Restrictions on usage: None Author: The SVG specification is a work product of the World Wide Web Consortium's SVG Working Group. Change controller: The W3C has change control over this specification. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG

3 5

re: Registration of media type image/svg+xml
by Chris Lilley 18 Jun '10

18 Jun '10

Hello Mark, I have just sent a registration request for image/svg+xml to ietf-types http://www.alvestrand.no/pipermail/ietf-types/2010-June/002360.html Looking back in the archives I see an old message from you (2005!) which I don't recall answering. http://www.alvestrand.no/pipermail/ietf-types/2005-December/000903.html Some of the points no longer apply to the new registration, some are addressed. I wanted to close the loop with you on that anyway, so that if any of the items you mentioned in 2005 are not addressed to your satisfaction in the new registration, we can get them fixed. > On 12/7/05, Chris Lilley <chris at w3.org> wrote: >> >> 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. > > Can I assume this section above was supposed to be a replacement for > the encoding section below? For the new registration, that text no longer appears. To answer your question though: no, its one of those unfortunate terminology issues where different terms are used by different communities. What XML calls the 'encoding' or 'character encoding' is what IETF calls the 'charset'. So the section was in the right place and was explaining the lack of a charset parameter. However, the new registration has the optional charset parameter so no longer needs the explanatory prose. >> Security considerations: >> 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. > > I don't see how that's a security issue. Seems more an encoding one to me. I agree it could be described either way, but there have been concerns in the past about triggering compression libraries and potential security concerns due to fixed-length zlib buffers so on balance, we decided to leave that text in there. A secondary reason to mention it was that a few implementations accept uncompressed svg, but fail with compressed svg, or only allow compressed svg when served over http and not from local disk. So it seemed worth mentioning the various ways that compressed svg might be labelled or detected. If you strongly disagree though, and no-one else speaks up in favour of this being worth mentioning in the security section, we are happy to take it out or move it to the encoding section. Should the initial byte sequence of gzipped svg be mentioned under magic numbers? It only shows that the content is gzipped, not that it is svg, so we did not add it there. > On the topic of compression though, I had heard a while ago (back in > the "image/svg-xml" days) that compressed SVG is sometimes sent as > image/svg+xml. Is that still (assuming it was ever) the case? Yes, it is the case. The same media type is used for svg regardless of whether it is compressed or not. For HTTP, other labelling is used to indicate the compression. > The > spec seems to make it clear that SVG is compressed via HTTP > compression. Yes. >> Published specification: >> This media type registration is extracted from Appendix M of >> the SVG 1.2 Tiny specification. >> http://www.w3.org/TR/SVGMobile12 > > There was no "Applications which used this media type" section. I > think it would be useful to say that there are numerous > implementations which currently support this media type. This has been added to the current registration; please check that the language is satisfactory. > Also, you might want to mention - probably in "interoperability" - > that this same media type was also prescribed for use in the SVG 1.0 > and 1.1 specs. And if there are any backward compatibility issues > between 1.2 and those, you might want to say something about that. The current registration is in the context of SVG 1.1, while the old one was for SVG Tiny 1.2 SVG 1.1 obsoletes SVG 1.0 (but SVG 1.0 did use the same media type) The same media type is used for SVG Tiny 1.1, SVG Basic 1.1, and SVG Tiny 1.2. We would be happy to note this in the registration, although the defining specification covers the relationship in much more detail. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG

1 0

Request for review of media type registration in draft-santoni-media-type-tsd-00.txt
by Adriano.Santoni 03 Jun '10

03 Jun '10

Hi all, would you please revise the media type registration in http://www.ietf.org/id/draft-santoni-media-type-tsd-00.txt Thanks Adriano Santoni

2 1

Registration of media type application/openurl-ctx+xml
by Young,Jeff (OR) 30 Apr '10

30 Apr '10

Type name: application Subtype name: openurl-ctx+xml This subtype refers XML documents that conform to "The XML ContextObject Format" <http://www.openurl.info/registry/dc/info:ofi/fmt:xml:xsd:ctx> Required parameters: none Optional parameters: charset Same as <http://tools.ietf.org/html/rfc3023#section-3.2> Encoding considerations: Same as <http://tools.ietf.org/html/rfc3023#section-3.2> Security considerations: Same as <http://tools.ietf.org/html/rfc3023#section-3.2> Interoperability considerations: Same as <http://tools.ietf.org/html/rfc3023#section-3.2> Published specification: See <http://www.openurl.info/registry/dc/info:ofi/fmt:xml:xsd:ctx> Applications that use this media type: OpenURL 1.0 <http://alcme.oclc.org/openurl/docs/pdf/z39_88_2004.pdf> Additional information: Magic number(s): None File extension(s): .ctx Macintosh file type code(s): None Person & email address to contact for further information: Phil Norman <norman(a)oclc.org> Intended usage: COMMON Restrictions on usage: None Author: Jeffrey A. Young <jyoung(a)oclc.org> Change controller: OpenURL Maintenance Agency <openurlagency(a)oclc.org>

1 0

IANA Registration Template from draft-ietf-marf-base
by Murray S. Kucherawy 28 Apr '10

28 Apr '10

Hi IANA, Below is a MIME type registration from the above document which is making its way toward the IESG. Please let me know if it contains any areas of concern. 6.1. MIME Type Registration of 'message/feedback-report' This section provides the media type registration application from [MIME-REG<http://tools.ietf.org/html/draft-ietf-marf-base-03#ref-MIME-REG>] for processing by IANA: To: ietf-types(a)iana.org Subject: Registration of media type message/feedback-report Type name: message Subtype name: feedback-report Required parameters: none Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers. Security considerations: See Section 7<http://tools.ietf.org/html/draft-ietf-marf-base-03#section-7> of [this document]. Interoperability considerations: Implementors MUST ignore any fields they do not support. Published specification: [this document] Applications that use this media type: Abuse helpdesk software for ISPs, mail service bureaus, mail certifiers, and similar organizations Additional information: none Person and email address to contact for further information: Yakov Shafranovich <ietf(a)shaftek.org> Murray S. Kucherawy <msk(a)cloudmark.com> Intended usage: COMMON Author: Yakov Shafranovich John Levine Murray S. Kucherawy Change controller: IESG

1 0

Re: plan for getting media type registrations updated w.r.t. media fragments?
by Mark Nottingham 28 Apr '10

28 Apr '10

Well, ietf-types is important from a functional standpoint, but I don't know that it should be used to discuss the document itself. That sort of coordination should happen on apps-discuss and the URI list, I think. Regards, On 23/04/2010, at 12:19 AM, Dan Connolly wrote: > +cc ietf-types(a)alvestrand.no ; > thread begins at > http://lists.w3.org/Archives/Public/public-media-fragment/2010Apr/0039.html > > On Wed, 2010-04-21 at 09:32 +1000, Silvia Pfeiffer wrote: >> On Wed, Apr 21, 2010 at 2:56 AM, Dan Connolly <connolly(a)w3.org> wrote: >>> http://www.w3.org/TR/2010/WD-media-frags-20100413/#standardisation-terminol… > [...] >>> "The Media Fragment WG has no authority to update registries of all >>> targeted media types. ... We recommend media type owners to harmonize >>> their existing schemes with the ones proposed in this document and >>> update or add the fragment semantics specification to their media type >>> registration." >>> >>> Is there a plan to get that recommendation implemented? >> >> I can offer to do an update of the Ogg RFC >> http://www.ietf.org/rfc/rfc5334.txt with these fragment >> specifications. >> >> Though, to be honest, it will be easier to just get implementations >> and then, if they catch on, update the RFC. > > Well, that's a plan of sorts... but it's important to coordinate > that with the IETF. It's not polite for W3C to unilaterally > encourage implementations to deploy certain designs that will > constrain updates to IETF RFCs. > > I wonder who to coordinate with from the IETF side... > The http://www.alvestrand.no/mailman/listinfo/ietf-types > page says it's owned/run by Harald Alvestrand and Mark Baker (distobj). > Does this play make sense to you? > > Otherwise, Mark N., would you suggest anybody in particular > to coordinate with? > >> The reason that we can do implementations without much issues is that >> virtually no other implementations of fragment schemes on media >> resources exist. Even where schemes were developed such as at YouTube, >> these schemes were not done on the media resource, but on the Web page >> URLs. Also see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#Existing… >> for a more indepth analysis of the state of affairs. The exisiting >> MPEG scheme has not been implemented anywhere FAIK and would not clash >> since it always starts with mp(). >> >> Cheers, >> Silvia. >> > > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E > > -- Mark Nottingham http://www.mnot.net/

2 1

Re: plan for getting media type registrations updated w.r.t. media fragments?
by Silvia Pfeiffer 23 Apr '10

23 Apr '10

Hi Dan, Does the IETF have a mechanism to request mime type owners to update their specs to integrate something like a fragment specification for URIs? If so, that would be helpful. Regards, Silvia. On Fri, Apr 23, 2010 at 12:19 AM, Dan Connolly <connolly(a)w3.org> wrote: > +cc ietf-types(a)alvestrand.no ; > thread begins at > http://lists.w3.org/Archives/Public/public-media-fragment/2010Apr/0039.html > > On Wed, 2010-04-21 at 09:32 +1000, Silvia Pfeiffer wrote: >> On Wed, Apr 21, 2010 at 2:56 AM, Dan Connolly <connolly(a)w3.org> wrote: >> > http://www.w3.org/TR/2010/WD-media-frags-20100413/#standardisation-terminol… > [...] >> > "The Media Fragment WG has no authority to update registries of all >> > targeted media types. ... We recommend media type owners to harmonize >> > their existing schemes with the ones proposed in this document and >> > update or add the fragment semantics specification to their media type >> > registration." >> > >> > Is there a plan to get that recommendation implemented? >> >> I can offer to do an update of the Ogg RFC >> http://www.ietf.org/rfc/rfc5334.txt with these fragment >> specifications. >> >> Though, to be honest, it will be easier to just get implementations >> and then, if they catch on, update the RFC. > > Well, that's a plan of sorts... but it's important to coordinate > that with the IETF. It's not polite for W3C to unilaterally > encourage implementations to deploy certain designs that will > constrain updates to IETF RFCs. > > I wonder who to coordinate with from the IETF side... > The http://www.alvestrand.no/mailman/listinfo/ietf-types > page says it's owned/run by Harald Alvestrand and Mark Baker (distobj). > Does this play make sense to you? > > Otherwise, Mark N., would you suggest anybody in particular > to coordinate with? > >> The reason that we can do implementations without much issues is that >> virtually no other implementations of fragment schemes on media >> resources exist. Even where schemes were developed such as at YouTube, >> these schemes were not done on the media resource, but on the Web page >> URLs. Also see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#Existing… >> for a more indepth analysis of the state of affairs. The exisiting >> MPEG scheme has not been implemented anywhere FAIK and would not clash >> since it always starts with mp(). >> >> Cheers, >> Silvia. >> > > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E > >

1 0

Re: Registration of media type application/its+xml
by Felix Sasaki 22 Apr '10

22 Apr '10

2010/4/21 Bjoern Hoehrmann <derhoermi(a)gmx.net> > * Felix Sasaki wrote: > >MIME media type name: > > application > > The registration is based on an obsoleted template. Could you resubmit > it using the RFC 4288 template? (In particular, the field names have > changed, and some fields have been split into multiple fields). > Yes, will do. > > >Applications which use this media type: > > This new media type is being registered to allow for deployment of ITS > >1.0 on the World Wide Web. > > This should give an idea what kinds of applications use the media type > (revision control software, word processing software, ...) > Propose to add: "ITS 1.0 information can be used e.g. by localization tools to extract localizable units (e.g. text strings) as an input to the localization process." > > >Additional information: > > File extension: > > its > > Fragment identifiers: > > A syntax identical to that of "application/xml" as described in > IETF > >RFC 3023. > > RFC 3023 does not define fragment identifier syntax for application/xml. > OK - I propose to leave the "Fragment identifiers" part out. > > > Base URI: > > As specified in IETF RFC 3023, section 6. > > RFC 3023 does not actually say something relevant here, for example, it > is unclear whether xml:base is considered for application/its+xml. > OK. > I do note that it is not actually clear to me what documents would be > labeled with this type, for instance, what would be the root element of > such documents? > Any XML document containing ITS 1.0 "its:rules" elements can be labelled with application/its+xml. At http://www.w3.org/TR/its/EX-link-external-rules-2.xml you see an example of a document linking to a file with ITS 1.0 "rules". The link target is at http://www.w3.org/TR/its/EX-link-external-rules-1.xml as you can see the link target does not have "its:rules" as a root element. The processing semantics here is that linked rules are gathered in document order. Felix -- > Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de > Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ >

2 3

Re: Potential media type registration: application/metalink4+xml for Metalink Download Description Format
by Anthony Bryan 22 Apr '10

22 Apr '10

On Thu, Apr 22, 2010 at 5:06 AM, Bjoern Hoehrmann <derhoermi(a)gmx.net> wrote: > * Anthony Bryan wrote: >>6.2. application/metalink4+xml MIME type > >> Additional information: >> >> Magic number(s): As specified for "application/xml" in [RFC3023], >> Section 3.2. > > This isn't quite accurate, as that would not identify metalink documents > (but rather all XML documents). I think "None" would be better, some XML > types also discuss presence of root elements or namespaces, but that's > not really helpful here, in my opinion. Changed to "None" >> File extension: .meta4 >> >> Macintosh File Type code: TEXT >> >> Person and email address to contact for further information: >> Anthony Bryan <anthonybryan(a)gmail.com> >> >> Intended usage: COMMON >> >> Restrictions on usage: None. >> >> Author/Change controller: IESG > > This should be two fields, with you as the author and the IESG as change > controller. Author: Anthony Bryan <anthonybryan(a)gmail.com> > Other than that this looks good. > > (You didn't copy the ietf-types list, so I'll send a mail there pointing > out that we've resolved this offlist, assuming you'll be making these > changes during auth48.) I copied the ietf-types list now. Here it is for one last review. Thanks for taking the time to catch these last minute! 6.2. application/metalink4+xml MIME type A Metalink Document, when serialized as XML 1.0, can be identified with the following media type: Type name: application Subtype name: metalink4+xml Required parameters: None. Optional parameters: "charset": This parameter has semantics identical to the charset parameter of the "application/xml" media type as specified in [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], Section 3.2. Security considerations: As defined in this specification. In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], Section 10. Interoperability considerations: There are no known interoperability issues. Published specification: This specification. Applications that use this media type: File transfer applications. Additional information: Magic number(s): None. File extension: .meta4 Macintosh File Type code: TEXT Person and email address to contact for further information: Anthony Bryan <anthonybryan(a)gmail.com> Intended usage: COMMON Restrictions on usage: None. Author: Anthony Bryan <anthonybryan(a)gmail.com> Change controller: IESG -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads

2 1