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

[Zach Shelby <[e-mail]>]

On Jan 26, 2010, at 15:43 , Don Sturek wrote:

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

Exactly. CoAP's goal is to support very light-weight RESTful interactions for constrained device environments. Just as HTTP can be used for WS purposes, CoAP should also be useful. There are a bunch of shortcomings in HTTP such as the lack of multicast and subscribe/notify - by fixing those in CoAP will enable simple REST applications, which also benefits use for e.g. DPWS or other WS-* if they so wish to bind to CoAP.

Zach

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

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