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

Jeni Tennison <jeni@jenitennison.com> Mon, 16 April 2012 08:33 UTC

Return-Path: <jeni@jenitennison.com>
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 31AA721F86D7 for <apps-discuss@ietfa.amsl.com>; Mon, 16 Apr 2012 01:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11]
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 1TA95FrUdqiW for <apps-discuss@ietfa.amsl.com>; Mon, 16 Apr 2012 01:33:52 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9B29F21F86D6 for <apps-discuss@ietf.org>; Mon, 16 Apr 2012 01:33:51 -0700 (PDT)
Received: from cpc19-epso4-2-0-cust100.6-3.cable.virginmedia.com ([86.30.196.101] helo=[192.168.123.64]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <jeni@jenitennison.com>) id 1SJhNd-0006ao-Nc; Mon, 16 Apr 2012 09:33:49 +0100
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="us-ascii"
From: Jeni Tennison <jeni@jenitennison.com>
In-Reply-To: <01OEABGEZ8RU00ZUIL@mauve.mrochek.com>
Date: Mon, 16 Apr 2012 09:33:46 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com>
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>
To: Ned Freed <ned.freed@mrochek.com>, "Murray S. Kucherawy" <msk@cloudmark.com>, john+ietf@jck.com, tony+mtsuffix@maillennium.att.com
X-Mailer: Apple Mail (2.1257)
X-Mailcore-Auth: 9919842
X-Mailcore-Domain: 1066436
X-Mailman-Approved-At: Mon, 16 Apr 2012 08:05:55 -0700
Cc: Julian Reschke <julian.reschke@gmx.de>, Noah Mendelsohn <nrm@arcanedomain.com>, apps-discuss@ietf.org, "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: Mon, 16 Apr 2012 08:33:54 -0000

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

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.

Thanks for your consideration,

Jeni

---

1. Add a new section 'Fragment Identifier Recommendations' (before the current 4.11 Additional Information) which says:

 Media type registrations SHOULD specify how applications should interpret
 fragment identifiers [RFC3986] within the media type.

 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.

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.

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

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.

-- 
Jeni Tennison
http://www.jenitennison.com