IETF Logo Mail Archive

Re: [apps-discuss] +exi

Zach Shelby <zach@sensinode.com> Fri, 10 February 2012 12:28 UTC

Return-Path: <zach@sensinode.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 228A121F84FE for <apps-discuss@ietfa.amsl.com>; Fri, 10 Feb 2012 04:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.418
X-Spam-Level:
X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
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 nGBi30R87I+Z for <apps-discuss@ietfa.amsl.com>; Fri, 10 Feb 2012 04:28:42 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0624721F84FD for <apps-discuss@ietf.org>; Fri, 10 Feb 2012 04:28:41 -0800 (PST)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q1ACSXW1030479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Feb 2012 14:28:34 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <CB59D465.18D85%psaintan@cisco.com>
Date: Fri, 10 Feb 2012 14:28:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com>
References: <CB59D465.18D85%psaintan@cisco.com>
To: psaintan <psaintan@cisco.com>
X-Mailer: Apple Mail (2.1084)
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, paduffy@cisco.com, Mark Nottingham <mnot@mnot.net>, Thomas Herbst <therbst@silverspringnet.com>
Subject: Re: [apps-discuss] +exi
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, 10 Feb 2012 12:28:44 -0000

Hi,

That's right, slipped my todo list. Pointers to fairly similar documents appreciated as a template, first time writing this kind of draft.

Paul, let's keep in touch directly regarding this. 

Zach 

On Feb 10, 2012, at 4:52 AM, psaintan wrote:

> As I recall, Zach Shelby was going to write a short draft about the
> registration requirements for +exi...
> 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03981.html
> 
> I haven't seen that pop out yet.
> 
> Peter
> 
> On 2/9/12 12:54 PM, "Paul Duffy" <paduffy@cisco.com> wrote:
> 
>> We are closing this SEP2 issue in the next few days.
>> 
>> Consensus seems to be (?):
>> 
>> Content_Type: application/sep+xml
>> 
>> ... or ...
>> 
>> Content_Type: application/sep+exi
>> 
>> The first indicating POX-to-native objects processing only, the second
>> indicating EXI-to-native processing (no intermediate XML ... its not a
>> compression).  May be further extended to support variants of EXI
>> processing.
>> 
>> Going once, going twice, ....
>> 
>> We need to get this registered with IANA, etc.
>> 
>> Thanks
>> 
>> 
>> On 12/17/2011 7:11 PM, Martin Thomson wrote:
>>> On 18 December 2011 06:34, Zach Shelby<zach@sensinode.com>  wrote:
>>>> I don't find the SchemaId all that useful. First of all, you need to invoke
>>>> your EXI parser to even get at that. It is more useful to immediately look
>>>> at the content-type to decide which parser to throw a representation at. A
>>>> strictly defined foo+exi registration would tell you that nicely.
>>> ISTM that a link relation type for schema would make some sort of
>>> difference.  The JSON schema draft had a "describedby" relation type
>>> that might fit the bill (though "schema" is shorter).
>>> 
>> 
> 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

v2.23.0 | Report a Bug | By Email