Re: [6lowapp] draft-shelby-6lowapp-coap-00

["Don Sturek" <[e-mail]>]

Hi Zach,

I agree we need to keep CoAp a simple REST implementation.   Reviewing DPWS
and other OASIS protocols is fine as long as we keep CoAp simple.  

We have done our job correctly if something like DPWS over CoAp becomes a
reality and we haven't if we find CoAp now is an annex of the OASIS WS
specifications.

Don


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Zach Shelby
Sent: Tuesday, January 26, 2010 2:56 AM
To: Guido Moritz
Cc: 6LoWAPP
Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00


On Jan 21, 2010, at 16:45 , Guido Moritz wrote:

> Dear Zach,
> 
> personally I am quite familiar with DPWS (see my I-D in 6LoWAPP), but I
may
> have some more commends on this. I would like to propose to have look on
> DPWS, WS-Discovery, and SOAP-over-UDP specs at OASIS. They might point to
> some conceptual solutions useful for COAP. Please find more comments below
> in the text.
> 

Yes, I do agree with this approach. We would be happy to explore that in the
text of http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt. 

In my opinion a goal of this new WG should be to cooperate with OASIS to
explore how a future extension to the DPWS paradigm (DPWS for CoAP?) could
make use of CoAP in these environments. CoAP should only provide the basic
protocol mechanism... just as DPWS makes use of HTTP and SOAP-over-UDP
today. 

> Regards,
> Guido
> 
>> -----Ursprüngliche Nachricht-----
>> Von: [e-mail] [mailto:[e-mail]] Im
>> Auftrag von Zach Shelby
>> Gesendet: Dienstag, 19. Januar 2010 14:37
>> An: 6LoWAPP
>> Betreff: [6lowapp] draft-shelby-6lowapp-coap-00
>> 
>> Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-
>> shelby-6lowapp-coap-00.txt that we submitted before the holidays? We
>> would like to start some design work, so any feedback would be really
>> useful. I've identified some areas where we need input/discussion on
>> the list:
>> 
>> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how
>> to encode this and what is enough space? How should such an encoding be
>> managed, ask IANA to do that? Any pointers to a similar encoding done
>> elsewhere?
> Encoding in the COAP header might be most efficient way, especially
focusing
> parsing incoming headers/messages. But extensibility is quite important
and
> a core feature of REST. XML send via HTTP uses "magic bytes".
SOAP-over-UDP
> (XML SOAP envelopes send via UDP without HTTP header) binding
> implementations can use these magic bytes for data format identification.
> COAP should include same features to allow own or not prior defined data
> formats.
> 

Agreed. That could be done by reserving a range of codes for private use, or
by having a code that says something like "look at the magic bytes in the
payload"?

>> 
>> 2. Caching (Section 2.6). Should we go towards an in-band or an out-of-
>> band discovery approach? Personally I think an in-band approach is by
>> far the simplest, although it requires some header space when present.
> Out-of-band discovery might imply overlapping with other specs (mDNS,
> WS-Discovery,..). Thus, comprehensive in-band discovery seems a proper
> approach. Header space should not be a problem because
> methods/actions/operations of COAP are very limited. Additional
information
> to be included in the header for discovery purposes would have to be
> included for out-of-band approaches as well but would require additional
> efforts to work on "two separated tracks".

Good point.

> 
>> 
>> 3. Subscribe/Notify (Section 2.7). This is an area that definitely
>> needs discussion. The current proposal is to use a REST interface to
>> create subscriptions and which are then sent using a NOTIFY message to
>> a call-back URL. How to format the body o the subscription (URL to
>> subscribe to, URL call-back, parameters?).
> Similar features are included in DPWS by using WS-Eventing. In
> subscriptions, a client includes an endpoint for event delivery. This is a
> transport specific address including protocol and address.
> But additional features might be required for a complete eventing concept.
> This includes lease management concepts and filtering concepts (e.g. set
> limits/thresholds for a temperature value). Furthermore, a data
distribution
> model is required. WS-Eventing uses by default unicast messages to the
> clients (sinks of event). This requires one message to every subscriber.
> XMPP instead needs, due to its architecture, only one message to the
server
> which distributes data to all subscribed clients without need for multiple
> sendings of the originator.

We should look at both in more detail. We don't have a server architecture
as in XMPP, 
however there may a proxy (HTTP-CoAP mapping e.g.) that aggregates
subscriptions on behalf of nodes. Therefore the paradigm would probably be
similar to the WS-Eventing (unicast). I think the question here is, is there
an existing payload format for including the URL call-back and other needed
subscription management parameters that we could just point at? This would
need to be simple to parse with a reasonable payload size. 

> 
>> 
>> 4. Resource Discovery (Section 2.9). The proposal is to use a new
>> DISCOVER method which can be sent either unicast or multicast. The only
>> difficult part there is the format of the list of resources (URLs)
>> which would be returned in such a response. This is a little bit like
>> index.html. We had some discussions in Hiroshima that XMPP has
>> developed some ways of coding lists of URLs and that could be re-used.
>> Does someone have a pointer for us on that?
> WS-Discovery specification goes one step further and combines metadata
> exchange for devices and service descriptions. In the first step, a device
> itself is discovered which is a ensemble of "Hosted Services" (services or
> in COAP single resource). A single service itself provides also metadata
> (methods/operations of service) which can be queried. 
> The new Bluetooth Low Energy Attribute Protocol uses a similar approach to
> request either all services of a attribute server or specific attributes
of
> a service.
> To sum up, I am not sure which functionalities the discovery of COAP has
to
> provide, but it might require more efforts then just to define how to
encode
> a set of URLs.

The new charter update will help us here... It seems like defining the
format of these messages might be out of scope for the WG's first charter,
although the original idea was also to define a basic URL list (do we still
do that?). It may be enough to point at other formats or paradigms that
could use this method for discovery. If there is interest and the need to
define one at the IETF later, then we could be re-chartered for that? 

> 
>> 
> 
> Some more comments:
> -REQ2 seems quite hard. Without knowledge about design/architecture to
> define a header size.

This is from the charter, and it comes from the 6LoWPAN network architecture
and IEEE 802.15.4 frame sizes. I don't find it to be that difficult to meet,
from experience designing similar protocols.

> 
> -REQ3: Is it useful to make sleeping nodes to an application layer
> requirement? 6LoWPAN allows seamless integration into existing networks.
To
> deal with sleeping nodes always requires caching intermediates and thus
does
> not permit for ad-hoc connectivity, because external endpoints cannot be
> aware of this. Sleeping nodes should be solved on link layer, without
design
> requirements for application layer?

Locally sleeping nodes *might* very well be dealt with at the link layer in
an ad-hoc setting, but we can't make such an assumption about all
link-layers (many don't) at the IETF. REQ3 does not force sleeping nodes to
be dealt with at the application layer (so your ad-hoc case will work), but
that it *can* be used to deal with sleeping nodes (e.g. caching in an
HTTP-CoAP proxy) when appropriate. It is common that nodes sleep for long
periods of time in sensor networks, for endpoints somewhere on the Internet,
this can be dealt with by a caching intermediate. I think the requirement is
good to keep in mind what caching will sometimes be used for here.

Zach

> 
>> Thanks,
>> Zach
>> 
>> --
>> http://www.sensinode.com
>> http://zachshelby.org - My blog "On the Internet of Things"
>> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded
>> Internet"
>> Mobile: [phone]
>> 
>> 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.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 6lowapp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowapp
> 
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: [phone]

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. 




_______________________________________________
6lowapp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowapp