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

Julian Reschke <julian.reschke@gmx.de> Fri, 13 April 2012 17:43 UTC

Return-Path: <julian.reschke@gmx.de>
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 1A4A521F865D for <apps-discuss@ietfa.amsl.com>; Fri, 13 Apr 2012 10:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.307
X-Spam-Level:
X-Spam-Status: No, score=-103.307 tagged_above=-999 required=5 tests=[AWL=-0.708, 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 iEZ5Xpv1Wg2b for <apps-discuss@ietfa.amsl.com>; Fri, 13 Apr 2012 10:43:02 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3DDA821F863F for <apps-discuss@ietf.org>; Fri, 13 Apr 2012 10:43:01 -0700 (PDT)
Received: (qmail invoked by alias); 13 Apr 2012 17:42:59 -0000
Received: from p57A6DDA5.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.221.165] by mail.gmx.net (mp027) with SMTP; 13 Apr 2012 19:42:59 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+uXdwxHriuLdhtJkZXqwEPW1y8v10cTTsWG2upOt XjqN3QGZgC70Mv
Message-ID: <4F8865A1.6090703@gmx.de>
Date: Fri, 13 Apr 2012 19:42:57 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Jeni Tennison <jeni@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>
In-Reply-To: <CFA00AEC-F80B-4517-8101-A5DDA57555ED@jenitennison.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Ned Freed <ned.freed@mrochek.com>, apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, 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: Fri, 13 Apr 2012 17:43:03 -0000

On 2012-04-13 12:34, Jeni Tennison wrote:
> Hi Julian,
>
> On 13 Apr 2012, at 10:03, Julian Reschke wrote:
>> On 2012-04-13 10:30, Jeni Tennison wrote:
>>> What we see happening is that fragment identifier syntax is being specified at four levels:
>>>
>>>    1. the general pattern whereby plain name fragment identifiers are used to reference things related to the document, or named fragments within them
>>>    2. generic syntax specified for top-level types (eg Media Fragment URIs [1])
>>
>> Here be dragons.
>>
>> As far as I understand there is no inheritance of fragment identifier syntax from top-level types. The Media Fragment spec essentially has invented it; without coordinating with the IETF.
>
> I think that their assumption was actually that all the image/*, video/* and audio/* types would re-register, referencing the Media Fragment spec. Perhaps that's the best way of handling it, and nothing needs to be said specifically about fragments identifiers for top-level types.
>
> In that case, the media type specification draft would need to point out that other media types within the same top-level type may describe the use of a particular fragment identifier syntax, and that if they do then to make content negotiation between different media types work more smoothly, it's best to adopt that same fragid syntax in new media types rather than inventing a new one.

Makes sense.

Can we turn this into advice for new media type registrations to be 
included into the updated registration spec?

 > ...

Best regards, Julian