- 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