Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures

From: Ned Freed <[email-masked]>
Date: Thu, 12 Apr 2012 19:49:51 -0700 (PDT)

> The W3C Technical Architecture Group have been concerned about conflicting
> sources of definitions of fragment identifier semantics located by
> following RFC 3986 and the media type definition. We believe that those
> defining and registering media types (including ones that follow generic
> rules such as 3023bis) need more explicit advice than currently contained
> within draft-ietf-appsawg-media-type-regs.

> In particular, we are working on defining best practice for use and
> definition of fragment identifier semantics, and the document
> http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12 is under
> development (although it has not been formally reviewed or approved by the
> TAG).

Referencing a developing draft, rather than a final specification, especially
when the reference is pretty clearly going to be normative, is going to be a
major problem.

> We believe media type registration authors should be pointed to these
> recommendations by reference from draft-ietf-appsawg-media-type-regs.

See above. If my understanding of the rules is correct, that's really not
possible until your specification is stable. What is something in the final
version conflicts in some way? What if something in the final version is
rejected by IETF consensus?

This is exactly why I refrained from adding a reference to the xdash document
until it was clearly stable, and why I considered every other alternative
before very reluctantly adding a reference to the mime-default-charset
specification. And these are both specifications internal to the IETF.

> We would like to coordinate the development of these documents effectively
> and would appreciate your feedback on how best to accomplish this.

Well, not to put too fine a point on it, but it sure would have been nice to
have been aware of this at some point in the last 10 months (the -00 version of
this revision was posted as a draft on 13-Jun-2011), instead of on the day
before the end of the WGLC.

Anyway, since I'm just the editor here and not one of the people managing the
process, I'm going to defer to the document shepard, WG chairs, and the Apps
ADs as to what should happen now. But the one thing I'm definitely not going to
do on my own is add a reference to a developing document.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Apr 2012 06:11:51 +0000

Hello Noah,

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Ned Freed
> Sent: Thursday, April 12, 2012 7:50 PM
> To: Noah Mendelsohn
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
> 
> > The W3C Technical Architecture Group have been concerned about
> > conflicting sources of definitions of fragment identifier semantics
> > located by following RFC 3986 and the media type definition. We
> > believe that those defining and registering media types (including
> > ones that follow generic rules such as 3023bis) need more explicit
> > advice than currently contained within draft-ietf-appsawg-media-type-regs.

I'm the document shepherd and responsible working group co-chair for this document.  I concur with Ned on all of his points, perhaps especially that the timing of this kind of input is unfortunate.

Can you provide (hopefully quickly) more specifics about the advice you think is absent from the draft?

-MSK, APPSAWG co-chair

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Apr 2012 11:03:16 +0200

On 2012-04-13 10:30, Jeni Tennison wrote:
> Hi Murray, Ned,
> ...

I read your document this morning and I think it's really helpful. Now 
how to coordinate with the registration spec is indeed a tricky question.

> (Not speaking for the TAG, just trying to give you a rapid response.)
>
> On 13 Apr 2012, at 07:11, Murray S. Kucherawy wrote:
> I am really sorry that we haven't raised these issues more explicitly earlier in the process, and completely understand that you can't point to a draft document and don't want your publication to be held up. That's precisely why we want to discuss how best to manage providing guidance about fragment identifiers with you: it could be:
>
>    * incorporating some specific text into the draft
>    * including a reference out to a document which we'll try to expedite through the W3C publication process
>    * adding some general hand-wavy text in the draft about guidance about fragids being available elsewhere
>    * not touching the media type specification draft but creating another draft specifically about fragment identifiers that can be published later that references and builds on it
>
> Basically I don't think we know how best to provide guidance about fragment identifiers in such a way that it's findable for those registering media types.
>
> What we see happening is that fragment identifier syntax is being specified at four levels:
>
>    1. the general pattern whereby plain name fragment identifiers are used to reference things related to the document, or named fragments within them
>    2. generic syntax specified for top-level types (eg Media Fragment URIs [1])

Here be dragons.

As far as I understand there is no inheritance of fragment identifier 
syntax from top-level types. The Media Fragment spec essentially has 
invented it; without coordinating with the IETF.

>    3. generic syntax specified for types sharing a suffix (eg XPointer for XML [2])
>    4. specific syntax specified for individual media types
>
> Taking these in reverse order, I think what we're aiming for is:
>
> Media type registrants need to be guided to specify the fragment identifier schemes that they inherit from any top-level type or suffix type and how any clashes should be handled. They also need to be guided to reserve plain name fragment identifiers for their common use, and to think about what constraints the media type places on "active fragment identifiers" which may be used within scripts.

If there is no multiple inheritance (from top level types), there should 
be fewer or no clashes at all.

> Registrations for structured syntax suffix types need to include information about the interpretation of fragment identifiers in types with that suffix, and there should be a field along those lines on the registration form for them.

Sounds right to me.

> Fragment identifier schemes for top-level types also need to be findable somehow. If the media type specification draft is the only place that they are defined, then the references need to go in there. We should think about what would happen if someone came up with a fragment identifier scheme for, say, lines and characters in text files based on line/column numbering and how that would be found.
>
> I'm now the one tasked within the TAG on drafting the precise guidance. It seems to me that it isn't all that much text (if you cut out all the explanation and rationale that's in the draft we pointed you at [3]). It might be that if we can incorporate it directly within the media type specification draft that would be the quickest route, but I don't know. I'd really value your advice about the best way forward.
>
> Thanks,
>
> Jeni
>
> [1] http://www.w3.org/TR/media-frags/
> [2] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag

Note that the draft above has never been submitted as Internet Draft, so 
from the IETF's point of view it doesn't exist. See 
<https://datatracker.ietf.org/doc/draft-murata-kohn-lilley-xml/>.

> [3] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12

Best regards, Julian

---

From: Jeni Tennison <[email-masked]>
Date: Fri, 13 Apr 2012 09:30:57 +0100

Hi Murray, Ned,

Thanks,

Jeni

[1] http://www.w3.org/TR/media-frags/
[2] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag
[3] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12
-- 
Jeni Tennison
http://www.jenitennison.com

---

From: Noah Mendelsohn <[email-masked]>
Date: Thu, 12 Apr 2012 21:10:06 -0400

Noah Mendelsohn
For the W3C Technical Architecture Group

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Apr 2012 19:42:57 +0200

On 2012-04-13 12:34, Jeni Tennison wrote:
> Hi Julian,
>
> On 13 Apr 2012, at 10:03, Julian Reschke wrote:
>> As far as I understand there is no inheritance of fragment identifier syntax from top-level types. The Media Fragment spec essentially has invented it; without coordinating with the IETF.
>
> I think that their assumption was actually that all the image/*, video/* and audio/* types would re-register, referencing the Media Fragment spec. Perhaps that's the best way of handling it, and nothing needs to be said specifically about fragments identifiers for top-level types.
>
> In that case, the media type specification draft would need to point out that other media types within the same top-level type may describe the use of a particular fragment identifier syntax, and that if they do then to make content negotiation between different media types work more smoothly, it's best to adopt that same fragid syntax in new media types rather than inventing a new one.

Makes sense.

Can we turn this into advice for new media type registrations to be 
included into the updated registration spec?

Best regards, Julian

---

From: Ned Freed <[email-masked]>
Date: Fri, 13 Apr 2012 22:00:37 -0700 (PDT)

> I think that their assumption was actually that all the image/*, video/* and
> audio/* types would re-register, referencing the Media Fragment spec.

Let me put the kibosh on any such assumption right now. The primary purpose of
this revision exercise is to try and get more people to register the media
types they use. This is, for a variety of reasons, a lot harder than it sounds.

And you can multiply the reluctance of registrants by a factor of 100 at least
when it comes to updating registrations. We're actually doing an adequate job
of getting initial registrations for new types outside of the standards tree,
but the number of people who are willing to revise registrations to include
additional information, especially if that has no immediate relevance to them
personally, is negligable.

As such, the notion that existing registrations will be updated wholesale to
include fragment identifier information is nothing short of laughable.

> Perhaps that's the best way of handling it, and nothing needs to be said
> specifically about fragments identifiers for top-level types.

This isn't an option either. This is a registration best current practices
(BCP) document that sets down rules for registering media types. Default or
intrinsic syntax and semantics of fragment identifiers associated with a
particular top-level type is a protocol specification. This isn't allowed in a
BCP - BCPs are one shot affairs and not subject to interoperability testing,
which rather obviously would apply to the specification of such semantics.

If you want to put this stuff in an RFC, it needs to one that's on the regular
standards track. And that means it needs to be in a different document. All you 
can put in this document are the registration rules for specifying a fragment
identifier. Nothing more.

> In that case, the media type specification draft would need to point out that
> other media types within the same top-level type may describe the use of a
> particular fragment identifier syntax, and that if they do then to make content
> negotiation between different media types work more smoothly, it's best to
> adopt that same fragid syntax in new media types rather than inventing a new
> one.

You can certainly put all that in a separate document and reference it here.
But I doubt very, very much that that can be done on a sufficiently short time
scale for this revision, although as I said before, I deferring how to handle
this to the document shepard, WG chairs, and apps ADs.

> > If there is no multiple inheritance (from top level types), there should be fewer or no clashes at all.

> Even without anything being said for top-level types, there's always the
> possibility of multiple inheritance. For example, say that someone invented a
> fragment identifier syntax for programming languages that used
> #function({name}) to reference functions within source files. If we wanted to
> use that with XSLT, we would need to say so within the application/xslt+xml
> media type definition and deal with the fact that the syntax clashed with
> XPointer syntax inherited through the use of the +xml suffix.

I have to say that this sounds like a much bigger problem than can possibly be
addressed by the addition of a few simple rules to the registration
specification, which given that the primary goal here is to have a registration
process people can use easily, is all that's going to be acceptable here.

> So it still rests with the media type definition itself to explain which
> fragment identifier schemes are supported and how they interact, even if
> there's no explicit recognition of inheritance from the top-level types.

I suspect that without some defaults, probably based on type suffix as much on
top-level types, laid out in one or more standards-track RFCs, this is unlikely
to get much traction.

> > from the IETF's point of view it doesn't exist.
> > See <https://datatracker.ietf.org/doc/draft-murata-kohn-lilley-xml/>.

> OK :) I believe the question of what exactly to put in that draft about
> fragment identifiers has been the main thing holding up its submission.

The point of publishing an Internet Draft isn't to expose your polished final
work to the world. Rather, it's to release your working material, missing parts
and all, so that unresolved issues like, say, how to handle fragment
identifiers can be exposed to broader discussion and input. This is
*especially* true of a document which, if the path is any indication, is
intended to be an update to RFC 3023.

Indeed, I'd have to call it highly inappropriate to have handled such an update
in this fashion.

					Ned

---

From: Noah Mendelsohn <[email-masked]>
Date: Fri, 13 Apr 2012 16:57:27 -0400

On 4/13/2012 6:34 AM, Jeni Tennison wrote:
> If we wanted to use that with XSLT, we would need to say so within the application/xslt+xml media type definition and deal with the fact that the syntax clashed with XPointer syntax inherited through the use of the +xml suffix.

Shouldn't we consider some overall advice as to whether generic semantics, 
with the goal of enabling generic processing based only on the top-level 
type is highly desirable in all cases/OK to selectively break in particular 
derived type specs/a completely false goal?

Noah

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 14 Apr 2012 23:52:14 +0200

>within draft-ietf-appsawg-media-type-regs.

Some people would like to have fragment identifier formats that apply to
entire classes of media types, but nobody cares enough to do the legwork
needed to put that into some kind of coherent standard. Issues would be,
for instance, whether RFC 3023 can and should be updated to retroactive-
ly define all "+xml" types use XPointer fragment identifiers and what to
do with the fallout from such a decision, like clashes with existing XML
types that assign different semantics to their fragment identifiers; and
if you have a common format for something like 2D visual media or timed
media, whether that can be accomplished with a similar retroactive over-
riding specification, or context-specific semantics, like for HTML <img>
the fragment identifier is interpreted in a common way unless otherwise
specified, or whether all existing registrations should be updated.

Firefox for instance now implements a special feature for video/ogg that
allows you to say http://example.org/video#t=30 and it will then seek 30
seconds into the video. RFC 5334, which defines video/ogg, however does
not mention such a feature. The syntax comes from a W3C proposal saying
that everybody should update their media type registrations to allow for
this syntax, and Ned Freed called that "nothing short of laughable" here
in this thread. I assume Firefox supports the same for "WebM", but I've
not been able to get "WebM" to work there at all and "WebM" doesn't have
a registered media type anyway.

The W3C has so far failed to build consensus around what should be done
with respect to these issues, so there is nothing draft-ietf-appsawg-
media-type-regs could advise, short of the Applications Area Working
Group building this consensus first. The Technical Architecture Group
would seem to be requesting that.

>development (although it has not been formally reviewed or approved by the 

I note that draft-ietf-appsawg-media-type-regs went from invididual sub-
mission to the end of the Working Group Last Call in about the time the
TAG did not review its own document that it now wants to have linked.

The document does not seem very useful for building consensus around the
issues I mentioned above, it is rather essentially written from a per-
spective where media type specific fragment identifiers have been re-
placed by universal "fragment structures" and attempts to make a couple
of suggestions. I will discuss them in reverse order:

  Fragment structures should be defined in ways that enable other
  processors to ignore fragment identifiers that use different fragment
  structures. Invalid fragment identifiers should result in a warning
  rather than an error.

How some application might treat an "invalid" or unrecognized fragment
identifier is very much up to the application, it is entirely possible
for instance that meaningful processing is no longer possible if some
secondary resource identified by a fragment identifier cannot be re-
trieved because the "fragment structure" is unknown to the application,
in which case an error would be far more appropriate than a warning.

The first part of this item addresses a "if there is no interoperabili-
ty" case; that's questionable in itself, and I really don't see what
this would mean in practise. If you take the example of #svgView, that
exists, among other things, so you can show a zoomed part of one image
in another. A processor that does not support that is not a conforming
SVG implementation and would not render the image as intended. So what
would the designers of the #svgView scheme care?

  Media type definitions should avoid 'must' language when describing
  supported fragment identifiers as in practice it is likely to be
  ignored. Instead, they should provide pointers to any known fragment
  structures that might be applied to that media type and give warnings
  of any contradictions between them.

I am unaware of any example where fragment identifier requirements were
ignored more than other requirement. Sure, some SVG implementations do
not support all aspects of SVG fragment identifiers, but they might also
fail to support SVG fonts or have broken error handling or can only load
external PNG and JPEG images but not external SVG images, so there does
not seem to be a reason to single this out. And quite frankly, this SVG
feature would not be very useful if it was optional, just as XInclude
would be quite difficult to use interoperably if it didn't require at
least the element() scheme.

  Fragment structures should be defined at levels that anticipate
  content negotiation. For example, the semantics of the svgView()
  fragment identifiers could be meaningfully applied to all image
  formats. Were a similar scheme developed in future, it should be
  defined for all images rather than a particular image format.

Anyone defining a media type can simply say their fragment identifier
syntax is the same as the syntax for SVG. They would likely have to
specify a whole lot of additional information (what if the identifier
references a region in a bitmap that is not aligned on pixel bounds?).
It may have been better had the scheme been named #imgView, but that's
about all I can make from this suggestion. I note that content nego-
tiation as a whole is not used in practise as assumed here, because it
doesn't work very well. The "server picks" model doesn't work well as
announcing all supported types all the time is infeasible, the "client
picks" model is hard to configure at the server level and not really
supported, never minding linking issues (if you copy and paste a URL
to send it someone else, do you want to link the representation, like
to point out a typo in a language negotiated page, or is it okay if
the recepient sees the page in a differnet language?) So this is of no
practical relevance anyway.

  Fragment structures which provide multiple ways of addressing the
  same secondary resource should indicate which fragment identifier
  is canonical and should be used for making statements about that
  secondary resource.

This has nothing to do with the "structures", there would be no point
in the SVG specification saying you have to use `2.0` where you could
also simply use `2` or the specification of the XPath scheme saying it
is always `[A and B]` and never `[B and A]`, and whether you reference
`#example` or `//p[3]` is again not a decision that the definition of
the media type or the fragment identifier "structure" can make. People
who publish documents might want to say "Please do not rely on section
numbers but rather use the IDs, the former may change", and in the odd
event  that some RDF folks want to make statements about regions in SVG
images, they might it sensible to follow certain conventions, and they
might indeed always use `2.0` instead of `2`, but having this in the
SVG specification itself would be akin to the HTML specification saying
people should not change section numbers or headings to make it easy to
create stable references to them.

>recommendations by reference from draft-ietf-appsawg-media-type-regs.

In its current form it does not provide useful information to people who
might want to register a media type. That is primarily because there is
currently no consensus whether someone registering, for instance, a new
image media type should care about "media fragments" and reference that
specification should they like to have #xywh fragment identifiers; if so
there would be some marginal utility in exposing them to their existence
but beyond that I don't see why anyone wishing to register a media type
should bother reading this document. 

>and would appreciate your feedback on how best to accomplish this.

I think it would be a good start if you abandon the "provide guidance"
idea, as that is just a means to an end, and define the problem to be
solved instead, show that it needs fixing, that it can be fixed, and so
on and so forth. A problem is that Firefox supports media fragments on
video/ogg resources but you cannot discover media fragments going from
any of the URI, MIME, HTTP, Ogg, Theora, and so on specifications in any
obvious manner. That is a problem. If people can simply make up their
own generic "structures", there is nothing much to prevent collisions.
That is probably also a problem. Maybe it's a bad idea for types to "in-
herit" fragment identifiers, maybe RFC3023bis should not add XPointer to
all +xml types. Maybe RFC 3986 should be updated to say that context may
also affect how fragment identifiers are interpreted, as above, "HTML5"
might say if you have `<img src='...#xywh=...'` then you ignore what the
media type definition says and apply media fragments semantics.

As far as giving guidance goes, it would be useful to know whether we
should tell people trying to register new media types whether they ought
to reference the media fragments specification. That's indeed something
that's relevant to the revision of RFC 4288. The media fragments speci-
fication suggests, yeah, they kinda should. What is the IETF position on
that? Who was asked to review and what did they say? I would expect that
there would have been comments to the effect that that's unrealistic, as
in the example given above. So how do we settle this question? That's a
problem, that's something the TAG might usefully spend time on. Whether
fragment identifier errors should be errors or warnings, not so much.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Jeni Tennison <[email-masked]>
Date: Mon, 16 Apr 2012 09:33:46 +0100

Hi Ned, all,

Here is a set of concrete suggestions for amendments to draft-ietf-appsawg-media-type-reg that I hope might focus discussion. Basically they 

  * create a specific section in the media type registration template for information about fragment identifier processing and provide some high-level guidance about what should go there
  * create a section within the structured syntax suffix registration template for discussions of generic processing of fragment identifiers across media types that use that structured syntax

I think there'd then be scope for a separate document that on all the details about prioritising between overlapping fragment identifier schemes and so on, but no need for that to be referenced from draft-ietf-appsawg-media-type-reg.

Thanks for your consideration,

Jeni

---

1. Add a new section 'Fragment Identifier Recommendations' (before the current 4.11 Additional Information) which says:

 Media type registrations SHOULD specify how applications should interpret
 fragment identifiers [RFC3986] within the media type.

 Media types SHOULD adopt fragment identifier schemes that are used with
 other similar media types, to facilitate content negotiation across them.
 In particular, media types that use a named structured syntax with a 
 registered "+suffix" SHOULD adopt any and all fragment identifier schemes 
 defined within the structured syntax suffix registration.

2. Remove the last bullet point from the list in 4.11 Additional Information, namely:

 o Information about how fragment/anchor identifiers [RFC3986] are
   constructed for use in conjunction with this media type.

3. In 5.7 Registration Template:

 a. Add a section 'Fragment identifier considerations'
 b. Remove the entry 'URI fragment/anchor identifier(s):' under Additional information

4. Within 6.2 Structured Syntax Suffix Registration Template add a new section:

 Fragment identifier considerations
   Generic processing of fragment identifiers for any type employing this
   syntax should be described here.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Apr 2012 10:07:08 -0600

> identifier. Nothing more.

Ned is right: this document defines best practices for *registering*
media types. We all might want to more clearly specify the syntax and
semantics of fragment identifiers, but IMHO that's out of scope for the
registration procedures per se.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Apr 2012 16:49:20 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Monday, April 16, 2012 9:07 AM
> To: Ned Freed
> Cc: Jeni Tennison; [email-masked];
> [email-masked]; Julian Reschke; Noah Mendelsohn;
> [email-masked]; [email-masked] List
> Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type
> Specifications and Registration Procedures
> 
> > If you want to put this stuff in an RFC, it needs to one that's on the
> > regular standards track. And that means it needs to be in a different
> > document. All you can put in this document are the registration rules
> > for specifying a fragment identifier. Nothing more.
> 

I think I agree.  Would it be an appropriate path forward to put that into another document, and then reference that one from this one as an Informative?

-MSK, as participant

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Apr 2012 10:53:43 -0600

On 4/16/12 10:49 AM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Peter
>> Saint-Andre Sent: Monday, April 16, 2012 9:07 AM To: Ned Freed Cc:
>> Jeni Tennison; [email-masked]; 
>> [email-masked]; Julian Reschke; Noah
>> Mendelsohn; [email-masked]; [email-masked] List Subject: Re:
>> [apps-discuss] W3C TAG Comment on Draft Media Type Specifications
>> and Registration Procedures
>> 
>>> If you want to put this stuff in an RFC, it needs to one that's
>>> on the regular standards track. And that means it needs to be in
>>> a different document. All you can put in this document are the
>>> registration rules for specifying a fragment identifier. Nothing
>>> more.
>> 
>> Ned is right: this document defines best practices for
>> *registering* media types. We all might want to more clearly
>> specify the syntax and semantics of fragment identifiers, but IMHO
>> that's out of scope for the registration procedures per se.
> 
> I think I agree.  Would it be an appropriate path forward to put that
> into another document, and then reference that one from this one as
> an Informative?

I don't think so. All we're trying to do here is make is easier for
folks to register media types. The thorny issues of the syntax and
semantics of media types and pointers thereto (which is what fragment
identifiers are at some level) are IMHO orthogonal to how you register
media types. Plus, the document we point to from the registration BCP
will likely change so significantly by the time it's done that the
citation will be mostly meaningless at this time.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ned Freed <[email-masked]>
Date: Mon, 16 Apr 2012 17:53:12 -0700 (PDT)

> Here is a set of concrete suggestions for amendments to
> draft-ietf-appsawg-media-type-reg that I hope might focus discussion. Basically
> they

>   * create a section within the structured syntax suffix registration template for discussions of generic processing of fragment identifiers across media types that use that structured syntax

This seems very reasonable.

> I think there'd then be scope for a separate document that on all the details
> about prioritising between overlapping fragment identifier schemes and so on,
> but no need for that to be referenced from draft-ietf-appsawg-media-type-reg.

I agree. This whole space is messy and guidance would be useful.

> 1. Add a new section 'Fragment Identifier Recommendations' (before the current 4.11 Additional Information) which says:

In keeping with the other sections, I'm going to call this "Fragment Identifier
Requirements".

>  fragment identifiers [RFC3986] within the media type.

Two issues here. First, a SHOULD means reviewers will have to push back on
registrations that don't include fragment identifier specifications. (SHOULD is
"MUST unless you have a good reason not to".) That's excessive at this point.

Second, "within the media type" doesn't make sense to me. Fragment identifiers
can be internal, I guess, but the common uses are external.

>  defined within the structured syntax suffix registration.

I expanded on this a little because I think there are a lot of uses besides
content negotiation. The final result for this addition is:

  Media type registrations can specify how applications should interpret
  fragment identifiers [RFC 3986] associated with the media type.

  Media types SHOULD adopt fragment identifier schemes that are used with
  other similar media types, to facilitate access and content negotiation across
  multiple types. In particular, media types that use a named structured syntax
  with a  registered "+suffix" SHOULD adopt any and all fragment identifier
  schemes defined within the structured syntax suffix registration.

>    constructed for use in conjunction with this media type.

Removed.

>  b. Remove the entry 'URI fragment/anchor identifier(s):' under Additional information

Added a and removed b.

>    syntax should be described here.

Added.

I'll wait a day or so for additional comments, then post a revised draft
with these changes.

I note that this raises the issue of what to do about fragment identifiers in
the initial suffix registry document. Fragment identifiers don't really make
sense for most of the suffixes defined there. The exceptions I see are +xml and
+json. +json seems simple enough - refer to draft-ietf-appsawg-json-pointer-01.

+xml is a bigger issue. This is a document to populate the registry; it is not
the place to define how fragment identifiers for XML work. But RFC 3023 section
5 seems a bit dated. And waiting for a revision for RFC 3023 when there isn't
even an I-D doesn't sound like a good idea. So dated or not, I guess a
reference to RFC 3023 is as good as it gets for now.

				Ned

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 17 Apr 2012 04:09:12 +0200

> fragment identifiers [RFC3986] within the media type.

I don't see how this would affect people who don't care about any frag-
ment identifier semantics of their media types other than putting "n/a"
in the template.

> other similar media types, to facilitate content negotiation across them.

There are no "fragment identifier schemes", that would have to be de-
fined, and it's rather unclear what "similar" is. Is XSL FO similar to
PDF and should thus allow, say, #page=13? This also does not seem to
address a problem that we actually have, people do not register types
with very similar yet different "fragment identifier schemes", and if
they did so, that would very likely be for good reasons. I also do not
agree with the "content negotiation" rationale.

> defined within the structured syntax suffix registration.

This is a layering violation. If the specification for the "+suffix"
syntax wants to require "sub-types" to do so then it can. There is no
reason to have this as part of the generic registration rules. This
would also imply that these "sub-types" have to do something special
to meet the requirement, rather than just having this by definition,
by virtue of following the "+suffix" convention. I see no reason why
the "+suffix" specification would make this SHOULD rather than MUST.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Apr 2012 21:14:34 -0600

> I'll wait a day or so for additional comments, then post a revised draft

That all looks good to me.

> reference to RFC 3023 is as good as it gets for now.

Agreed.

/psa

---

From: Ned Freed <[email-masked]>
Date: Mon, 16 Apr 2012 22:56:42 -0700 (PDT)

> I think I agree.  Would it be an appropriate path forward to put that into 
> another document, and then reference that one from this one as an Informative?

While it might be helpful to have such a reference, I don't think it's
necessary. And given that it's not required, the issue is timing. I don't
see much chance such a document can be generated in a reasonable amount of
time.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 16 Apr 2012 23:00:12 -0700 (PDT)

> ment identifier semantics of their media types other than putting "n/a"

n/a is not a specification. This is effectively saying that all media types
SHOULD have fragment identifiers. That's unreasonable.

> PDF and should thus allow, say, #page=13?

Fair point. Nevertheless, encouraging some amount of consistency seems like 
a good idea. It just doesn't rise to the level of a requirement.

> This also does not seem to
> they did so, that would very likely be for good reasons.

Actually, if the Wikipedia page on these things can be believed, they do. For
example, different fragment id syntaxes for "page N" with what appear to be
idential semantics seem to exist.

> I also do not

I'm by no means familiar with all content negotiation schemes out there, so 
I wasn't willing to be categorical about that.

That said, I agree it definitely isn't the main rationale. As I see it, the
main rationale for specifying fragment identifiers associated with a given type
is the obvious one: So that it gets implemented consistently and the ids, you
know, actually work when you use them.

> the "+suffix" specification would make this SHOULD rather than MUST.

Another fair point. But the meta-point here is that whatever rules are
associated with the suffix need to be followed by types using that suffix. And
it's reasonable to state that here.

Based on this feedback, I now have (I'm leaving the XML in this time):

<t>
Media type registrations can specify how applications should interpret
fragment identifiers <xref target="RFC3986"/> associated with the media type.
</t>

<t>
Media types are encouraged to adopt fragment identifier schemes that are used
with semantically similar media types. In particular, media types that use a
named structured syntax with a  registered "+suffix" MUST follow whatever
fragment identifier rules are given in the structured syntax suffix
registration.
</t>

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Apr 2012 09:15:38 +0200

> +json. +json seems simple enough - refer to draft-ietf-appsawg-json-pointer-01.

I think that would be premature.

The question has come up several times, and I don't think we are near 
any kind of even rough consensus about whether the spec should try to 
define a fragment identifier syntax for "+json" (or even application/json).

> reference to RFC 3023 is as good as it gets for now.

Indeed.

Best regards, Julian

---

From: Ned Freed <[email-masked]>
Date: Tue, 17 Apr 2012 08:25:28 -0700 (PDT)

> Ned, all,

> On 17 Apr 2012, at 01:53, Ned Freed wrote:

> Thank you very much for that. I'll bring the revised text to the attention of
> the TAG during the next telcon on Thursday, and raise the other issues that
> have been touched on during this discussion, namely:

Note that I have already made an additional revision and posted the
revised text. There may be additional revisions in fairly short order; I'll
post them as I make them.

				Ned

---

From: Jeni Tennison <[email-masked]>
Date: Mon, 16 Apr 2012 18:30:49 +0100

Peter,

> registration procedures per se.

Please can you advise whether the changes I proposed in [1] fit within that scope, and if not, what changes would make them do so?

Thanks,

Jeni

[1] http://lists.w3.org/Archives/Public/www-tag/2012Apr/0098.html
-- 
Jeni Tennison
http://www.jenitennison.com

---

From: Jeni Tennison <[email-masked]>
Date: Tue, 17 Apr 2012 10:21:08 +0100

Ned, all,

> I'll wait a day or so for additional comments, then post a revised draft

Thank you very much for that. I'll bring the revised text to the attention of the TAG during the next telcon on Thursday, and raise the other issues that have been touched on during this discussion, namely:

* the need for an I-D for 3023bis and coordination around the +xml structured syntax suffix registration
* the need for coordination between W3C and IETF over the Media Fragment URI work
* the development of a separate document with guidance about specifying fragment identifiers for media types

Thanks again for your help and sorry for the last-minute nature of these changes.

Cheers,

Jeni

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 18 Apr 2012 06:47:24 +0200

>idential semantics seem to exist.

Yeah, but if you use #page=13 versus #page(13) or some other variation
is likely for good reasons, like, you want to use some meta-mechanism
like XPointer that allows one but not the other. Would be nice to have
some proper statistics.

>fragment identifier rules are given in the structured syntax suffix

This seems reasonable to me, though it would seem better to turn that
into a general "+suffix types must follow +suffix rules, whatever they
are" requirement.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ned Freed <[email-masked]>
Date: Tue, 17 Apr 2012 21:48:44 -0700 (PDT)

> like XPointer that allows one but not the other. Would be nice to have

... maybe. Having seen so many examples in other places of disrepancies that
turned out to be completely superfluous, I'm skeptical.

> into a general "+suffix types must follow +suffix rules, whatever they

Even if we were to insert such a general requirement, I think this one is so
important it bears repeating. Especially since it indirectly places limits on
what you really want to allow in a fragment identifier description in your
suffix registration. If you make this material too restrictive, the result will
be that the suffix won't be usable, and I think that's a good thing.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Thu, 19 Apr 2012 09:35:01 -0400

>> reference to RFC 3023 is as good as it gets for now.

So, I'm revising my draft where I'm actually *registering* a bunch of 
these structured suffixes. (draft-hansen-media-type-suffix-reg)

What I'm thinking is that the fragment considerations section for each 
should simply point at the base application/whatever specification. That 
is, if application/SUFFIX has specific fragment identifiers associated 
with it, then anything with +SUFFIX (e.g., application/TYPE+SUFFIX) 
should accept the application/SUFFIX fragment identifiers as well as 
anything specific to the given media type.

So I've added these Fragment identifier considerations sections to the 
suffixes that have an underlying media type registration.

     Media types using "+json" MUST accept any fragment identifiers
     defined for "application/json". Specific media types may
     identify additional fragment identifier considerations.

I have similar text for +fastinfoset, +wbxml and +zip.

This way, the definition of fragment identifiers for application/json 
can progress at its own pace, as can any definitions of fragment 
identifiers for application/fastinfoset, application/vnd.wap.wbxml and 
application/zip.

In addition, I'm thinking draft-hansen-media-type-suffix-reg should have 
an IANA considerations note to add the Fragment identifier 
considerations section for +xml, with text similar to the above.

(I think the basic paragraph could use a little wordsmithing, but what I 
have there should get the right idea across.)

	Tony Hansen

---

From: Ned Freed <[email-masked]>
Date: Fri, 20 Apr 2012 00:24:43 -0700 (PDT)

> anything specific to the given media type.

The operative term here is "should". There may be very compelling reasons why
you want to support fragment identifiers but not the ones that are normally
associated with whatever format your media type uses.

For example, suppose you defined some sort of structured image representation
using XML. It is entirely possible that the elements of that representation are
basically worthless when it comes to referencing parts of the image. So it
makes no sense to require support for XPointer-based fragment ids in such a
case. Even if such fragment ids were useful for, say, some sort of general
editing application for XML, they neverthless would place an undue burden on
conforming imlementations of that type.

>      identify additional fragment identifier considerations.

I like the overall idea but, per the above, MUST is too strong. SHOULD
is appropriate here, and I'd capitalize the may in the second sentence.

> identifiers for application/fastinfoset, application/vnd.wap.wbxml and

Yes, this is very clever, and entirely apporpriate for an initial registry
content document. This is not the place to be defining default fragment
identifier mechanisms for suffixes. Doing so is going to require a lot of work,
and I expect a fair bit of contention for some of them.

Agreed.

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Apr 2012 10:50:02 +0200

> identify additional fragment identifier considerations.

Maybe, to avoid confusion, point out that at the time of publication, 
there was no fragment identifier syntax for JSON...

Best regards, Julian

---

From: [email-masked] (Henry S. Thompson)
Date: Fri, 20 Apr 2012 10:09:21 +0100

Tony Hansen writes:

> should simply point at the base application/whatever
> specification. That is, if application/SUFFIX has specific fragment
> identifiers associated with it, then anything with +SUFFIX (e.g.,
> application/TYPE+SUFFIX) should accept the application/SUFFIX fragment
> identifiers as well as anything specific to the given media type.
>
> In addition, I'm thinking draft-hansen-media-type-suffix-reg should
> have an IANA considerations note to add the Fragment identifier

If you go in that direction, please consider the fact that 3023bis
_is_ once again under active development, with W3C TAG cooperation,
and that something very similar to the following (slightly adapted
from the previous editors' draft) will likely appear therein:

  When a new media type is introduced for an XML-based format, the
  name of the media type SHOULD end with '+xml'. This convention will
  allow applications that can process XML generically to detect that
  the MIME entity is supposed to be an XML document, verify this
  assumption by invoking some XML processor, and then process the XML
  document accordingly. Applications may match for types that
  represent XML MIME entities by comparing the subtype to the pattern
  '*/*+xml'.

  XML generic processing is not always appropriate for XML-based media
  types. For example, authors of some such media types may wish that
  the types remain entirely opaque except to applications that are
  specifically designed to deal with that media type. By NOT following
  the naming convention '+xml', such media types can avoid XML-generic
  processing. Since generic processing will be useful in many cases,
  however -- including in some situations that are difficult to
  predict ahead of time -- those registering media types SHOULD use
  the '+xml' convention unless they have a particularly compelling
  reason not to. [1]

Note that these paragraphs address _more_ than just fragment
identifiers.  The level of "generic processing", i.e. processing
appropriate to any member of a stuctured-syntax family identified by a
+SUFFIX, is I think the appropriate one at which to address the mutual
dependency between app/foo and app/bar+foo.

ht

[1] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Jeni Tennison <[email-masked]>
Date: Fri, 20 Apr 2012 11:30:54 +0100

Hi Tony,

> is appropriate here, and I'd capitalize the may in the second sentence.

I agree with Ned about softening the wording. The other thing that you could specifically draw out is that fragment identifiers that are classed as errors in the media type related to the suffix may be classified as OK within a specific media type.

The other (word-smithing) comment I'd make is that it's not enough for the specific media type to 'accept' fragment identifiers: they should be processed in the same way as well.

So I'd suggest something like:

    Media types using "+json" SHOULD process any fragment identifiers
    defined for "application/json" in the same way as defined for that
    media type. Specific media types MAY identify additional fragment 
    identifier considerations and MAY define processing for fragment 
    identifiers that are classed as errors for "application/json".

Cheers,

Jeni

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 20 Apr 2012 21:45:08 +0200

>     identify additional fragment identifier considerations.

This says that "+json" cannot be used for JSON types where fragment
identifiers are of any concern since any future specification of the
application/json type may override such registrations in incompatible
ways. This seems to be missing the point of why we would have "+json"
to begin with.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: [email-masked] (Henry S. Thompson)
Date: Sat, 21 Apr 2012 16:12:08 +0100

> ways. This seems to be missing the point of why we would have "+json"

Or, it implies any update to a syntax schema registration such as
application/json has a responsibility to its "deployed base".  Comes
with the territory.

ht

---

From: Noah Mendelsohn <[email-masked]>
Date: Fri, 20 Apr 2012 14:54:35 -0400

On 4/20/2012 5:09 AM, Henry S. Thompson wrote:
> Note that these paragraphs address_more_  than just fragment

Right, I'm happy with that.

In the context of the overall recommendations on media types, I think it's 
worth thinking a bit about the tradeoffs. There are at least two possible 
goals for having each "derived" type accept (at least) the same 
syntax/semantics as the base: 1) it promotes least astonishment for users 
-- things work as you'd expect; 2) you might wish to enable generic processing.

If generic processing is a goal, then it's worth thinking about the 
consequences of SHOULD vs. MUST. If we go with SHOULD, which is OK with me, 
then it might be worth saying:

"Note: if the specification for a derived type provides for a different 
interpretation of some particular fragment identifier(s) than the base 
does, then generic processors may resolve such identifiers incorrectly."

So, SHOULD somewhat undercuts efforts to enable generic processing, insofar 
as it leaves open the possibility of misinterpreting even conforming 
identifiers and content. I think we should either go with MUST, or warn of 
the risk.

Noah

---

From: Tony Hansen <[email-masked]>
Date: Fri, 20 Apr 2012 13:44:41 -0400

Thanks for all the comments.

This is what I've come up with that seems to satisfy the concerns I've 
heard expressed so far:

Media types using "+json" SHOULD process any fragment identifiers 
defined for "application/json" in the same way as defined for that media 
type. (At publication of this document, there is no fragment 
identification syntax defined for "application/json".) Specific media 
types using "+json" MAY identify additional fragment identifier 
considerations, MAY define processing for fragment identifiers that are 
classed as errors for "application/json" and MAY designate fragment 
identifiers defined for "application/json" that SHOULD NOT be used.

Same text for +fastinfoset, +wbxml and +zip. The note I added for +xml 
is similar:

Media types using "+xml" SHOULD process any fragment identifiers defined 
for "application/xml" in the same way as defined for that media type. 
(At publication of this document, the fragment identification syntax 
considerations for "application/xml" are defined in <xref 
target='RFC3023'/>.) Specific media types using "+xml" MAY identify 
additional fragment identifier considerations, MAY define processing for 
fragment identifiers that are classed as errors for "application/xml" 
and MAY designate fragment identifiers defined for "application/xml" 
that SHOULD NOT be used.

	Tony Hansen

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 22 Apr 2012 00:03:18 +0200

>application/json has a responsibility to its "deployed base".  Comes

Saying that an inferior authority must obey a superior authority does
not imply that the superior authority is limited by choices any such
inferior authorities have made. We might find that taking such choices
into consideration is the responsible thing to do, but that is not what
the text says, and certainly not how authorities tend to operate. Look
no further than the +xml discussions where people do not find they need
to re-define +xml in a manner compatible with all existing +xml types.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: [email-masked] (Henry S. Thompson)
Date: Sat, 21 Apr 2012 23:09:19 +0100

> to re-define +xml in a manner compatible with all existing +xml types.

Actually, we've been continuing to struggle with that, and I _believe_
the next draft of 3023bis will fix that.

ht

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 22 Apr 2012 00:32:58 +0200

* Henry S. Thompson wrote:
>Actually, we've been continuing to struggle with that, [...]

Yes, indeed. That is the problem with the interpretation you proposed.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ned Freed <[email-masked]>
Date: Sat, 21 Apr 2012 19:20:17 -0700 (PDT)

> _is_ once again under active development, with W3C TAG cooperation,

First of all, given that there has been no I-D posting of a 3023bis "active
development" is a bit of a stretch. There may be something going on inside the
W3C, but 3023 is an IETF RFC, and that means new versions need to be posted as
I-Ds and discussion needs to be happning on an IETF list. I strongly urge
whoever is working on this to see that this happens ASAP.

All that aside, this sort of revision is the reason why Tony is taking this
approach. An 3023bis is necessarily going to contain both a new registration
for application/xml, quite likely including updated information on XML fragment
identifiers. Additionally, since +xml is defined in 3023 and assuming the new
media types registration procedures are in place before 3023bis, 3023bis is
going to have to contain an updated registration for +xml.

> dependency between app/foo and app/bar+foo.

Of course. And this actually won't be sufficient - as noted above, a
proper +xml registration will also be needed.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 21 Apr 2012 19:32:03 -0700 (PDT)

>     identifiers that are classed as errors for "application/json".

I think adding this is a good idea.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 21 Apr 2012 19:33:25 -0700 (PDT)

> and MAY designate fragment identifiers defined for "application/xml"

AFAICT this covers every point that has been raised.

				Ned

---

From: [email-masked] (Henry S. Thompson)
Date: Sun, 22 Apr 2012 11:23:23 +0100

> whoever is working on this to see that this happens ASAP.

Absolutely -- the 'active development' I refer to is only a few weeks
old, and the goal is to get a new I-D up as soon as possible.

> All that aside, this sort of revision is the reason why Tony is
> taking this approach. An 3023bis is necessarily going to contain
> both a new registration for application/xml, quite likely including
> updated information on XML fragment identifiers. Additionally, since
> +xml is defined in 3023 and assuming the new media types
> registration procedures are in place before 3023bis, 3023bis is

Since +xml is the structured syntax we have the most experience with
to date, I hope we can coordinate the two, so that the experience of
the XML community is not lost.

> proper +xml registration will also be needed.

For sure -- 3023 contained one, informally, as it were, in the absence
of official guidance at that time, and 3023bis will do so as well,
coordinated, as I said above, with the new official guidance.

ht

---

From: [email-masked] (Henry S. Thompson)
Date: Sun, 22 Apr 2012 11:25:59 +0100

> Yes, indeed. That is the problem with the interpretation you proposed.

Sorry I wasn't clear -- by "been continuing to struggle with" I meant
"been working to achieve compatibility with all existing types".

ht

---

From: David Booth <[email-masked]>
Date: Sun, 22 Apr 2012 11:20:51 -0400

> > type. 

Please forgive me if I am missing something obvious, but . . .

I find the sentence above ambiguous, as it isn't clear whether the
phrase 'that media type' refers to 'application/json' or 'Media types
using "+json"'.  I suggest being explicit instead of saying "that media
type".

> > for "application/xml" in the same way as defined for that media type.

Ditto.

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.