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

Ned Freed <ned.freed@mrochek.com> Fri, 13 April 2012 22:44 UTC

Return-Path: <ned.freed@mrochek.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 BD46611E8142 for <apps-discuss@ietfa.amsl.com>; Fri, 13 Apr 2012 15:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.417
X-Spam-Level:
X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 DOfZBOYbvnNQ for <apps-discuss@ietfa.amsl.com>; Fri, 13 Apr 2012 15:44:58 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 294B911E8135 for <apps-discuss@ietf.org>; Fri, 13 Apr 2012 15:44:58 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE9X6YDC68008VRD@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Apr 2012 15:44:56 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Fri, 13 Apr 2012 15:44:53 -0700 (PDT)
Message-id: <01OE9X6WVWO000ZUIL@mauve.mrochek.com>
Date: Fri, 13 Apr 2012 15:40:48 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 13 Apr 2012 16:02:14 -0400" <20120413200214.GE696@jay.w3.org>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <D73B8F43-AC66-48B9-BE26-A38A97C628B4@tzi.org> <f5bmx6ftxm2.fsf@calexico.inf.ed.ac.uk> <4F88546D.5020007@gmx.de> <f5behrrtwqc.fsf@calexico.inf.ed.ac.uk> <4F885889.5020401@gmx.de> <f5baa2ftvfy.fsf@calexico.inf.ed.ac.uk> <4F886487.3050806@gmx.de> <f5b62d3tsg2.fsf@calexico.inf.ed.ac.uk> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org>
To: Carine Bournez <carine@w3.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, "apps-discuss@ietf.org Discuss" <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: Fri, 13 Apr 2012 22:44:58 -0000

> On Fri, Apr 13, 2012 at 08:24:39PM +0200, Julian Reschke wrote:
> >>>>
> >>>> All true, but as far as I can tell, you didn't mention
> >>>> Content-Encoding in the message I replied to.
> >>>
> >>> Ah, I see the disconnect. In my original message, I said:
> >>>
> >>> "Why not call it application/senml+xml and encode it with EXI?
> >>> Doesn't that tell you everything you need?"
> >>>
> >>> I should have been more explicit -- what I meant the above to convey
> >>> was
> >>>
> >>> "Why not call it application/senml+xml and encode it with EXI?
> >>> That is, use Content-Type: application/senml+xml and
> >>> Content-Encoding: exi .
> >>> Doesn't that tell you everything you need?"
> >>>
> >>> So, reset. With that clarification, what do you think?
> >>
> >> Yes, absolutely, that works with HTTP.
> >>
> >> AFAIR, Core (<http://tools.ietf.org/wg/core/>) doesn't have
> >> Content-Encoding, though.
> >> ...
> >
> > ...with the constraint Ned mentioned in a parallel message (no
> > out-of-band information needed).

> I suppose that the registration for application/senml+xml could
> mandate use of a particular schema when encoded with EXI and exclude
> any additional schema (i.e. no schemaId allowed).

That's certainly doable from a registration standpoint - we even have
an Encoding Considerations section that could be used for this.

However, keep in mind that this approach could be a bit of a problem if
a new version of senml comes out that includes a schema change.

				Ned