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

Jeni Tennison <jeni@jenitennison.com> Fri, 20 April 2012 10:31 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 A4B4421F8731 for <apps-discuss@ietfa.amsl.com>; Fri, 20 Apr 2012 03:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level:
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 AgYKbt0aiUs2 for <apps-discuss@ietfa.amsl.com>; Fri, 20 Apr 2012 03:31:55 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 647CB21F8732 for <apps-discuss@ietf.org>; Fri, 20 Apr 2012 03:31:54 -0700 (PDT)
Received: from [82.132.248.239] (helo=[192.168.43.17]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <jeni@jenitennison.com>) id 1SLB84-0006qV-4R; Fri, 20 Apr 2012 11:31:52 +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: <01OEITCHB07U00ZGHB@mauve.mrochek.com>
Date: Fri, 20 Apr 2012 11:30:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <02811F06-0325-4A0D-AE0D-3B5AF07EAE97@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> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <01OEITCHB07U00ZGHB@mauve.mrochek.com>
To: Tony Hansen <tony@maillennium.att.com>
X-Mailer: Apple Mail (2.1257)
X-Mailcore-Auth: 9919842
X-Mailcore-Domain: 1066436
X-Mailman-Approved-At: Fri, 20 Apr 2012 08:18:14 -0700
Cc: Ned Freed <ned.freed@mrochek.com>, "www-tag@w3.org List" <www-tag@w3.org>, 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: Fri, 20 Apr 2012 10:31:56 -0000

Hi Tony,

On 20 Apr 2012, at 08:24, Ned Freed 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.
> 
> I like the overall idea but, per the above, MUST is too strong. SHOULD
> is appropriate here, and I'd capitalize the may in the second sentence.

I agree with Ned about softening the wording. The other thing that you could specifically draw out is that fragment identifiers that are classed as errors in the media type related to the suffix may be classified as OK within a specific media type.

The other (word-smithing) comment I'd make is that it's not enough for the specific media type to 'accept' fragment identifiers: they should be processed in the same way as well.

So I'd suggest something like:

    Media types using "+json" SHOULD process any fragment identifiers
    defined for "application/json" in the same way as defined for that
    media type. Specific media types MAY identify additional fragment 
    identifier considerations and MAY define processing for fragment 
    identifiers that are classed as errors for "application/json".

Cheers,

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