Re: [ietf-types] Registration of media typeimage/svg+xml

Chris Lilley <> Thu, 25 November 2010 06:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FD6C3A6AAA for <>; Wed, 24 Nov 2010 22:53:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.724
X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[AWL=-2.425, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Usj1bjqzrDJV for <>; Wed, 24 Nov 2010 22:53:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0C1D53A6AA9 for <>; Wed, 24 Nov 2010 22:53:42 -0800 (PST)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id oAP6s7EW018999 for <>; Wed, 24 Nov 2010 22:54:27 -0800
Received: from localhost ([]) by with esmtpa (Exim 4.69) (envelope-from <>) id 1PLViU-0002eL-5L; Thu, 25 Nov 2010 01:54:02 -0500
Date: Thu, 25 Nov 2010 07:53:32 +0100
From: Chris Lilley <>
X-Mailer: The Bat! (v3.95.6) Home
Organization: W3C
X-Priority: 3 (Normal)
Message-ID: <>
To: "\"Martin J. Dürst\"" <>
In-Reply-To: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 ( []); Wed, 24 Nov 2010 22:54:28 -0800 (PST)
Cc: Alexey Melnikov <>,,
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Chris Lilley <>
List-Id: "Media \(MIME\) type review" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Nov 2010 06:53:43 -0000

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>     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

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

MJD> On top of that, 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 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> (

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.

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, 

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> (

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