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

[Guido Moritz <[e-mail]>]

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.

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.

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

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

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

> 

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

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

> 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