Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt

Carine Bournez <carine@w3.org> Mon, 02 April 2012 12:45 UTC

Return-Path: <carine@jay.w3.org>
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 56AC621F8532 for <apps-discuss@ietfa.amsl.com>; Mon, 2 Apr 2012 05:45:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
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 XITCyoqhz0oN for <apps-discuss@ietfa.amsl.com>; Mon, 2 Apr 2012 05:45:23 -0700 (PDT)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8C821F8513 for <apps-discuss@ietf.org>; Mon, 2 Apr 2012 05:45:23 -0700 (PDT)
Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from <carine@jay.w3.org>) id 1SEgdO-00072l-5P; Mon, 02 Apr 2012 08:45:22 -0400
Date: Mon, 02 Apr 2012 08:45:22 -0400
From: Carine Bournez <carine@w3.org>
To: Zach Shelby <zach@sensinode.com>
Message-ID: <20120402124522.GX16698@jay.w3.org>
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt
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, 02 Apr 2012 12:45:24 -0000

On Thu, Mar 29, 2012 at 10:52:06PM +0200, Zach Shelby wrote:
> I have posted a new version of the +exi registration draft. This version improves the Interoperability considerations of the registration requirements and further clarifies when this suffix may be used, as per the feedback on the list from Carine and others.
> 
> http://www.ietf.org/id/draft-shelby-exi-registration-01.txt

Hi,
Thanks for this new version.
I still think that this proposal is too restrictive.
As you say in section 2, you want to "use EXI as a native encoding 
(without the use of XML as an interemediate) in Schema-informed mode, 
and the base Media Type together with the SchemaID indicates to the 
protocol the Schema that was used to produce the EXI grammar as described 
in Section 4." 
I don't think this will be necessarily the case for all the foo+exi
media types that you can think of. Carsten pointed out in the earlier
discussion that your use case is for constrained devices, and I 
understand the choice of schema-informed, strict, and shortest schemaID
possible, but the original discussion about proposing a +exi suffix 
was not restricted to such use cases.

A consequence of relaxing these constraints in section 2 is that 
section 4 would have MAYs everywhere instead of those MUSTs:
<<
 Interoperability considerations:  The registration of a Media Type
      using this suffix MUST describe how to determine the XML Schema
      that is used to encode/decode a payload identified by that Media
      Type.  In particular this description defines how to determine the
      Schema used to encode a payload using the SchemaID option of the
      EXI header.  The format of the identifier to be used in the
      SchemaID, a reference to where the corresponding Schema is
      defined, and a description of how future versions of such Schemas
      will be handled MUST be included.  A default Schema version in the
      absence of the SchemaID field MAY be defined.
>>

Other points than schemaID would also need to be mentioned (I thought 
I had commented on that earlier as well).
It will be fine to specify a number of constraints when you define and
register a given foo+exi media type, but for the +exi suffix generic 
description, I'd just list interop key points without specific restrictions.


-- 
Carine Bournez -+- W3C Europe