Re: [6lowapp] BOF proposal: update

Hi Sam,

The plan in ZigBee Smart Energy V2 is not to rehost the current ZigBee Smart
Energy application messaging overtop the IP stack.  Work is currently
underway to extend the IEC TC57 CIM for the Smart Energy V2 use cases.  The
CIM is a static data model using UML.

The message exchange will be defined as XML (probably) or possibly ASN.1 (at
least, some standard self describing protocol).  Since we have very small
packet sizes using IEEE 802.15.4, we need to use some standard encoding
method (like tokenized XML method, which I think is out of scope of IETF)
and some efficient embedded web services delivery (which I think should be
in scope for IETF).   We also need a service discovery method which aligns
with the use of the encoding method we use (XML or ASN.1 or ??).

I agree with the statement that the 6LowAPP application protocol should be
format agnostic.  It would be good to see that various encodings are
supported and that the XML encoding/embedded web services/binary service
discovery defined by 6LowAPP could be transparently used in conjunction with
full XML (or other self describing protocol)/current web services
protocols/full XML based service discovery for those devices holding the
schema and willing to expand/compress for communication with small footprint
devices.

I think we have most of the communications layers defined to support this,
now needing the application support.

Don

-----Original Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf
Of Sam Roberts
Sent: Monday, September 28, 2009 12:29 PM
To: 6lowapp@ietf.org
Subject: Re: [6lowapp] BOF proposal: update

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?

> - 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?

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

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