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

[Guido Moritz <[e-mail]>]

Find comments below inline.


> -----Ursprüngliche Nachricht-----
> Von: Zach Shelby [mailto:[e-mail]]
> Gesendet: Dienstag, 26. Januar 2010 11:56
> An: Guido Moritz
> Cc: 6LoWAPP
> Betreff: 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.

Carefully agreed. Core question: Will COAP reuse paradigms/concepts/methods
of DPWS or vice versa ('DPWS over COAP' vs. 'COAP over DPWS')? Both sounds
quite interesting! Nevertheless, DPWS defines most features (also most
required by COAP) and bases on transport layer. In a paper we currently
preparing for final submission, we also investigate on benefit of HTTP
binding for DPWS, which is only used for compatibility reasons with existing
SOAP Web services. But I will follow up if COAP is a adequate replacement
candidate for constraint SOAP binding. Sounds good!

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

Agreed.

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

For payload format WS-Eventing defines an own format (see
http://www.w3.org/Submission/WS-Eventing/#Subscribe as example). XMPP reuses
originator addresses already included in the XMPP stanza (I am not sure if
there is an additional mechanism for negotiation, might be corrected if I am
wrong). A nice feature of XMPP is that the originator address is always
stamped by the server in the message itself and must not be transmitted by
the sender to the next server (this may also have security reasons). 

Nevertheless, I would go a step further and first ask first: what about data
dissemination and transport negotiation. Is there a central point which
sends events out to all subscribes and thus the event source only has to
transmit data ones to this central point? If yes, does the subscriber
include the 'call back URL' in the subscription. If yes, how does the
subscriber discovers this central point? Or is the event source aware of
this central point and tells the subscriber in a response were to pick up
the events? Is the whole design aware of optional presence of such a central
point, like DPWS has concept for differentiating between ad-hoc mode and
managed mode and both can work in coexistence?

To sum up, before trying to find a proper payload format for endpoint and
filter negotiation, the requirements and protocol design should be clearer.
(Up to now I have no idea about such core design principals of COAP.)

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

What I wanted to say is, that there are questions which first might be
discussed first. E.g.: Do we prepare for separation of 'device/resource
(e.g. human readable URI)' address and 'transport (IP)' address like DPWS
does by including WS-Addressing? Or does COAP always derives addresses from
transport layer? Otherwise these addresses might be included in the header.
Are these information header fields? The 'call back' addresses discussed for
eventing purposes discussed above, is this a header or a payload field?
Might this be derived from transport layer or included in the layer above or
both? SOAP also separated between SOAP header and SOAP body, but with clear
definition what difference between both parts is. I hope I could make clear
what I am thinking about.
So until the design is not clear about which information are required to be
carried within the header, definition about its size should not be a core
requirement. Nevertheless, as you mentioned there is a frame size limitation
and thus there might be a requirement to fit a complete COAP frame in one
15.4 frame. But not the definition about limitation a header size which's
content is not clear.

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

Should be made clearer that sleeping nodes are transparent to external
networks by using caching intermediates to enable sleeping states for nodes.

> 
> Zach
> 
Your welcome,
Guido
> >
> >> 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.
> 
>