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

On Mon, Apr 16, 2012 at 05:53:12PM -0700, Ned Freed wrote:
> > 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
> 
> 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.
> 
> > Thanks for your consideration,
> 
> > Jeni
> 
> > ---
> 
> > 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".
> 
> >  Media type registrations SHOULD specify how applications should interpret
> >  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.
> 
> >  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.
> 
> 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.
> 
> > 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.
> 
> Removed.
> 
> > 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
> 
> Added a and removed b.
> 
> > 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.
> 
> Added.
> 
> I'll wait a day or so for additional comments, then post a revised draft
> with these changes.

That all looks good to me.

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

Agreed.

/psa

Received on Tuesday, 17 April 2012 03:00:54 UTC