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

Bjoern Hoehrmann <derhoermi@gmx.net> Sat, 21 April 2012 22:03 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 03B9921F865B for <apps-discuss@ietfa.amsl.com>; Sat, 21 Apr 2012 15:03:31 -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 JHG7zzuRc3jz for <apps-discuss@ietfa.amsl.com>; Sat, 21 Apr 2012 15:03:18 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D088E21F856C for <apps-discuss@ietf.org>; Sat, 21 Apr 2012 15:03:17 -0700 (PDT)
Received: (qmail invoked by alias); 21 Apr 2012 22:03:15 -0000
Received: from dslb-094-222-155-205.pools.arcor-ip.net (EHLO HIVE) [94.222.155.205] by mail.gmx.net (mp001) with SMTP; 22 Apr 2012 00:03:15 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/quSlvHtXqRT6B6EkMVwGRIwJvH+RYQCCpC0A062 spPoZy8Uc4RXzJ
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: ht@inf.ed.ac.uk
Date: Sun, 22 Apr 2012 00:03:18 +0200
Message-ID: <9ua6p79fh03lm9i7f6l98jorsnu9erqqi1@hive.bjoern.hoehrmann.de>
References: <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> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <2ee3p79ijn5orc4i6m85hqfm7ta4vv55mb@hive.bjoern.hoehrmann.de> <f5bty0df7av.fsf@calexico.inf.ed.ac.uk>
In-Reply-To: <f5bty0df7av.fsf@calexico.inf.ed.ac.uk>
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: www-tag@w3.org, Tony Hansen <tony@maillennium.att.com>, apps-discuss@ietf.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: Sat, 21 Apr 2012 22:03:31 -0000

* Henry S. Thompson wrote:
>Bjoern Hoehrmann writes:
>> * Tony Hansen wrote:
>>>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.
>>
>> This says that "+json" cannot be used for JSON types where fragment
>> identifiers are of any concern since any future specification of the
>> application/json type may override such registrations in incompatible
>> ways. This seems to be missing the point of why we would have "+json"
>> to begin with.
>
>Or, it implies any update to a syntax schema registration such as
>application/json has a responsibility to its "deployed base".  Comes
>with the territory.

Saying that an inferior authority must obey a superior authority does
not imply that the superior authority is limited by choices any such
inferior authorities have made. We might find that taking such choices
into consideration is the responsible thing to do, but that is not what
the text says, and certainly not how authorities tend to operate. Look
no further than the +xml discussions where people do not find they need
to re-define +xml in a manner compatible with all existing +xml types.
-- 
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/