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

[Tony Hansen <[e-mail]>]

On 4/17/2012 3:15 AM, Julian Reschke wrote:
> On 2012-04-17 02:53, Ned Freed wrote:
>> ...
>> 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.
>> ...
>
> 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).
>
>> +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.

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