Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
From: Alexey Melnikov <[email-masked]>
To: Chris Lilley <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Tue, 30 Nov 2010 18:21:51 +0000
List-Id: <ietf-xml-mime.imc.org>

Chris Lilley wrote:

>On Tuesday, November 30, 2010, 9:19:33 AM, Julian wrote:
>
>JR> OK, is there anything left to do? Or is this already on the way to IANA?
>
>Re-reading Martin's latest comments, in a calmer frame of mind, there is merit to his proposed wording. I'm going to check it a little and then send in a (final? please?) last revision, likely tomorrow.
>  
>
Ok. Please also ask IESG to approve the registration through W3C 
liaison. I would like to get this done during the December 16th IESG 
telechat.

Thanks,
Alexey

Date: Tue, 30 Nov 2010 18:14:17 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Julian Reschke <[email-masked]>
CC: Ned Freed <[email-masked]>, "=?iso-8859-1?Q?=22Martin_J._D=FCrst=22?=" <[email-masked]>, <[email-masked]>, <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

On Tuesday, November 30, 2010, 9:19:33 AM, Julian wrote:

JR> OK, is there anything left to do? Or is this already on the way to IANA?

Re-reading Martin's latest comments, in a calmer frame of mind, there is merit to his proposed wording. I'm going to check it a little and then send in a (final? please?) last revision, likely tomorrow.

JR> Let's get this finished...

JR> On 25.11.2010 21:01, Ned Freed wrote:
>> Looks good to me as well.

>> Ned

>>> This looks good to me. I hope this can move forward to the next step
>>> (IESG approval?) soon, so that image/svg+xml can finally be properly
>>> registered.

>>> Regards, Martin.

>>> On 2010/11/25 7:36, Chris Lilley wrote:
>>> >
>>> > This is an updated registration request, incorporating the latest
>>> > round of feedback.
>>> >
>>> >
>>> > Type name:
>>> >
>>> > image
>>> >
>>> > Subtype name:
>>> >
>>> > svg+xml
>>> >
>>> > Required parameters:
>>> >
>>> > None.
>>> >
>>> > Optional parameters:
>>> >
>>> > charset
>>> >
>>> > Same as application/xml media type, as specified in [RFC3023] or
>>> > its successors.
>>> >
>>> > Encoding considerations:
>>> >
>>> > Same as for application/xml. See [RFC3023], section 3.2 or its
>>> > successors.
>>> >
>>> > 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.
>>> >
>>> > 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 the published 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:
>>> >
>>> > The published 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://www.w3.org/TR/SVG/mimereg.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
>>> >
>>> > Note that the extension 'svgz' is used as an alias for
>>> > 'svg.gz' [RFC1952], i.e. octet streams of type image/svg+xml,
>>> > subsequently compressed with gzip.
>>> >
>>> > Macintosh file type code(s):
>>> >
>>> > "svg " (all lowercase, with a space character as the fourth letter).
>>> >
>>> > Note that the Macintosh file type code 'svgz' (all lowercase)
>>> > is used as an alias for GZIP [RFC1952] compressed "svg ", i.e.
>>> > octet streams of type image/svg+xml, subsequently compressed
>>> > with gzip.
>>> >
>>> > Macintosh Universal Type Identifier code:
>>> >
>>> > org.w3c.svg conforms to public.image and to public.xml
>>> >
>>> > Windows Clipboard Name:
>>> >
>>> > "SVG Image"
>>> >
>>> > Fragment Identifiers
>>> >
>>> > For documents labeled as application/svg+xml, the fragment
>>> > identifier notation is that for application/xml, as specified
>>> > in RFC 3023 or its successors, plus the SVG-specific SVG Views
>>> > syntax described in the SVG specification.
>>> >
>>> > Person& email address to contact for further information:
>>> >
>>> > Chris Lilley, Doug Schepers ([email-masked]).
>>> >
>>> > 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.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >

>>> --
>>> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
>>> #-# http://www.sw.it.aoyama.ac.jp mailto:[email-masked]

>> _______________________________________________
>> ietf-types mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-types

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Date: Tue, 30 Nov 2010 09:19:33 +0100
From: Julian Reschke <[email-masked]>
To: Ned Freed <[email-masked]>
CC: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

OK, is there anything left to do? Or is this already on the way to IANA?

Let's get this finished...

On 25.11.2010 21:01, Ned Freed wrote:
> Looks good to me as well.
>
> Ned
>
>> This looks good to me. I hope this can move forward to the next step
>> (IESG approval?) soon, so that image/svg+xml can finally be properly
>> registered.
>
>> Regards, Martin.
>
>> On 2010/11/25 7:36, Chris Lilley wrote:
>> >
>> > This is an updated registration request, incorporating the latest
>> > round of feedback.
>> >
>> >
>> > Type name:
>> >
>> > image
>> >
>> > Subtype name:
>> >
>> > svg+xml
>> >
>> > Required parameters:
>> >
>> > None.
>> >
>> > Optional parameters:
>> >
>> > charset
>> >
>> > Same as application/xml media type, as specified in [RFC3023] or
>> > its successors.
>> >
>> > Encoding considerations:
>> >
>> > Same as for application/xml. See [RFC3023], section 3.2 or its
>> > successors.
>> >
>> > 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.
>> >
>> > 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 the published 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:
>> >
>> > The published 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://www.w3.org/TR/SVG/mimereg.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
>> >
>> > Note that the extension 'svgz' is used as an alias for
>> > 'svg.gz' [RFC1952], i.e. octet streams of type image/svg+xml,
>> > subsequently compressed with gzip.
>> >
>> > Macintosh file type code(s):
>> >
>> > "svg " (all lowercase, with a space character as the fourth letter).
>> >
>> > Note that the Macintosh file type code 'svgz' (all lowercase)
>> > is used as an alias for GZIP [RFC1952] compressed "svg ", i.e.
>> > octet streams of type image/svg+xml, subsequently compressed
>> > with gzip.
>> >
>> > Macintosh Universal Type Identifier code:
>> >
>> > org.w3c.svg conforms to public.image and to public.xml
>> >
>> > Windows Clipboard Name:
>> >
>> > "SVG Image"
>> >
>> > Fragment Identifiers
>> >
>> > For documents labeled as application/svg+xml, the fragment
>> > identifier notation is that for application/xml, as specified
>> > in RFC 3023 or its successors, plus the SVG-specific SVG Views
>> > syntax described in the SVG specification.
>> >
>> > Person& email address to contact for further information:
>> >
>> > Chris Lilley, Doug Schepers ([email-masked]).
>> >
>> > 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.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>
>> --
>> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
>> #-# http://www.sw.it.aoyama.ac.jp mailto:[email-masked]
>
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types
>

Date: Fri, 26 Nov 2010 12:14:58 +0100
From: Julian Reschke <[email-masked]>
To: Ned Freed <[email-masked]>
CC: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

On 25.11.2010 21:25, Ned Freed wrote:
> ...
> So if we cannot nail this down I'm OK with moving forward with something
> that's understood to be less than perfect. Remember, registrations can
> always be revised.
> ...

Absolutely.

Best regards, Julian

From: [email-masked]
Cc: Chris Lilley <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Date: Thu, 25 Nov 2010 12:25:07 -0800 (PST)
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Sender: [email-masked]

First of all, I prefer Martin's text, modulo correcting any technical
errors it may contain.

THat said, the more important point is we cannot have registrations wait on
some future clarification to the confusion surrounding fragment identifiers and
how they should be handled in media type registrations. I cannot, for example,
wait on 3023bis before approving the registrations in other trees that arrive
at a rate of several every week. We've tried that tack before and we know what
happens - people simply stop registrating things and it takes years for
the process to recover.

So if we cannot nail this down I'm OK with moving forward with something
that's understood to be less than perfect. Remember, registrations can
always be revised.

				Ned

> Hello Chris,

> On 2010/11/25 15:53, Chris Lilley wrote:
> > On Thursday, November 25, 2010, 7:30:41 AM, Martin wrote:
> >
> > MJD>  Sorry to pull back yet another time.
> >
> > Oh, after a decade of not getting registered, I'm getting used to someone bringing up a last minute problem as soon as it looks like we can go ahead.

> Really sorry about that.

> > MJD>   I just found a comment by Björn
> > MJD>  Höhrmann in another thread saying that RFC 3032 doesn't define fragment
> > MJD>  identifiers.
> >
> > I know. But the TAG wants its successor to talk about them (and it does).

> I know. I recently had the chance to attended the respective session
> where the TAG discussed this issue.

> > You seem to have missed the *** part below:

> No, I didn't.

> > Fragment Identifiers
> >
> >          For documents labeled as application/svg+xml, the fragment
> >          identifier notation is that for application/xml, as specified
> >          in RFC 3023 *** or its successors ***

> That would be fine (with me, in any case) if RFC 3023 said something
> definite about this issue. But it just mentions an "attempt".

> > MJD>  Upon checking, I found the following:
> >
> > MJD>  http://tools.ietf.org/html/rfc3023#section-5
> >
> > MJD>      As of today, no established specifications define identifiers for XML
> > MJD>      media types.  However, a working draft published by W3C, namely "XML
> > MJD>      Pointer Language (XPointer)", attempts to define fragment identifiers
> > MJD>      for text/xml and application/xml.  The current specification for
> > MJD>      XPointer is available at http://www.w3.org/TR/xptr.
> >
> > But that language is no use either,

> I agree. I just put it in there so that everybody can see what it says.

> > because as you point out
> >
> > MJD>  On top of that, http://www.w3.org/TR/xptr/ says it's superseeded.
> >
> > Which I also know, because RFC 3023bis has better language and was written after XPointer was superceeded.

> That will be great, once RFC 3023bis will actually be an RFC.

> > MJD>  In
> > MJD>  this light, the following text from the registration may need
> > MJD>  reconsideration:
> >
> > No, it really doesn't, because it already has some future proofing built in because of "or its successors"

> I don't mind "future proofing" if the present is also well defined. But
> I don't think it's very appropriate to use "future proofing" if the
> present isn't well defined.

> > plus the fact that I have a fair idea what its successor will say.

> I know you are one of the authors, and I trust you to do a good job on
> this, but I also know that things often change.

> >   >>>  Fragment Identifiers
> >
> >   >>>  For documents labeled as application/svg+xml, the fragment
> >   >>>  identifier notation is that for application/xml, as specified
> >   >>>  in RFC 3023 or its successors, plus the SVG-specific SVG Views
> >   >>>  syntax described in the SVG specification.
> >
> > MJD>  What about:
> >
> >
> > MJD>  Fragment Identifiers
> >
> > MJD>  For documents labeled as application/svg+xml, the fragment
> > MJD>  identifier notation follows the XML Pointer Language (XPointer)
> > MJD>  Framework (see http://www.w3.org/TR/xptr-framework/). Fragment
> > MJD>  identifiers are either Shorthand Pointers (formerly called barenames) or
> > MJD>  SVG view specifications.
> >
> > No, because that misses out the XPonter registry for example.

> I was under the impression that the only fragment syntaxes usable in SVG
> would be 'barenames' and the view syntax. So I thought that the XPointer
> registry was essentially irrelevant. If that's wrong, feel free to tweak
> the above text.

> However, if we actually had different ideas of what would be allowed as
> SVG fragment identifiers, then this might show that pointing to a text
> like "attempts to define fragment identifiers" isn't clear enough.

> > MJD>  For details, please see Section 17.3.2 of the
> > MJD>  SVG specification
> > MJD>  (http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers).
> >
> >
> > MJD>  or some such. I hope that RFC 3023bis can be completed soon,
> >
> > Martin, how can I put this politely.
> >
> > No. NO!
> >
> > No, we are not waiting for 3023bis to be done before registering image/svg+xml.

> Sorry, but if you had read the whole sentence I wrote (see below for the
> rest) before writing this, you would have understood that you don't have
> to disagree with me, because I already agree with you: Let's register
> image/svg+xml without waiting for RFC 3023bis to be completed.

> > For one thing, 3023bis was sort of ready when there was an objection to its deprecation of text/xml. I'm working on a way around that, but it depends in turn on resolution of a longstanding issue on HTTPbis.
> >
> > For another thing, TAG is currently noodling some more on fragments and may want some 3023bis changes to special case RDF fragment identifiers.

> [My understanding is that they already made their mind up on this, and
> set the authors (including you) an email about this, but that there may
> be an issue left with fragment identifiers and RDF*a*.]

> > So, I am much more comfortable with the current wording than with your proposed change.

> The current wording points to an "attemt" and some future spec that we
> don't know when it will be done. I'm not sure what makes you comfortable
> about that.

> My wording was an attempt to remove these dependencies to make it clear
> what can actually be used as a fragment identifier. If I got something
> wrong, I don't have any problem with my proposal being fixed.

> > MJD>  and make
> > MJD>  this easier, but I hope we don't need to wait for this to complete the
> > MJD>  image/svg+xml registration.
> >
> > Exactly. So - no.
> >
> > MJD>  This also brings me to another nit. The registration currently says:
> >
> >   >>>  Published specification:
> >
> >   >>>  This media type registration is extracted from Appendix P of the
> >   >>>  SVG 1.1 specification.
> >   >>>  http://www.w3.org/TR/SVG/mimereg.html
> >
> > MJD>  First, we made some tweaks,
> >
> > Martin, I have made the tweaks *to the editors draft* and it will show up under /TR next time it gets published, okay?

> Ah, okay, then that's fine with me.

> > In fact, to be sure, I made the tweaks to the editors draft and *then* after that converted the HTML to plain text, to create the email plain text version, to be sure they were identical.
> >
> > MJD>  and second, the published specification is
> > MJD>  all of SVG 1.1, not just the mimereg part,
> >
> > Obviously
> >
> > MJD>  as far as I understand. So
> > MJD>  what about something like:
> >
> >
> > MJD>  Published specification:
> >
> > MJD>  This media type registration is an extracted and slightly adapted
> > MJD>  version of Appendix P of the SVG 1.1 specification
> > MJD>  (http://www.w3.org/TR/SVG11/).
> >
> > No to the 'slightly adapted' for reasons given above,

> Just to confirm, fine with me.

> > and no to the changing the link from appendix P to the entire spec because that is what the text says.

> It is not clear whether the parenthesis is a clarification to "Appendix
> P of the SVG 1.1 specification" or "the SVG 1.1 specification". I was
> expecting the later, also because that would be in line with the title
> of the section (Publish Specification must be SVG 1.1, not only appendix P).

> Regards,   Martin.

> > The registration is appendix P and the spec is the spec, and no-one is going to mix them up surely.
> >
> > It says that there is the SVG 1.1 specification, and it says the media type registration is extracted from appendix P of it.
> >
> > Alexey, Keith, I request that we move ahead with the text that I submited earlier, on Wednesday, 24 November 2010, 23:36:35  (Wed, 24 Nov 2010 23:36:35 +0100)
> >

> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

From: [email-masked]
Cc: Chris Lilley <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>, Philippe Le Hegaret <[email-masked]>
Date: Thu, 25 Nov 2010 12:01:13 -0800 (PST)
Subject: Re: Registration of media typeimage/svg+xml
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Sender: [email-masked]

Looks good to me as well.

				Ned

> This looks good to me. I hope this can move forward to the next step
> (IESG approval?) soon, so that image/svg+xml can finally be properly
> registered.

> Regards,   Martin.

> On 2010/11/25 7:36, Chris Lilley wrote:
> >
> > This is an updated registration request, incorporating the latest
> > round of feedback.
> >
> >
> > Type name:
> >
> >      image
> >
> > Subtype name:
> >
> >      svg+xml
> >
> > Required parameters:
> >
> >      None.
> >
> > Optional parameters:
> >
> >      charset
> >
> >      Same as application/xml media type, as specified in [RFC3023] or
> >      its successors.
> >
> > Encoding considerations:
> >
> >      Same as for application/xml. See [RFC3023], section 3.2 or its
> >      successors.
> >
> > 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.
> >
> >      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 the published 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:
> >
> >      The published 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://www.w3.org/TR/SVG/mimereg.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
> >
> >          Note that the extension 'svgz' is used as an alias for
> >          'svg.gz' [RFC1952], i.e. octet streams of type image/svg+xml,
> >          subsequently compressed with gzip.
> >
> >      Macintosh file type code(s):
> >
> >          "svg " (all lowercase, with a space character as the fourth letter).
> >
> >          Note that the Macintosh file type code 'svgz' (all lowercase)
> >          is used as an alias for GZIP [RFC1952] compressed "svg ", i.e.
> >          octet streams of type image/svg+xml, subsequently compressed
> >          with gzip.
> >
> >      Macintosh Universal Type Identifier code:
> >
> >          org.w3c.svg conforms to public.image and to public.xml
> >
> >      Windows Clipboard Name:
> >
> >          "SVG Image"
> >
> >      Fragment Identifiers
> >
> >          For documents labeled as application/svg+xml, the fragment
> >          identifier notation is that for application/xml, as specified
> >          in RFC 3023 or its successors, plus the SVG-specific SVG Views
> >          syntax described in the SVG specification.
> >
> > Person&  email address to contact for further information:
> >
> >      Chris Lilley, Doug Schepers ([email-masked]).
> >
> > 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.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >

> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

Date: Thu, 25 Nov 2010 18:24:26 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Chris Lilley <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

Hello Chris,

On 2010/11/25 15:53, Chris Lilley wrote:
> On Thursday, November 25, 2010, 7:30:41 AM, Martin wrote:
>
> MJD>  Sorry to pull back yet another time.
>
> Oh, after a decade of not getting registered, I'm getting used to someone bringing up a last minute problem as soon as it looks like we can go ahead.

Really sorry about that.

> MJD>   I just found a comment by Björn
> MJD>  Höhrmann in another thread saying that RFC 3032 doesn't define fragment
> MJD>  identifiers.
>
> I know. But the TAG wants its successor to talk about them (and it does).

I know. I recently had the chance to attended the respective session 
where the TAG discussed this issue.

> You seem to have missed the *** part below:

No, I didn't.

> Fragment Identifiers
>
>          For documents labeled as application/svg+xml, the fragment
>          identifier notation is that for application/xml, as specified
>          in RFC 3023 *** or its successors ***

That would be fine (with me, in any case) if RFC 3023 said something 
definite about this issue. But it just mentions an "attempt".

> MJD>  Upon checking, I found the following:
>
> MJD>  http://tools.ietf.org/html/rfc3023#section-5
>
> MJD>      As of today, no established specifications define identifiers for XML
> MJD>      media types.  However, a working draft published by W3C, namely "XML
> MJD>      Pointer Language (XPointer)", attempts to define fragment identifiers
> MJD>      for text/xml and application/xml.  The current specification for
> MJD>      XPointer is available at http://www.w3.org/TR/xptr.
>
> But that language is no use either,

I agree. I just put it in there so that everybody can see what it says.

> because as you point out
>
> MJD>  On top of that, http://www.w3.org/TR/xptr/ says it's superseeded.
>
> Which I also know, because RFC 3023bis has better language and was written after XPointer was superceeded.

That will be great, once RFC 3023bis will actually be an RFC.

> MJD>  In
> MJD>  this light, the following text from the registration may need
> MJD>  reconsideration:
>
> No, it really doesn't, because it already has some future proofing built in because of "or its successors"

I don't mind "future proofing" if the present is also well defined. But 
I don't think it's very appropriate to use "future proofing" if the 
present isn't well defined.

> plus the fact that I have a fair idea what its successor will say.

I know you are one of the authors, and I trust you to do a good job on 
this, but I also know that things often change.

>   >>>  Fragment Identifiers
>
>   >>>  For documents labeled as application/svg+xml, the fragment
>   >>>  identifier notation is that for application/xml, as specified
>   >>>  in RFC 3023 or its successors, plus the SVG-specific SVG Views
>   >>>  syntax described in the SVG specification.
>
> MJD>  What about:
>
>
> MJD>  Fragment Identifiers
>
> MJD>  For documents labeled as application/svg+xml, the fragment
> MJD>  identifier notation follows the XML Pointer Language (XPointer)
> MJD>  Framework (see http://www.w3.org/TR/xptr-framework/). Fragment
> MJD>  identifiers are either Shorthand Pointers (formerly called barenames) or
> MJD>  SVG view specifications.
>
> No, because that misses out the XPonter registry for example.

I was under the impression that the only fragment syntaxes usable in SVG 
would be 'barenames' and the view syntax. So I thought that the XPointer 
registry was essentially irrelevant. If that's wrong, feel free to tweak 
the above text.

However, if we actually had different ideas of what would be allowed as 
SVG fragment identifiers, then this might show that pointing to a text 
like "attempts to define fragment identifiers" isn't clear enough.

> MJD>  For details, please see Section 17.3.2 of the
> MJD>  SVG specification
> MJD>  (http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers).
>
>
> MJD>  or some such. I hope that RFC 3023bis can be completed soon,
>
> Martin, how can I put this politely.
>
> No. NO!
>
> No, we are not waiting for 3023bis to be done before registering image/svg+xml.

Sorry, but if you had read the whole sentence I wrote (see below for the 
rest) before writing this, you would have understood that you don't have 
to disagree with me, because I already agree with you: Let's register 
image/svg+xml without waiting for RFC 3023bis to be completed.

> For one thing, 3023bis was sort of ready when there was an objection to its deprecation of text/xml. I'm working on a way around that, but it depends in turn on resolution of a longstanding issue on HTTPbis.
>
> For another thing, TAG is currently noodling some more on fragments and may want some 3023bis changes to special case RDF fragment identifiers.

[My understanding is that they already made their mind up on this, and 
set the authors (including you) an email about this, but that there may 
be an issue left with fragment identifiers and RDF*a*.]

> So, I am much more comfortable with the current wording than with your proposed change.

The current wording points to an "attemt" and some future spec that we 
don't know when it will be done. I'm not sure what makes you comfortable 
about that.

My wording was an attempt to remove these dependencies to make it clear 
what can actually be used as a fragment identifier. If I got something 
wrong, I don't have any problem with my proposal being fixed.

> MJD>  and make
> MJD>  this easier, but I hope we don't need to wait for this to complete the
> MJD>  image/svg+xml registration.
>
> Exactly. So - no.
>
> MJD>  This also brings me to another nit. The registration currently says:
>
>   >>>  Published specification:
>
>   >>>  This media type registration is extracted from Appendix P of the
>   >>>  SVG 1.1 specification.
>   >>>  http://www.w3.org/TR/SVG/mimereg.html
>
> MJD>  First, we made some tweaks,
>
> Martin, I have made the tweaks *to the editors draft* and it will show up under /TR next time it gets published, okay?

Ah, okay, then that's fine with me.

> In fact, to be sure, I made the tweaks to the editors draft and *then* after that converted the HTML to plain text, to create the email plain text version, to be sure they were identical.
>
> MJD>  and second, the published specification is
> MJD>  all of SVG 1.1, not just the mimereg part,
>
> Obviously
>
> MJD>  as far as I understand. So
> MJD>  what about something like:
>
>
> MJD>  Published specification:
>
> MJD>  This media type registration is an extracted and slightly adapted
> MJD>  version of Appendix P of the SVG 1.1 specification
> MJD>  (http://www.w3.org/TR/SVG11/).
>
> No to the 'slightly adapted' for reasons given above,

Just to confirm, fine with me.

> and no to the changing the link from appendix P to the entire spec because that is what the text says.

It is not clear whether the parenthesis is a clarification to "Appendix 
P of the SVG 1.1 specification" or "the SVG 1.1 specification". I was 
expecting the later, also because that would be in line with the title 
of the section (Publish Specification must be SVG 1.1, not only appendix P).

Regards,   Martin.

> The registration is appendix P and the spec is the spec, and no-one is going to mix them up surely.
>
> It says that there is the SVG 1.1 specification, and it says the media type registration is extracted from appendix P of it.
>
> Alexey, Keith, I request that we move ahead with the text that I submited earlier, on Wednesday, 24 November 2010, 23:36:35  (Wed, 24 Nov 2010 23:36:35 +0100)
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

Date: Thu, 25 Nov 2010 07:53:32 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: "=?iso-8859-1?Q?=22Martin_J._D=FCrst=22?=" <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked], <[email-masked]>
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

On Thursday, November 25, 2010, 7:30:41 AM, Martin wrote:

MJD> Sorry to pull back yet another time.

Oh, after a decade of not getting registered, I'm getting used to someone bringing up a last minute problem as soon as it looks like we can go ahead.

MJD>  I just found a comment by Björn 
MJD> Höhrmann in another thread saying that RFC 3032 doesn't define fragment
MJD> identifiers. 

I know. But the TAG wants its successor to talk about them (and it does). You seem to have missed the *** part below:

Fragment Identifiers

        For documents labeled as application/svg+xml, the fragment
        identifier notation is that for application/xml, as specified
        in RFC 3023 *** or its successors ***

MJD> Upon checking, I found the following:

MJD> http://tools.ietf.org/html/rfc3023#section-5

MJD>     As of today, no established specifications define identifiers for XML
MJD>     media types.  However, a working draft published by W3C, namely "XML
MJD>     Pointer Language (XPointer)", attempts to define fragment identifiers
MJD>     for text/xml and application/xml.  The current specification for
MJD>     XPointer is available at http://www.w3.org/TR/xptr.

But that language is no use either, because as you point out

MJD> On top of that, http://www.w3.org/TR/xptr/ says it's superseeded. 

Which I also know, because RFC 3023bis has better language and was written after XPointer was superceeded.

MJD> In 
MJD> this light, the following text from the registration may need 
MJD> reconsideration:

No, it really doesn't, because it already has some future proofing built in because of "or its successors" plus the fact that I have a fair idea what its successor will say.

 >>> Fragment Identifiers

 >>> For documents labeled as application/svg+xml, the fragment
 >>> identifier notation is that for application/xml, as specified
 >>> in RFC 3023 or its successors, plus the SVG-specific SVG Views
 >>> syntax described in the SVG specification.

MJD> What about:

MJD> Fragment Identifiers

MJD> For documents labeled as application/svg+xml, the fragment
MJD> identifier notation follows the XML Pointer Language (XPointer) 
MJD> Framework (see http://www.w3.org/TR/xptr-framework/). Fragment 
MJD> identifiers are either Shorthand Pointers (formerly called barenames) or
MJD> SVG view specifications. 

No, because that misses out the XPonter registry for example.

MJD> For details, please see Section 17.3.2 of the
MJD> SVG specification 
MJD> (http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers).

MJD> or some such. I hope that RFC 3023bis can be completed soon, 

Martin, how can I put this politely.

No. NO!

No, we are not waiting for 3023bis to be done before registering image/svg+xml.

For one thing, 3023bis was sort of ready when there was an objection to its deprecation of text/xml. I'm working on a way around that, but it depends in turn on resolution of a longstanding issue on HTTPbis.

For another thing, TAG is currently noodling some more on fragments and may want some 3023bis changes to special case RDF fragment identifiers.

So, I am much more comfortable with the current wording than with your proposed change.

MJD> and make 
MJD> this easier, but I hope we don't need to wait for this to complete the
MJD> image/svg+xml registration.

Exactly. So - no.

MJD> This also brings me to another nit. The registration currently says:

 >>> Published specification:

 >>> This media type registration is extracted from Appendix P of the
 >>> SVG 1.1 specification.
 >>> http://www.w3.org/TR/SVG/mimereg.html

MJD> First, we made some tweaks, 

Martin, I have made the tweaks *to the editors draft* and it will show up under /TR next time it gets published, okay?

In fact, to be sure, I made the tweaks to the editors draft and *then* after that converted the HTML to plain text, to create the email plain text version, to be sure they were identical.

MJD> and second, the published specification is
MJD> all of SVG 1.1, not just the mimereg part, 

Obviously
 
MJD> as far as I understand. So 
MJD> what about something like:

MJD> Published specification:

MJD> This media type registration is an extracted and slightly adapted 
MJD> version of Appendix P of the SVG 1.1 specification
MJD> (http://www.w3.org/TR/SVG11/).

No to the 'slightly adapted' for reasons given above, and no to the changing the link from appendix P to the entire spec because that is what the text says. The registration is appendix P and the spec is the spec, and no-one is going to mix them up surely.

It says that there is the SVG 1.1 specification, and it says the media type registration is extracted from appendix P of it.

Alexey, Keith, I request that we move ahead with the text that I submited earlier, on Wednesday, 24 November 2010, 23:36:35  (Wed, 24 Nov 2010 23:36:35 +0100)

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Date: Thu, 25 Nov 2010 15:30:41 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Chris Lilley <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

Sorry to pull back yet another time. I just found a comment by Björn 
Höhrmann in another thread saying that RFC 3032 doesn't define fragment 
identifiers. Upon checking, I found the following:

http://tools.ietf.org/html/rfc3023#section-5
 >>>>
5. Fragment Identifiers

    Section 4.1 of [RFC2396] notes that the semantics of a fragment
    identifier (the part of a URI after a "#") is a property of the data
    resulting from a retrieval action, and that the format and
    interpretation of fragment identifiers is dependent on the media type
    of the retrieval result.

    As of today, no established specifications define identifiers for XML
    media types.  However, a working draft published by W3C, namely "XML
    Pointer Language (XPointer)", attempts to define fragment identifiers
    for text/xml and application/xml.  The current specification for
    XPointer is available at http://www.w3.org/TR/xptr.
 >>>>

On top of that, http://www.w3.org/TR/xptr/ says it's superseeded. In 
this light, the following text from the registration may need 
reconsideration:

 >> Fragment Identifiers
 >>
 >> For documents labeled as application/svg+xml, the fragment
 >> identifier notation is that for application/xml, as specified
 >> in RFC 3023 or its successors, plus the SVG-specific SVG Views
 >> syntax described in the SVG specification.

What about:

 >>>>
Fragment Identifiers

For documents labeled as application/svg+xml, the fragment
identifier notation follows the XML Pointer Language (XPointer) 
Framework (see http://www.w3.org/TR/xptr-framework/). Fragment 
identifiers are either Shorthand Pointers (formerly called barenames) or 
SVG view specifications. For details, please see Section 17.3.2 of the 
SVG specification 
(http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers).
 >>>>

or some such. I hope that RFC 3023bis can be completed soon, and make 
this easier, but I hope we don't need to wait for this to complete the 
image/svg+xml registration.

This also brings me to another nit. The registration currently says:

 >> Published specification:
 >>
 >> This media type registration is extracted from Appendix P of the
 >> SVG 1.1 specification.
 >> http://www.w3.org/TR/SVG/mimereg.html

First, we made some tweaks, and second, the published specification is 
all of SVG 1.1, not just the mimereg part, as far as I understand. So 
what about something like:

 >>>>
Published specification:

This media type registration is an extracted and slightly adapted 
version of Appendix P of the SVG 1.1 specification
(http://www.w3.org/TR/SVG11/).
 >>>>

I'm not against replacing SVG 1.1 with something like "the latest and 
greatest SVG specification" (and a link to http://www.w3.org/TR/SVG/), 
but I think we should be consistent.

Regards,    Martin.

On 2010/11/25 14:30, "Martin J. Dürst" wrote:
> This looks good to me. I hope this can move forward to the next step
> (IESG approval?) soon, so that image/svg+xml can finally be properly
> registered.
>
> Regards, Martin.
>
> On 2010/11/25 7:36, Chris Lilley wrote:
>>
>> This is an updated registration request, incorporating the latest
>> round of feedback.
>>
>>
>> Type name:
>>
>> image
>>
>> Subtype name:
>>
>> svg+xml
>>
>> Required parameters:
>>
>> None.
>>
>> Optional parameters:
>>
>> charset
>>
>> Same as application/xml media type, as specified in [RFC3023] or
>> its successors.
>>
>> Encoding considerations:
>>
>> Same as for application/xml. See [RFC3023], section 3.2 or its
>> successors.
>>
>> 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.
>>
>> 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 the published 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:
>>
>> The published 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://www.w3.org/TR/SVG/mimereg.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
>>
>> Note that the extension 'svgz' is used as an alias for
>> 'svg.gz' [RFC1952], i.e. octet streams of type image/svg+xml,
>> subsequently compressed with gzip.
>>
>> Macintosh file type code(s):
>>
>> "svg " (all lowercase, with a space character as the fourth letter).
>>
>> Note that the Macintosh file type code 'svgz' (all lowercase)
>> is used as an alias for GZIP [RFC1952] compressed "svg ", i.e.
>> octet streams of type image/svg+xml, subsequently compressed
>> with gzip.
>>
>> Macintosh Universal Type Identifier code:
>>
>> org.w3c.svg conforms to public.image and to public.xml
>>
>> Windows Clipboard Name:
>>
>> "SVG Image"
>>
>> Fragment Identifiers
>>
>> For documents labeled as application/svg+xml, the fragment
>> identifier notation is that for application/xml, as specified
>> in RFC 3023 or its successors, plus the SVG-specific SVG Views
>> syntax described in the SVG specification.
>>
>> Person& email address to contact for further information:
>>
>> Chris Lilley, Doug Schepers ([email-masked]).
>>
>> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
From: Keith Moore <[email-masked]>
Date: Thu, 25 Nov 2010 01:21:05 -0500
Cc: Chris Lilley <[email-masked]>, Alexey Melnikov <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Henri Sivonen <[email-masked]>, Larry Masinter <[email-masked]>
To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Sender: [email-masked]

+1.  

Let's try to make things clear for people who are reading just the type registration.  Someone who looks at the registration separately from the RFC or other specification shouldn't have to guess as to what "this specification" is.

Keith

On Nov 25, 2010, at 12:46 AM, Martin J. Dürst wrote:

> Hello Chris, Larry,
> 
> On 2010/11/25 7:16, Chris Lilley wrote:
>> 
>> On Wednesday, November 24, 2010, 9:14:12 PM, Larry wrote:
>> 
>> LM>  Martin, in a couple of places you complained that the SVG registration
>> LM>  template, contained in a W3C document, referred to "this specification",
>> LM>  and said:
>> 
>> LM>  # "this specification" doesn't work when the registration template is
>> LM>  # taken out of the SVG spec. Either say "the SVG specification" or
>> LM>  # explicitly reference a specific version of the specification.
>> 
>> LM>  However, I think it is common practice both in W3C and IETF, that
>> LM>  a registration template embedded within another document can
>> LM>  reasonably say "this specification" to mean the document in which
>> LM>  it is embedded,
> 
> In that context, this looks reasonable, but out of context, it does no longer make sense. Registration are often taken out of context, and should be able to stand alone, without readers having to guess what "the specification" might be.
> 
>> LM>  with the registry itself pointing to an
>> LM>  explicit version of the spec as well as the template within.
> 
> IANA often, if not always, lists the relevant RFC. But I haven't seen them listing other specifications. I may have missed it. Anyway, that's usually outside the registration, so the registration is still not standalone.
> 
>> Larry, your interjection is timely, as I was just about to edit the registration to address Martin's comment.
>> 
>> Given that we already have
>> 
>> Published specification:
>> 
>>     This media type registration is extracted from Appendix P of the
>>     SVG 1.1 specification. http://www.w3.org/TR/SVG/
>> 
>> I'm tempted to just s/this specification/the published specification/
> 
> Great! That makes the registration standalone, while at the same time doesn't look weird inside the specification.
> 
>> LM>  There are plenty of examples... perhaps those comments don't apply?
> 
> The fact that there are plenty of examples doesn't mean that we can't fix it when we have a chance. I don't think it's worth doing back and fixing one by one, but if we are working on a registration anyway, we can make it better form the start.
> 
>> LM>  (This comment applies to all registries, not just of media types.)
> 
> Agreed.
> 
> 
> Regards,   Martin.
> 
> -- 
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types
> 

Date: Thu, 25 Nov 2010 14:46:18 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Chris Lilley <[email-masked]>
CC: Larry Masinter <[email-masked]>, Alexey Melnikov <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Henri Sivonen <[email-masked]>
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

Hello Chris, Larry,

On 2010/11/25 7:16, Chris Lilley wrote:
>
> On Wednesday, November 24, 2010, 9:14:12 PM, Larry wrote:
>
> LM>  Martin, in a couple of places you complained that the SVG registration
> LM>  template, contained in a W3C document, referred to "this specification",
> LM>  and said:
>
> LM>  # "this specification" doesn't work when the registration template is
> LM>  # taken out of the SVG spec. Either say "the SVG specification" or
> LM>  # explicitly reference a specific version of the specification.
>
> LM>  However, I think it is common practice both in W3C and IETF, that
> LM>  a registration template embedded within another document can
> LM>  reasonably say "this specification" to mean the document in which
> LM>  it is embedded,

In that context, this looks reasonable, but out of context, it does no 
longer make sense. Registration are often taken out of context, and 
should be able to stand alone, without readers having to guess what "the 
specification" might be.

> LM>  with the registry itself pointing to an
> LM>  explicit version of the spec as well as the template within.

IANA often, if not always, lists the relevant RFC. But I haven't seen 
them listing other specifications. I may have missed it. Anyway, that's 
usually outside the registration, so the registration is still not 
standalone.

> Larry, your interjection is timely, as I was just about to edit the registration to address Martin's comment.
>
> Given that we already have
>
> Published specification:
>
>      This media type registration is extracted from Appendix P of the
>      SVG 1.1 specification. http://www.w3.org/TR/SVG/
>
> I'm tempted to just s/this specification/the published specification/

Great! That makes the registration standalone, while at the same time 
doesn't look weird inside the specification.

> LM>  There are plenty of examples... perhaps those comments don't apply?

The fact that there are plenty of examples doesn't mean that we can't 
fix it when we have a chance. I don't think it's worth doing back and 
fixing one by one, but if we are working on a registration anyway, we 
can make it better form the start.

> LM>  (This comment applies to all registries, not just of media types.)

Agreed.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

Date: Thu, 25 Nov 2010 14:30:17 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Chris Lilley <[email-masked]>
CC: [email-masked], [email-masked], Alexey Melnikov <[email-masked]>, Philippe Le Hegaret <[email-masked]>
Subject: Re: Registration of media typeimage/svg+xml
Sender: [email-masked]

This looks good to me. I hope this can move forward to the next step 
(IESG approval?) soon, so that image/svg+xml can finally be properly 
registered.

Regards,   Martin.

On 2010/11/25 7:36, Chris Lilley wrote:
>
> This is an updated registration request, incorporating the latest
> round of feedback.
>
>
> Type name:
>
>      image
>
> Subtype name:
>
>      svg+xml
>
> Required parameters:
>
>      None.
>
> Optional parameters:
>
>      charset
>
>      Same as application/xml media type, as specified in [RFC3023] or
>      its successors.
>
> Encoding considerations:
>
>      Same as for application/xml. See [RFC3023], section 3.2 or its
>      successors.
>
> 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.
>
>      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 the published 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:
>
>      The published 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://www.w3.org/TR/SVG/mimereg.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
>
>          Note that the extension 'svgz' is used as an alias for
>          'svg.gz' [RFC1952], i.e. octet streams of type image/svg+xml,
>          subsequently compressed with gzip.
>
>      Macintosh file type code(s):
>
>          "svg " (all lowercase, with a space character as the fourth letter).
>
>          Note that the Macintosh file type code 'svgz' (all lowercase)
>          is used as an alias for GZIP [RFC1952] compressed "svg ", i.e.
>          octet streams of type image/svg+xml, subsequently compressed
>          with gzip.
>
>      Macintosh Universal Type Identifier code:
>
>          org.w3c.svg conforms to public.image and to public.xml
>
>      Windows Clipboard Name:
>
>          "SVG Image"
>
>      Fragment Identifiers
>
>          For documents labeled as application/svg+xml, the fragment
>          identifier notation is that for application/xml, as specified
>          in RFC 3023 or its successors, plus the SVG-specific SVG Views
>          syntax described in the SVG specification.
>
> Person&  email address to contact for further information:
>
>      Chris Lilley, Doug Schepers ([email-masked]).
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

Date: Wed, 24 Nov 2010 23:36:35 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Chris Lilley <[email-masked]>
CC: [email-masked], [email-masked], Alexey Melnikov <[email-masked]>, Philippe Le Hegaret <[email-masked]>
Subject: Re: Registration of media typeimage/svg+xml
Sender: [email-masked]

This is an updated registration request, incorporating the latest
round of feedback.

Type name:

    image

Subtype name:

    svg+xml

Required parameters:

    None.

Optional parameters:

    charset

    Same as application/xml media type, as specified in [RFC3023] or
    its successors.

Encoding considerations:

    Same as for application/xml. See [RFC3023], section 3.2 or its
    successors.

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.

    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 the published 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:

    The published 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://www.w3.org/TR/SVG/mimereg.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

        Note that the extension 'svgz' is used as an alias for
        'svg.gz' [RFC1952], i.e. octet streams of type image/svg+xml,
        subsequently compressed with gzip.

    Macintosh file type code(s):

        "svg " (all lowercase, with a space character as the fourth letter).

        Note that the Macintosh file type code 'svgz' (all lowercase)
        is used as an alias for GZIP [RFC1952] compressed "svg ", i.e.
        octet streams of type image/svg+xml, subsequently compressed
        with gzip.

    Macintosh Universal Type Identifier code:

        org.w3c.svg conforms to public.image and to public.xml

    Windows Clipboard Name:

        "SVG Image"

    Fragment Identifiers

        For documents labeled as application/svg+xml, the fragment
        identifier notation is that for application/xml, as specified
        in RFC 3023 or its successors, plus the SVG-specific SVG Views
        syntax described in the SVG specification.

Person & email address to contact for further information:

    Chris Lilley, Doug Schepers ([email-masked]).

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   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Date: Wed, 24 Nov 2010 23:16:12 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Larry Masinter <[email-masked]>
CC: "=?iso-8859-1?Q?=22Martin_J._D=FCrst=22?=" <[email-masked]>, Alexey Melnikov <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Henri Sivonen <[email-masked]>
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

On Wednesday, November 24, 2010, 9:14:12 PM, Larry wrote:

LM> Martin, in a couple of places you complained that the SVG registration
LM> template, contained in a W3C document, referred to "this specification",
LM> and said:

LM> # "this specification" doesn't work when the registration template is 
LM> # taken out of the SVG spec. Either say "the SVG specification" or 
LM> # explicitly reference a specific version of the specification.

LM> However, I think it is common practice both in W3C and IETF, that
LM> a registration template embedded within another document can
LM> reasonably say "this specification" to mean the document in which
LM> it is embedded, with the registry itself pointing to an
LM> explicit version of the spec as well as the template within.

Larry, your interjection is timely, as I was just about to edit the registration to address Martin's comment.

Given that we already have

Published specification:

    This media type registration is extracted from Appendix P of the
    SVG 1.1 specification. http://www.w3.org/TR/SVG/

I'm tempted to just s/this specification/the published specification/

LM> There are plenty of examples... perhaps those comments don't apply?

LM> (This comment applies to all registries, not just of media types.)

LM> Larry

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Date: Fri, 19 Nov 2010 20:30:53 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Julian Reschke <[email-masked]>
CC: Yves Lafon <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

Yes, and the same for the Macintosh file type code(s).
(sorry I missed this in my last mail)

Regards,   Martin.

On 2010/11/19 19:53, Julian Reschke wrote:
> On 19.11.2010 10:57, Yves Lafon wrote:
>> On Thu, 18 Nov 2010, Chris Lilley wrote:
>>
>>> Additional information:
>>>
>>> Magic number(s):
>>> File extension(s):
>>> svg, svgz (if gzip-compressed)
>>
>> Wouldn't it be better to say:
>>
>> File extension(s):
>> svg
>> Note that 'svgz' is used as an alias for 'svg.gz' [RFC1952]
>
> "Note that the extension 'svgz' is used as an alias for 'svg.gz'
> [RFC1952], i.e. octet streams of type image/svg+xml, subsequently
> compressed with gzip."
>
> (this emphasizes that it stops being image/xvg+xml)
>
> Best regards, Julian
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

Date: Fri, 19 Nov 2010 11:53:12 +0100
From: Julian Reschke <[email-masked]>
To: Yves Lafon <[email-masked]>
CC: Chris Lilley <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

On 19.11.2010 10:57, Yves Lafon wrote:
> On Thu, 18 Nov 2010, Chris Lilley wrote:
>
>> Additional information:
>>
>> Magic number(s):
>> File extension(s):
>> svg, svgz (if gzip-compressed)
>
> Wouldn't it be better to say:
>
> File extension(s):
> svg
> Note that 'svgz' is used as an alias for 'svg.gz' [RFC1952]

"Note that the extension 'svgz' is used as an alias for 'svg.gz' 
[RFC1952], i.e. octet streams of type image/svg+xml, subsequently 
compressed with gzip."

(this emphasizes that it stops being image/xvg+xml)

Best regards, Julian

Date: Fri, 19 Nov 2010 10:11:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Yves Lafon <[email-masked]>
CC: Chris Lilley <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

Yves Lafon wrote:
> On Thu, 18 Nov 2010, Chris Lilley wrote:
>> Additional information:
>>
>>    Magic number(s):
>>    File extension(s):
>>        svg, svgz (if gzip-compressed)
> Wouldn't it be better to say:
>
>     File extension(s):
>         svg
>         Note that 'svgz' is used as an alias for 'svg.gz' [RFC1952] 
Yes.

Date: Fri, 19 Nov 2010 10:42:14 +0100
From: Julian Reschke <[email-masked]>
To: Chris Lilley <[email-masked]>
CC: Ned Freed <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>, Maciej Stachowiak <[email-masked]>
Subject: Re: Registration of media typeimage/svg+xml
Sender: [email-masked]

On 18.11.2010 23:22, Chris Lilley wrote:
> ...
> In that case I can remove the section.
> ...

Thanks for that!

> ...
> Julian, does that satisfy your concern as well?
> ...

Partly. As Björn already said, the svgz file extension still is 
mentioned in a way that could be understood to say that the gzipped 
variant *is* the same mime type.

I think we have now agree that it is not, right?

One way to address this would be to mention it elsewhere, stating this 
is just a convention, and how it needs to be handled. I do believe that 
the registration template is not the best place for it, though (maybe a 
WG Note that establishes the filename convention and shows how to serve 
that stuff over HTTP?).

Of course an alternative is to make it a *separate* media type. I 
believe that Maciej Stachowiak said at the Lyon TPAC that Safari on 
MacOS internally uses media types, and that they actually had to add a 
workaround so that they could map both *.svg and *.svgz to the same 
(hopefully I got that right; cc'ing him). That's exactly the kind of 
problem I'm hoping to avoid.

Best regards, Julian

Date: Fri, 19 Nov 2010 14:34:47 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Chris Lilley <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked], [email-masked], Henri Sivonen <[email-masked]>, Larry Masinter <[email-masked]>
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
Sender: [email-masked]

Hello Chris, others,

On 2010/11/19 7:52, Chris Lilley wrote:
> This is an updated registration request, incorporating some feedback
> from Ned Freed<[email-masked]>  and Julian Reschke<[email-masked]>

I agree with Ned and Julian. This registration now looks good to me, 
except for a little detail pointed out below.

As for why I was very uneasy with mentioning .svgz in the Mime Media 
Type registration of image/svg+xml, please see the following excerpt 
from a conversation between Larry Masinter and Henri Sivonen 
(http://lists.w3.org/Archives/Public/www-tag/2010Nov/0053.html):

 >>>>
 > What were the problems with image/svg+xml, image/jp2 and/or video/mp4?

The problem with image/svg+xml is that after a decade of deployment and 
W3C REC status, the type still isn't in the registry. Even if the IETF 
experts found something wrong with the type, it would be way too late to 
stop its deployment, so there's really no point in subjecting it to 
expert review at this point.
 >>>>

 >>>>
 > As for image/svg+xml not being used for 'XML' format. I think this is 
a 3023bis issue?

Do you mean sending gzipped data as image/svg+xml without 
Content-Encoding: gzip?
 >>>>

I concluded (I hope erroneously) that there was gzipped SVG content out 
there that was sent with a naked Content-Type: image/svg+xml, and that 
some people in the industry thought that that was just okay. It is very 
clear that it is not okay, and that the registry should not at all 
suggest that it would be okay.

> 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 successors.
>
> Encoding considerations:
>
>      Same as for application/xml. See [RFC3023], section 3.2 or it's
>      successors.
>
> 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.
>
>      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

"this specification" doesn't work when the registration template is 
taken out of the SVG spec. Either say "the SVG specification" or 
explicitly reference a specific version of the specification.

>      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

Same problem here.

>      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://www.w3.org/TR/SVG/
>
> 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).
>      Macintosh Universal Type Identifier code:
>          org.w3c.svg conforms to public.image and to public.xml
>      Windows Clipboard Name:
>          "SVG Image"
>      Fragment Identifiers
>          For documents labeled as application/svg+xml, the fragment
>          identifier notation is that for application/xml, as specified
>          in RFC 3023 or its successors, plus the SVG-specific SVG Views
>          syntax described in the SVG specification.
>
> Person&  email address to contact for further information:
>
>      Chris Lilley, Doug Schepers ([email-masked]).
>
> 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.

And same problem here again. Actually, in this case, I'm under the 
impression that "Change controller" refers to the change controller of 
the registration, not the specification (which would be the same, but 
would be written differently). But I might be wrong.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

Date: Thu, 18 Nov 2010 23:52:36 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Chris Lilley <[email-masked]>
CC: [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Registration of media typeimage/svg+xml
Sender: [email-masked]

This is an updated registration request, incorporating some feedback
from Ned Freed <[email-masked]> and Julian Reschke <[email-masked]>

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 successors.
    
Encoding considerations:

    Same as for application/xml. See [RFC3023], section 3.2 or it's
    successors.
    
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.

    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://www.w3.org/TR/SVG/

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).
    Macintosh Universal Type Identifier code:
        org.w3c.svg conforms to public.image and to public.xml
    Windows Clipboard Name:
        "SVG Image"
    Fragment Identifiers
        For documents labeled as application/svg+xml, the fragment
        identifier notation is that for application/xml, as specified
        in RFC 3023 or its successors, plus the SVG-specific SVG Views
        syntax described in the SVG specification.

Person & email address to contact for further information:

    Chris Lilley, Doug Schepers ([email-masked]).

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   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Date: Thu, 18 Nov 2010 23:22:49 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Ned Freed <[email-masked]>
CC: Julian Reschke <[email-masked]>, [email-masked], <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: Registration of media typeimage/svg+xml
Sender: [email-masked]

On Thursday, November 18, 2010, 10:26:51 PM, Ned wrote:

>> On 18.11.2010 21:01, Chris Lilley wrote:
 read BCP 13, RFC 4288 section 4.6 "Security requirements" where you will find
>> >
>> >        A media type that employs compression may provide an opportunity
>> >        for sending a small amount of data that, when received and
>> >        evaluated, expands enormously to consume all of the recipient's
>> >        resources.  All media types SHOULD state whether or not they
>> >        employ compression, and if they do they should discuss
>> >        what  steps need to be taken to avoid such attacks.

NF> Read the section again. It is clearly talking about media types that employ
NF> compression *internally*, not compression done at other layers.

NF> Any media type can, and often is, compressed at other layers. Discussion
NF> of such actions has no business being in any particular media type
NF> registration.

OK. 

NF> If, however, the answer is never - and I'm pretty sure it is - then all mention
NF> of compression needs to be dropped from this registration, as it is doing
NF> nothing useful and is just making things unclear. At most you might want a note
NF> about it in the encoding consideration sections saying external compression is
NF> often used with this type. Again, lots of media types are compressed at other
NF> layers; this has nothing to do with the image/svg+xml media type specifically.

In that case I can remove the section.

Julian, does that satisfy your concern as well?

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

From: [email-masked]
Cc: Chris Lilley <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Date: Thu, 18 Nov 2010 13:26:51 -0800 (PST)
Subject: Re: Registration of media typeimage/svg+xml
To: Julian Reschke <[email-masked]>
Sender: [email-masked]

> On 18.11.2010 21:01, Chris Lilley wrote:
> > On Thursday, November 18, 2010, 8:19:20 PM, Julian wrote:
> >
> > JR>  On 18.11.2010 19:02, Chris Lilley wrote:
> >>> ...
> >>> 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-Encoding or
> >>>       Transfer-Encoding header, as appropriate; 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.
> >>> ...
> >
> > JR>  1) What does this have to do with "Security Considerations"?
> >
> > Please read BCP 13, RFC 4288 section 4.6 "Security requirements" where you will find
> >
> >        A media type that employs compression may provide an opportunity
> >        for sending a small amount of data that, when received and
> >        evaluated, expands enormously to consume all of the recipient's
> >        resources.  All media types SHOULD state whether or not they
> >        employ compression, and if they do they should discuss
> >        what  steps need to be taken to avoid such attacks.

Read the section again. It is clearly talking about media types that employ
compression *internally*, not compression done at other layers.

Any media type can, and often is, compressed at other layers. Discussion
of such actions has no business being in any particular media type
registration.

> Agreed.

> But then it would need to be clearly stated, that, you know, the content
> can be gzipped and still be image/svg+xml.

> Can it?

This is indeed the question: If I have a static object of type image/svg+xml,
is it inside a gzip container or not? If the answer to this question is
yes, then:

(a) The security consideration section is appropriate, but needs to be
    clarified to state specifically that the media type employs compression
    internally, and

(b) The +xml on the type name MUST be removed, because the type cannot simply
    be processed directly as XML, which is what +xml means.

The same actions apply if the answer is "sometimes".

If, however, the answer is never - and I'm pretty sure it is - then all mention
of compression needs to be dropped from this registration, as it is doing
nothing useful and is just making things unclear. At most you might want a note
about it in the encoding consideration sections saying external compression is
often used with this type. Again, lots of media types are compressed at other
layers; this has nothing to do with the image/svg+xml media type specifically. 

> Because otherwise if you're talking about compression on the transport
> layer, this doesn't need to be stated here. It confuses layers.

Exactly.

> > JR>  2) I find the whole paragraph misleading; I'd like to see a clear
> > JR>  statement about whether the stream of octets resulting from gzipping SVG
> > JR>  can be labeled as "image/svg+xml" or not
> >
> > Not by itself, no. In a MIME context, it must be labelled as Content-type:
> > image/svg+xml **AND** Transfer-Encoding: gzip. Please note the AND.

Sorry, you cannot make that a requirement of a media type. At most you can
suggest that a compressed encoding may be helpful. But general purpose media
types like this travel over all sorts of different transports all the time -
including ones that lack support for particular compression mechanisms - so the
notion that they're constrained to a particular transport is simply a fantasy.

> So why we do have the paragraph above in the first place?

Exactly.

> *Any* media type can be used with Content-Encoding: gzip over HTTP.

> > This is not the same thing as Content-type: application/octet-stream and  Transfer-Encoding: gzip - because that conveys the encoding, but omits the content type.

> Nobody said that.

> > In other words the encoding label ADDS TO the media type; it does not
> remove the type.

> "The Content-Encoding entity-header field is used as a modifier to the
> media-type. When present, its value indicates what additional content
> codings have been applied to the entity-body, and thus what decoding
> mechanisms must be applied in order to obtain the media-type referenced
> by the Content-Type header field. Content-Encoding is primarily used to
> allow a document to be compressed without losing the identity of its
> underlying media type." --
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.11>

> So once you apply the Content-Encoding you have to undo it to get back
> the payload specified by the Content-Type. It's orthogonal. It doesn't
> make the payload an instance of the media type *until* you undo the
> encoding.

Correct.

> > Indeed, this is why separate labelling of encoding was added. Back in the early days people would use gzipped VRML or gzipped PostScript, and attempted to register application/gzip; but since they were using the Media Type to hold the encoding information they had lost important information, so VRML viewers were sent PostScript and so on.  Some people said this was okay, unzip and then look at the filename extension. But a much better way was to add the encoding headers.
> >
> > JR>  (please consider transports
> > JR>  other than HTTP, such as a file system that actually supports typing by
> > JR>  Internet media types).
> >
> > Please feel free to file a bug report for the BeOS filesystem saying that
> > it should support labelling of encodings in addition to media types.

How a particular OS elects to label files, and the restrictions it imposes
through it's choice of labelling, are 100% irrlevant to the matter at hand.

> > Speaking as a former BeOS user myself, I still consider modern SVG
> > implementations (of which there are many) to be a rather more numerous and
> > relevant consideration than a promising, but obsolete and abandoned, operating
> > system from 15 years ago.

Frankly, it would not matter if you were talking about all versions of Windows
here. Many if not most operating systems have botched media type handling in
some way or other; the solution to this problem isn't to break existing media
type semantics.

> I really honestly (!) have no idea what you're referring to.

> For the media type registration what's relevant is what kind of octet
> sequences you can label with the type you register.

> So, I hear you saying: "it can be gzipped when used in a MIME context if
> and only if you label it with "content-encoding: gzip".

> That's true, and nobody disagrees with it. It's true for *any* media
> type. It doesn't require any additional statements.

Quite right.

> > JR>  If yes, that's a violation of "+xml" (and the last sentence points into
> > JR>  this direction). If not, please remove the paragraph above.
> >
> > JR>  3) If the intent is to say that "svgz" acts as file extension for
> > JR>  gzipped SVG, and *that* content can be served over HTTP as-is with
> >
> > JR>          Content-Type: image/svg+xml
> > JR>          Content-Encoding: gzip
> >
> > That is exactly what it says, yes
> >
> > JR>  than this is obviously ok
> >
> > I'm glad its obviously OK.

> But the way it's stated is totally misleading.

> Please keep in mind that I only joined this discussion after other
> people complained (I stumbled into it during a conversation at the IETF
> meeting in Maastricht).

> > JR>  because it follows from RFC 2616, and has
> > JR>  *nothing* to do with the media type (except for the extension
> > JR>  recommendation).
> >
> > So you oppose reminding people how to detect such gzipped content?
> >
> > Why would you want to do that?

> Because it makes it sound like detecting gzipped content by inspecting
> the header is an acceptable way to handle this media type.

That's exactly what it does, and that along with the other confusion really
is not OK.

				Ned

Date: Thu, 18 Nov 2010 21:20:04 +0100
From: Julian Reschke <[email-masked]>
To: Chris Lilley <[email-masked]>
CC: [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Registration of media typeimage/svg+xml
Sender: [email-masked]

On 18.11.2010 21:01, Chris Lilley wrote:
> On Thursday, November 18, 2010, 8:19:20 PM, Julian wrote:
>
> JR>  On 18.11.2010 19:02, Chris Lilley wrote:
>>> ...
>>> 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-Encoding or
>>>       Transfer-Encoding header, as appropriate; 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.
>>> ...
>
> JR>  1) What does this have to do with "Security Considerations"?
>
> Please read BCP 13, RFC 4288 section 4.6 "Security requirements" where you will find
>
>        A media type that employs compression may provide an opportunity
>        for sending a small amount of data that, when received and
>        evaluated, expands enormously to consume all of the recipient's
>        resources.  All media types SHOULD state whether or not they
>        employ compression, and if they do they should discuss
>        what  steps need to be taken to avoid such attacks.

Agreed.

But then it would need to be clearly stated, that, you know, the content 
can be gzipped and still be image/svg+xml.

Can it?

Because otherwise if you're talking about compression on the transport 
layer, this doesn't need to be stated here. It confuses layers.

> JR>  2) I find the whole paragraph misleading; I'd like to see a clear
> JR>  statement about whether the stream of octets resulting from gzipping SVG
> JR>  can be labeled as "image/svg+xml" or not
>
> Not by itself, no. In a MIME context, it must be labelled as Content-type: image/svg+xml **AND** Transfer-Encoding: gzip. Please note the AND.

So why we do have the paragraph above in the first place?

*Any* media type can be used with Content-Encoding: gzip over HTTP.

> This is not the same thing as Content-type: application/octet-stream and  Transfer-Encoding: gzip - because that conveys the encoding, but omits the content type.

Nobody said that.

> In other words the encoding label ADDS TO the media type; it does not remove the type.

"The Content-Encoding entity-header field is used as a modifier to the 
media-type. When present, its value indicates what additional content 
codings have been applied to the entity-body, and thus what decoding 
mechanisms must be applied in order to obtain the media-type referenced 
by the Content-Type header field. Content-Encoding is primarily used to 
allow a document to be compressed without losing the identity of its 
underlying media type." -- 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.11>

So once you apply the Content-Encoding you have to undo it to get back 
the payload specified by the Content-Type. It's orthogonal. It doesn't 
make the payload an instance of the media type *until* you undo the 
encoding.

> Indeed, this is why separate labelling of encoding was added. Back in the early days people would use gzipped VRML or gzipped PostScript, and attempted to register application/gzip; but since they were using the Media Type to hold the encoding information they had lost important information, so VRML viewers were sent PostScript and so on.  Some people said this was okay, unzip and then look at the filename extension. But a much better way was to add the encoding headers.
>
> JR>  (please consider transports
> JR>  other than HTTP, such as a file system that actually supports typing by
> JR>  Internet media types).
>
> Please feel free to file a bug report for the BeOS filesystem saying that it should support labelling of encodings in addition to media types.
>
> Speaking as a former BeOS user myself, I still consider modern SVG implementations (of which there are many) to be a rather more numerous and relevant consideration than a promising, but obsolete and abandoned, operating system from 15 years ago.

I really honestly (!) have no idea what you're referring to.

For the media type registration what's relevant is what kind of octet 
sequences you can label with the type you register.

So, I hear you saying: "it can be gzipped when used in a MIME context if 
and only if you label it with "content-encoding: gzip".

That's true, and nobody disagrees with it. It's true for *any* media 
type. It doesn't require any additional statements.

> JR>  If yes, that's a violation of "+xml" (and the last sentence points into
> JR>  this direction). If not, please remove the paragraph above.
>
> JR>  3) If the intent is to say that "svgz" acts as file extension for
> JR>  gzipped SVG, and *that* content can be served over HTTP as-is with
>
> JR>          Content-Type: image/svg+xml
> JR>          Content-Encoding: gzip
>
> That is exactly what it says, yes
>
> JR>  than this is obviously ok
>
> I'm glad its obviously OK.

But the way it's stated is totally misleading.

Please keep in mind that I only joined this discussion after other 
people complained (I stumbled into it during a conversation at the IETF 
meeting in Maastricht).

> JR>  because it follows from RFC 2616, and has
> JR>  *nothing* to do with the media type (except for the extension
> JR>  recommendation).
>
> So you oppose reminding people how to detect such gzipped content?
>
> Why would you want to do that?

Because it makes it sound like detecting gzipped content by inspecting 
the header is an acceptable way to handle this media type.

Best regards, Julian

Date: Thu, 18 Nov 2010 21:01:21 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Julian Reschke <[email-masked]>
CC: [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Registration of media typeimage/svg+xml
Sender: [email-masked]

On Thursday, November 18, 2010, 8:19:20 PM, Julian wrote:

JR> On 18.11.2010 19:02, Chris Lilley wrote:
>> ...
>> 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-Encoding or
>>      Transfer-Encoding header, as appropriate; 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.
>> ...

JR> 1) What does this have to do with "Security Considerations"?

Please read BCP 13, RFC 4288 section 4.6 "Security requirements" where you will find

      A media type that employs compression may provide an opportunity
      for sending a small amount of data that, when received and
      evaluated, expands enormously to consume all of the recipient's
      resources.  All media types SHOULD state whether or not they
      employ compression, and if they do they should discuss 
      what  steps need to be taken to avoid such attacks.

JR> 2) I find the whole paragraph misleading; I'd like to see a clear 
JR> statement about whether the stream of octets resulting from gzipping SVG
JR> can be labeled as "image/svg+xml" or not 

Not by itself, no. In a MIME context, it must be labelled as Content-type: image/svg+xml **AND** Transfer-Encoding: gzip. Please note the AND.

This is not the same thing as Content-type: application/octet-stream and  Transfer-Encoding: gzip - because that conveys the encoding, but omits the content type.

In other words the encoding label ADDS TO the media type; it does not remove the type.

Indeed, this is why separate labelling of encoding was added. Back in the early days people would use gzipped VRML or gzipped PostScript, and attempted to register application/gzip; but since they were using the Media Type to hold the encoding information they had lost important information, so VRML viewers were sent PostScript and so on.  Some people said this was okay, unzip and then look at the filename extension. But a much better way was to add the encoding headers.

JR> (please consider transports 
JR> other than HTTP, such as a file system that actually supports typing by
JR> Internet media types).

Please feel free to file a bug report for the BeOS filesystem saying that it should support labelling of encodings in addition to media types. 

Speaking as a former BeOS user myself, I still consider modern SVG implementations (of which there are many) to be a rather more numerous and relevant consideration than a promising, but obsolete and abandoned, operating system from 15 years ago.

JR> If yes, that's a violation of "+xml" (and the last sentence points into
JR> this direction). If not, please remove the paragraph above.

JR> 3) If the intent is to say that "svgz" acts as file extension for 
JR> gzipped SVG, and *that* content can be served over HTTP as-is with

JR>         Content-Type: image/svg+xml
JR>         Content-Encoding: gzip

That is exactly what it says, yes

JR> than this is obviously ok 

I'm glad its obviously OK.

JR> because it follows from RFC 2616, and has 
JR> *nothing* to do with the media type (except for the extension 
JR> recommendation).

So you oppose reminding people how to detect such gzipped content?

Why would you want to do that?

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Date: Thu, 18 Nov 2010 20:19:20 +0100
From: Julian Reschke <[email-masked]>
To: Chris Lilley <[email-masked]>
CC: [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Registration of media typeimage/svg+xml
Sender: [email-masked]

On 18.11.2010 19:02, Chris Lilley wrote:
> ...
> 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-Encoding or
>      Transfer-Encoding header, as appropriate; 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.
> ...

1) What does this have to do with "Security Considerations"?

2) I find the whole paragraph misleading; I'd like to see a clear 
statement about whether the stream of octets resulting from gzipping SVG 
can be labeled as "image/svg+xml" or not (please consider transports 
other than HTTP, such as a file system that actually supports typing by 
Internet media types).

If yes, that's a violation of "+xml" (and the last sentence points into 
this direction). If not, please remove the paragraph above.

3) If the intent is to say that "svgz" acts as file extension for 
gzipped SVG, and *that* content can be served over HTTP as-is with

	Content-Type: image/svg+xml
	Content-Encoding: gzip

than this is obviously ok because it follows from RFC 2616, and has 
*nothing* to do with the media type (except for the extension 
recommendation).

Best regards, Julian

Date: Thu, 18 Nov 2010 19:02:55 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Chris Lilley <[email-masked]>
CC: [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Registration of media typeimage/svg+xml
Sender: [email-masked]

This is an updated registration request, incorporating some feedback
from Paul Libbrecht <[email-masked]>, Mark Baker
<[email-masked]>, Henry S. Thompson <[email-masked]>
and Alexey Melnikov <[email-masked]>.

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 successors.
    
Encoding considerations:

    Same as for application/xml. See [RFC3023], section 3.2 or it's
    successors.
    
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-Encoding or
    Transfer-Encoding header, as appropriate; 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 P of the
    SVG 1.1 specification. http://www.w3.org/TR/SVG/

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).
    Macintosh Universal Type Identifier code:
        org.w3c.svg conforms to public.image and to public.xml
    Windows Clipboard Name:
        "SVG Image"
    Fragment Identifiers
        For documents labeled as application/svg+xml, the fragment
        identifier notation is that for application/xml, as specified
        in RFC 3023 or its successors, plus the SVG-specific SVG Views
        syntax described in the SVG specification.

Person & email address to contact for further information:

    Chris Lilley, Doug Schepers ([email-masked]).

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   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups