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

Bjoern Hoehrmann <derhoermi@gmx.net> Wed, 18 April 2012 04:47 UTC

Return-Path: <derhoermi@gmx.net>
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 D892321F8546 for <apps-discuss@ietfa.amsl.com>; Tue, 17 Apr 2012 21:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 TDc-G6biuBJR for <apps-discuss@ietfa.amsl.com>; Tue, 17 Apr 2012 21:47:14 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 49F1D21F8526 for <apps-discuss@ietf.org>; Tue, 17 Apr 2012 21:47:13 -0700 (PDT)
Received: (qmail invoked by alias); 18 Apr 2012 04:47:12 -0000
Received: from dslb-094-222-144-125.pools.arcor-ip.net (EHLO HIVE) [94.222.144.125] by mail.gmx.net (mp020) with SMTP; 18 Apr 2012 06:47:12 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX18L9eISb1MLNfeTpbv7RrbfepSkM4yT42X1Tn7ZZV 9Uku8m0btP+LRv
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Ned Freed <ned.freed@mrochek.com>
Date: Wed, 18 Apr 2012 06:47:24 +0200
Message-ID: <tghso756ijcpgn1udkugi7os5ik9rglgp8@hive.bjoern.hoehrmann.de>
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> <3kjpo79jo1mvg2dtqf19hl5i3lrrfm5eb5@hive.bjoern.hoehrmann.de> <01OEEJU1A7HY00ZUIL@mauve.mrochek.com>
In-Reply-To: <01OEEJU1A7HY00ZUIL@mauve.mrochek.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org, "www-tag@w3.org List" <www-tag@w3.org>, Jeni Tennison <jeni@jenitennison.com>
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: Wed, 18 Apr 2012 04:47:21 -0000

* Ned Freed wrote:
>> This also does not seem to
>> address a problem that we actually have, people do not register types
>> with very similar yet different "fragment identifier schemes", and if
>> they did so, that would very likely be for good reasons.
>
>Actually, if the Wikipedia page on these things can be believed, they do. For
>example, different fragment id syntaxes for "page N" with what appear to be
>idential semantics seem to exist.

Yeah, but if you use #page=13 versus #page(13) or some other variation
is likely for good reasons, like, you want to use some meta-mechanism
like XPointer that allows one but not the other. Would be nice to have
some proper statistics.

>Based on this feedback, I now have (I'm leaving the XML in this time):
>
><t>
>Media type registrations can specify how applications should interpret
>fragment identifiers <xref target="RFC3986"/> associated with the media type.
></t>
>
><t>
>Media types are encouraged to adopt fragment identifier schemes that are used
>with semantically similar media types. In particular, media types that use a
>named structured syntax with a  registered "+suffix" MUST follow whatever
>fragment identifier rules are given in the structured syntax suffix
>registration.
></t>

This seems reasonable to me, though it would seem better to turn that
into a general "+suffix types must follow +suffix rules, whatever they
are" requirement.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/