Re: [6lowapp] BOF proposal: update

Zach Shelby <zach@sensinode.com> Mon, 28 September 2009 21:54 UTC

Return-Path: <zach@sensinode.com>
X-Original-To: 6lowapp@core3.amsl.com
Delivered-To: 6lowapp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5673A68F3 for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 14:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPvvy9gXKB6y for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 14:54:40 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3336A3A682E for <6lowapp@ietf.org>; Mon, 28 Sep 2009 14:54:39 -0700 (PDT)
Received: from snl-zach.local ([212.17.142.122]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n8SLtp6c026122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2009 00:55:51 +0300
Message-ID: <4AC130EA.6090101@sensinode.com>
Date: Mon, 28 Sep 2009 23:55:54 +0200
From: Zach Shelby <zach@sensinode.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Sam Roberts <vieuxtech@gmail.com>
References: <D9BF98E0-72D4-49BA-9542-3264EE96F8E8@tzi.org> <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <7b191a110909281104k10f3869bg534bbfaef0bf8322@mail.gmail.com> <17eac67c0909281228m339084c9u4e27decdd2271af8@mail.gmail.com>
In-Reply-To: <17eac67c0909281228m339084c9u4e27decdd2271af8@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] BOF proposal: update
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowapp>
List-Post: <mailto:6lowapp@ietf.org>
List-Help: <mailto:6lowapp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2009 21:54:41 -0000

Hi,

Sam Roberts wrote:
> On Mon, Sep 28, 2009 at 11:04 AM, Brian Frank <brian.tridium@gmail.com> wrote:
>> Couple of my thoughts to echo what some others have said:
>> - I believe the application protocol should be format agnostic.  I suspect
>> that it will be difficult to achieve consensus on data formats. I am not
>> sure how that might limit the scope of 6lowapp, but certainly I hope that a
>> debate on formats doesn't derail the transport protocol itself
> 
> I share the hope that format discussions won't bog things down.
> 
> Perhaps I misunderstand what you mean by "format agnostic", won't
> non-specification of such an important aspect prevent independantly
> developed implementations of the protocol from interoperating?

By format agnostic, we only mean that the protocol must have a content 
type/encoding identifier. The same philosophy is used by HTTP. Here our 
challenge is to represent that with 1-2 bytes. Once you have that, 
application developers may use any kind of content-type over this 
protocol, including e.g. text/xml, text/plain, rdf+xml, 
application/octet-stream using any content-encoding such as x-exi.

>> - I personally believe that naming should be based on URIs; however it seems
>> as this is already presumed as a requirement?
> 
> Have I missed discussion of this, or has rehosting the zigbee
> application support layer and cluster library on top of IPv6 over
> 802.15.4 already been discussed and/or discarded as a possibility?

The current indication from ZigBee/IP and Smart Energy is that they will 
use a web based approach. The ZigBee application layer is not being used 
in Smart Energy 2.0 at all, which is currently the only profile being 
developed for "ZigBee/IP". I would say this is something we should 
consider in the future (a later re-chartering) if we see there is a need 
  from the other organizations involved. For this charter the goal is to 
stick to the most urgent tasks.

> A profile supporting RESTful URI based request/response could exit at
> a zigbee endpoint.

Sure, I think you could definitely make them interact, and this would be 
an interesting draft!

Zach

> 
> Cheers,
> Sam
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.