- From: Tony Hansen <tony@maillennium.att.com>
- Date: Thu, 19 Apr 2012 09:35:01 -0400
- CC: "www-tag@w3.org List" <www-tag@w3.org>, apps-discuss@ietf.org
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
Received on Thursday, 19 April 2012 20:41:27 UTC