Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
Peter Saint-Andre <stpeter@stpeter.im> Tue, 17 April 2012 03:00 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5911E808A for <apps-discuss@ietfa.amsl.com>; Mon, 16 Apr 2012 20:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Fv6w2hOw9qf for <apps-discuss@ietfa.amsl.com>; Mon, 16 Apr 2012 20:00:26 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 22DD211E8076 for <apps-discuss@ietf.org>; Mon, 16 Apr 2012 20:00:26 -0700 (PDT)
Received: by stpeter.im (Postfix, from userid 1006) id 5FABD4005B; Mon, 16 Apr 2012 21:14:34 -0600 (MDT)
Date: Mon, 16 Apr 2012 21:14:34 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
To: Ned Freed <ned.freed@mrochek.com>
Message-ID: <20120417031434.GA6746@stpeter.im>
References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <CA8E55D5-822A-47DC-B5CB-583CC328227B@jenitennison.com> <4F87EBD4.90501@gmx.de> <CFA00AEC-F80B-4517-8101-A5DDA57555ED@jenitennison.com> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <01OEE9DUSD8400ZUIL@mauve.mrochek.com>
Jabber-ID: stpeter@jabber.org
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
Cc: Jeni Tennison <jeni@jenitennison.com>, apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, Julian Reschke <julian.reschke@gmx.de>, Noah Mendelsohn <nrm@arcanedomain.com>, john+ietf@jck.com, "www-tag@w3.org List" <www-tag@w3.org>
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Apr 2012 03:00:26 -0000
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
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Ned Freed
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Murray S. Kucherawy
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Julian Reschke
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Jeni Tennison
- [apps-discuss] W3C TAG Comment on Draft Media Typ… Noah Mendelsohn
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Julian Reschke
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Ned Freed
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Noah Mendelsohn
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Bjoern Hoehrmann
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Jeni Tennison
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Peter Saint-Andre
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Murray S. Kucherawy
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Peter Saint-Andre
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Ned Freed
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Bjoern Hoehrmann
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Peter Saint-Andre
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Ned Freed
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Ned Freed
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Julian Reschke
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Ned Freed
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Jeni Tennison
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Jeni Tennison
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Bjoern Hoehrmann
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Ned Freed
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Tony Hansen
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Ned Freed
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Julian Reschke
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Henry S. Thompson
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Jeni Tennison
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Bjoern Hoehrmann
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Henry S. Thompson
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Noah Mendelsohn
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Tony Hansen
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Bjoern Hoehrmann
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Henry S. Thompson
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Bjoern Hoehrmann
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Ned Freed
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Ned Freed
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Ned Freed
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Henry S. Thompson
- Re: [apps-discuss] W3C TAG Comment on Draft Media… Henry S. Thompson
- Re: [apps-discuss] W3C TAG Comment on Draft Media… David Booth