Handling XML objects in MIME

Chris Lilley | 18 Nov 2010 19:02

Re: Registration of media typeimage/svg+xml


This is an updated registration request, incorporating some feedback
from Paul Libbrecht <paul <at> activemath.org>, Mark Baker
<distobj <at> acm.org>, Henry S. Thompson <ht <at> inf.ed.ac.uk>
and Alexey Melnikov <alexey.melnikov <at> isode.com>.

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.

(Continue reading)

headers

Julian Reschke | 18 Nov 2010 20:19

Re: Registration of media typeimage/svg+xml

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

(Continue reading)

headers

Chris Lilley | 18 Nov 2010 21:01

Re: Registration of media typeimage/svg+xml

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

(Continue reading)

headers

Julian Reschke | 18 Nov 2010 21:20

Re: Registration of media typeimage/svg+xml

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.

(Continue reading)

headers

Ned Freed | 18 Nov 2010 22:26

Re: Registration of media typeimage/svg+xml


> 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

(Continue reading)

headers

Chris Lilley | 18 Nov 2010 23:22

Re: Registration of media typeimage/svg+xml

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.

(Continue reading)

headers

Julian Reschke | 19 Nov 2010 10:42

Re: Registration of media typeimage/svg+xml

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.

(Continue reading)

headers

Chris Lilley | 18 Nov 2010 23:52

Re: Registration of media typeimage/svg+xml

This is an updated registration request, incorporating some feedback
from Ned Freed <ned.freed <at> mrochek.com> and Julian Reschke <julian.reschke <at> gmx.de>

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,

(Continue reading)

headers

Martin J. Dürst | 19 Nov 2010 06:34

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


Hello Chris, others,

On 2010/11/19 7:52, Chris Lilley wrote:
> This is an updated registration request, incorporating some feedback
> from Ned Freed<ned.freed <at> mrochek.com>  and Julian Reschke<julian.reschke <at> gmx.de>

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

(Continue reading)

headers

Larry Masinter | 24 Nov 2010 21:14

Re: Registration of media typeimage/svg+xml

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

# "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.

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

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

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

Larry
--

-- 
http://larry.masinter.net

headers

Chris Lilley | 24 Nov 2010 23:16

Re: Registration of media typeimage/svg+xml

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

(Continue reading)

headers

Martin J. Dürst | 25 Nov 2010 06:46

Re: Registration of media typeimage/svg+xml

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

(Continue reading)

headers

Keith Moore | 25 Nov 2010 07:21

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


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

(Continue reading)

headers

Keith Moore | 25 Nov 2010 07:21

Re: Registration of media typeimage/svg+xml

+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

(Continue reading)

headers

Yves Lafon | 19 Nov 2010 10:57

Re: Registration of media typeimage/svg+xml

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]

>    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 (member-svg-media-type <at> w3.org).

(Continue reading)

headers

Alexey Melnikov | 19 Nov 2010 11:11

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


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.

headers

Julian Reschke | 19 Nov 2010 11:53

Re: Registration of media typeimage/svg+xml

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

headers

Martin J. Dürst | 19 Nov 2010 12:30

Re: Registration of media typeimage/svg+xml

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

(Continue reading)

headers

Alexey Melnikov | 19 Nov 2010 11:11

Re: Registration of media typeimage/svg+xml

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.

headers

Martin J. Dürst | 19 Nov 2010 06:34

Re: Registration of media typeimage/svg+xml

Hello Chris, others,

On 2010/11/19 7:52, Chris Lilley wrote:
> This is an updated registration request, incorporating some feedback
> from Ned Freed<ned.freed <at> mrochek.com>  and Julian Reschke<julian.reschke <at> gmx.de>

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?

(Continue reading)

headers

Chris Lilley | 24 Nov 2010 23:36

Re: Registration of media typeimage/svg+xml

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,

(Continue reading)

headers

Martin J. Dürst | 25 Nov 2010 06:30

Re: Registration of media typeimage/svg+xml

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.

(Continue reading)

headers

Martin J. Dürst | 25 Nov 2010 07:30

Re: Registration of media typeimage/svg+xml

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

(Continue reading)

headers

Chris Lilley | 25 Nov 2010 07:53

Re: Registration of media typeimage/svg+xml

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

(Continue reading)

headers

Martin J. Dürst | 25 Nov 2010 10:24

Re: Registration of media typeimage/svg+xml

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

(Continue reading)

headers

Ned Freed | 25 Nov 2010 21:25

Re: Registration of media typeimage/svg+xml

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

(Continue reading)

headers

Julian Reschke | 26 Nov 2010 12:14

Re: Registration of media typeimage/svg+xml

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

headers

Chris Lilley | 7 Dec 2010 15:52

Re: Registration of media typeimage/svg+xml

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

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. 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 looked into this. At first, I was going to normatively reference XPointer Framework as you suggested.

However, the SVG WG had made a decision not to reference XPointer (superceeded) and not to reference
XPointer Framework either, partly because of concerns over the scope of the conformance criteria
http://www.w3.org/TR/xptr-framework/#conformance
and also because this is not in any case needed just to define barenames.

So I have added adapted wording:

    Fragment Identifiers

        For documents labeled as application/svg+xml, the 
        fragment identifier notation is either Shorthand Pointers
        (formerly called barenames) or the SVG-specific SVG Views

(Continue reading)

headers

Martin J. Dürst | 8 Dec 2010 08:39

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


Hello Chris, others,

I'm glad to confirm that I'm extremely happy with your new wording.

And I strictly promise I won't find any new hair in the soup anymore.

Regards,    Martin.

On 2010/12/07 23:52, Chris Lilley wrote:
> On Thursday, November 25, 2010, 7:30:41 AM, Martin wrote:
>
> 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. 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 looked into this. At first, I was going to normatively reference XPointer Framework as you suggested.
>
> However, the SVG WG had made a decision not to reference XPointer (superceeded) and not to reference

(Continue reading)

headers

Martin J. Dürst | 8 Dec 2010 08:39

Re: Registration of media typeimage/svg+xml

Hello Chris, others,

I'm glad to confirm that I'm extremely happy with your new wording.

And I strictly promise I won't find any new hair in the soup anymore.

Regards,    Martin.

On 2010/12/07 23:52, Chris Lilley wrote:
> On Thursday, November 25, 2010, 7:30:41 AM, Martin wrote:
>
> 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. 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 looked into this. At first, I was going to normatively reference XPointer Framework as you suggested.
>
> However, the SVG WG had made a decision not to reference XPointer (superceeded) and not to reference
XPointer Framework either, partly because of concerns over the scope of the conformance criteria

(Continue reading)

headers

Ned Freed | 25 Nov 2010 21:01

Re: Registration of media typeimage/svg+xml

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

(Continue reading)

headers

Julian Reschke | 30 Nov 2010 09:19

Re: Registration of media typeimage/svg+xml

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:

(Continue reading)

headers

Chris Lilley | 30 Nov 2010 18:14

Re: Registration of media typeimage/svg+xml

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

(Continue reading)

headers

Alexey Melnikov | 30 Nov 2010 19:21

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


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

headers

Alexey Melnikov | 30 Nov 2010 19:21

Re: Registration of media typeimage/svg+xml

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

headers

ned+xml-mime | 1 Dec 2010 20:25

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


> OK, is there anything left to do?

The only remaining issue, which came up afer I sent this, is the bit about
fragment ids. I'm happy with Martin's proposal change on that front, but
others may not be.

> Or is this already on the way to IANA?

This is a standards tree registration so it goes to the IESG, not IANA.

				Ned

headers

Ned Freed | 1 Dec 2010 20:25

Re: Registration of media typeimage/svg+xml

> OK, is there anything left to do?

The only remaining issue, which came up afer I sent this, is the bit about
fragment ids. I'm happy with Martin's proposal change on that front, but
others may not be.

> Or is this already on the way to IANA?

This is a standards tree registration so it goes to the IESG, not IANA.

				Ned