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 examp=
le,
wait on 3023bis before approving the registrations in other trees that arri=
ve
at a rate of several every week. We've tried that tack before and we know w=
hat
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 someo=
ne bringing up a last minute problem as soon as it looks like we can go ahe=
ad.

> Really sorry about that.

> > MJD>   I just found a comment by Bj=F6rn
> > MJD>  H=F6hrmann 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, name=
ly "XML
> > MJD>      Pointer Language (XPointer)", attempts to define fragment ide=
ntifiers
> > 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 writ=
ten 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 buil=
t 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 barena=
mes) 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 depe=
nds 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 complet=
e the
> > MJD>  image/svg+xml registration.
> >
> > Exactly. So - no.
> >
> > MJD>  This also brings me to another nit. The registration currently sa=
ys:
> >
> >   >>>  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 beca=
use 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 submit=
ed earlier, on Wednesday, 24 November 2010, 23:36:35  (Wed, 24 Nov 2010 23:=
36:35 +0100)
> >

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