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

[Ned Freed <[e-mail]>]

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

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