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

From: Zach Shelby <[email-masked]>
Date: Tue, 19 Jan 2010 15:36:51 +0200

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?

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.

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

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? 

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: +358 40 7796297

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.

---

From: Jorge Amodio <[email-masked]>
Date: Tue, 19 Jan 2010 07:58:50 -0600

It would be nice if in section 8 you include some references to REST
and somewhere in the document you use "Representational state transfer
(REST)" instead of just the acronym.

My .02
Jorge

---

From: Guido Moritz <[email-masked]>
Date: Thu, 21 Jan 2010 15:45:11 +0100

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: [email-masked] [mailto:[email-masked]] 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?

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp

---

From: Zach Shelby <[email-masked]>
Date: Tue, 26 Jan 2010 12:56:21 +0200

> some conceptual solutions useful for COAP. Please find more comments below

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. 

> COAP should include same features to allow own or not prior defined data

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

> efforts to work on "two separated tracks".

Good point.

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

> provide, but it might require more efforts then just to define how to encode

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? 

> -REQ2 seems quite hard. Without knowledge about design/architecture to

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.

> 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

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Guido Moritz <[email-masked]>
Date: Tue, 26 Jan 2010 13:25:47 +0100

Find comments below inline.

> Von: Zach Shelby [mailto:[email-masked]]
> Gesendet: Dienstag, 26. Januar 2010 11:56
> An: Guido Moritz
> Cc: 6LoWAPP
> Betreff: Re: [6lowapp] draft-shelby-6lowapp-coap-00
> 
> 
> 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!

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

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

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

> 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

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 26 Jan 2010 05:43:53 -0800

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: [email-masked] [mailto:[email-masked]] 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

> some conceptual solutions useful for COAP. Please find more comments below

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. 

> COAP should include same features to allow own or not prior defined data

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

Good point.

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

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? 

> -REQ2 seems quite hard. Without knowledge about design/architecture to

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.

> 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

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.

---

From: Zach Shelby <[email-masked]>
Date: Tue, 26 Jan 2010 16:46:31 +0200

> reality and we haven't if we find CoAp now is an annex of the OASIS WS

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

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Tue, 26 Jan 2010 18:56:21 +0100

Hi Zach,
I would to give a bit regarding CoAP/HTTP mapping and notification messages from constrained devices to wider Internet and vice versa.

Basically, the issue here is that HTTP has a synchronous request-response model where a NOTIFY is an asynch event. Searching on the REST literature, there is cute way to handle asynch tasks within a synch model. Let to split the asynch operation into more synchronous requests. The first request spawns the operation, and the other requests let the client to be informed about the status of the operation.

Let to consider a client node on the internet subscribing to a server node for a data event notification (e.g. temperature crossing a threshold). The server node is in the constrained environment and a CoAP/HTTP interworking function is running between client and server.

The client node makes its subscribe request by sending a POST message to the server node.
The server node accepts the request, creates a new resource representing the event and put it in a queue.
Instead of keeping the client node waiting until the event happens, the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted and gives it a new URL that represents the new created resource.
Then the client can make GET requests to that URL until the event happens.
Once the client has 'consumed' the event it can DELETE the event resource from the server queue.

Better ways exist to accomplish the same task but hope this can help.

Regards,
Adriano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: martedì 19 gennaio 2010 14.37
To: 6LoWAPP
Subject: [6lowapp] draft-shelby-6lowapp-coap-00

Thanks,
Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Jan 2010 11:22:59 -0800 (PST)

----- Original Message ----
> From: Zach Shelby <[email-masked]>
> To: [email-masked]
> Cc: 6LoWAPP <[email-masked]>
> Sent: Tue, January 26, 2010 8:46:31 AM
> 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.

I agree that application layer multicast is better for constrained device environments as IP multicast would be too costly.

Regards,

Behcet

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 26 Jan 2010 11:42:45 -0800

Hi,

The recently approved HYBI WG will be taking on use cases very like
this.  The BOF discussed documenting the "long poll" approach (a
request that the client understands will not receive a response until
event or timeout occurs), long-body approach (not recommending) as
replacements to expensive repeated polling approaches.  That ended up
not being a required output of the WG according to its charter, but
that WG does have expertise in how clients know when to  poll or ask
for a notification and how servers know that the client knows what to
expect.

Lisa

---

From: Paul Duffy <[email-masked]>
Date: Tue, 26 Jan 2010 14:45:46 -0500

Hi Adriano,

Given the constraints of REST's messaging patterns,  the method 
described below is essentially polling on an event object.  Any concerns 
with lots of this occurring in a BW limited environment and/or battery 
consumption issues?

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Jan 2010 12:37:21 -0800 (PST)

Forwarding Guido's question to the list.

----- Forwarded Message ----
> From: Guido Moritz <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Sent: Tue, January 26, 2010 2:20:08 PM
> Subject: AW: [6lowapp] draft-shelby-6lowapp-coap-00
> 
> Please can you go more into detail why IP layer multicast is too
> expensive/more expensive than application layer multicast?
> 
> IP layer implies further efforts for group membership management and
> multicast routing. But if IP layer routing is used, it is the most energy
> efficient way for data dissemination for the overall sensor network. Indeed,
> problem is group management through routers.
> 
> In contrast, application layer multicast needs single unicast connections to
> every endpoint. This has a significant influence on energy consumption of
> the originator and even for 'routing' intermediate nodes in scenarios with
> many endpoints. However, application layer multicast requires group
> membership managements as well, but require no specific routing effort
> because only unicast messages are assumed.
> 
> Thank you for clarification in advance,
> Guido
> 
> > Auftrag von Behcet Sarikaya
> > Gesendet: Dienstag, 26. Januar 2010 20:23
> > An: Zach Shelby; [email-masked]
> > Cc: 6LoWAPP
> > > From: Zach Shelby 
> > I agree that application layer multicast is better for constrained
> > device environments as IP multicast would be too costly.
> > 
> > Regards,
> > 
> > Behcet
> > 
> > 
> >

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 26 Jan 2010 12:43:13 -0800

We should try to avoid polling.  A publish/subscribe mechanism where devices
opt in for notification and then are updated asynchronously is best.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Duffy
Sent: Tuesday, January 26, 2010 11:46 AM
To: [email-masked]
Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00

Hi Adriano,

On 1/26/2010 12:56 PM, Adriano Pezzuto (apezzuto) wrote:
> Hi Zach,
> I would to give a bit regarding CoAP/HTTP mapping and notification
messages from constrained devices to wider Internet and vice versa.
>
> Basically, the issue here is that HTTP has a synchronous request-response
model where a NOTIFY is an asynch event. Searching on the REST literature,
there is cute way to handle asynch tasks within a synch model. Let to split
the asynch operation into more synchronous requests. The first request
spawns the operation, and the other requests let the client to be informed
about the status of the operation.
>
> Let to consider a client node on the internet subscribing to a server node
for a data event notification (e.g. temperature crossing a threshold). The
server node is in the constrained environment and a CoAP/HTTP interworking
function is running between client and server.
> Instead of keeping the client node waiting until the event happens, the
server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted and gives
it a new URL that represents the new created resource.
Of Zach Shelby
> 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?
>
> 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.
>
> 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?).
>
> 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?

---

From: "Van Der Stok, Peter" <[email-masked]>
Date: Wed, 27 Jan 2010 08:53:51 +0100

Hi Zach, Adriano,

I would not be too happy about polling a sleeping device. It kind of beats the original purpose of having a subscription.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adriano Pezzuto (apezzuto)
Sent: Tuesday 26 January 2010 18:56
To: Zach Shelby
Cc: 6LoWAPP
Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00

Hi Zach,

Regards,
Adriano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: martedì 19 gennaio 2010 14.37
To: 6LoWAPP
Subject: [6lowapp] draft-shelby-6lowapp-coap-00

Thanks,
Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Zach Shelby <[email-masked]>
Date: Wed, 27 Jan 2010 10:00:24 +0200

I think there is a misunderstanding there. Adriano was describing what technique could be used on the HTTP side to realize the mapping with the CoAP subscribe/notify feature. Obviously the CoAP side would use asynchronous notifications sent by the sensor node, no problem there. When a proxy (server node below) maps that to HTTP, you need to use some kind of long pull technique between the proxy and the HTTP subscriber. Lisa gave a good pointer that the new HYBI working group is chartered to develop a long pull approach for HTTP - which we may be able to make use of.

Did I summarize that right Adriano?

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 27 Jan 2010 09:04:54 +0100

I would agree that asynchronous notifications as a default are a better model in a resource constrained environment. Polling could be used as an option when resources allow. The architecture and philosophy is similar to the one used in network management where devices send notifications at boot time (coldStart) or when an application initializes (warmStart), while a management application (typically not powered constrained) may poll periodically the devices to make sure notifications were not lost. 

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Don Sturek
> Sent: Tuesday, January 26, 2010 10:43 PM
> To: [email-masked]; [email-masked]
> We should try to avoid polling.  A publish/subscribe 
> mechanism where devices opt in for notification and then are 
> updated asynchronously is best.
> 
> Don
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Duffy
> Given the constraints of REST's messaging patterns,  the 
> method described below is essentially polling on an event 
> object.  Any concerns with lots of this occurring in a BW 
> limited environment and/or battery consumption issues?
> 
> 
> model where a NOTIFY is an asynch event. Searching on the 
> REST literature, there is cute way to handle asynch tasks 
> within a synch model. Let to split the asynch operation into 
> more synchronous requests. The first request spawns the 
> operation, and the other requests let the client to be 
> informed about the status of the operation.
> >
> > Let to consider a client node on the internet subscribing 
> to a server 
> > node
> for a data event notification (e.g. temperature crossing a 
> threshold). The server node is in the constrained environment 
> and a CoAP/HTTP interworking function is running between 
> client and server.
> >
> > The client node makes its subscribe request by sending a 
> POST message 
> > to
> the server node.
> > The server node accepts the request, creates a new resource 
> > representing
> the event and put it in a queue.
> server sends to the client (by CoAP/HTTP IWF) an HTTP 202 
> Accepted and gives it a new URL that represents the new 
> created resource.
> > Once the client has 'consumed' the event it can DELETE the event 
> > resource
> from the server queue.
> >
> 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:
> >
> 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?
> >
> 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.
> >
> > 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?).
> >
> > 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?
> >
> > Thanks,
> > Zach
> >
> >    
>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 27 Jan 2010 10:14:31 +0200

And a figure may help, this is what using a long poll would look like:

Sensor  <---------  coap --------->  Proxy <---------- http -----------> Client	 

	 CREATE subscribe /temp	   <<<	  POST subscribe /temp
			   OK			   >>> 	 	   OK (/sub1)	    
							     *  	      LONG GET /sub1
									       GET stays open....
*/temp changes*						
 		NOTIFY /temp		  >>>	 	    OK (/temp)
		           OK

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Van Der Stok, Peter" <[email-masked]>
Date: Wed, 27 Jan 2010 09:21:44 +0100

Zach,

thanks for the explanation.
I am quite happy about the shown construct, in the expectation that the notify to the proxy aggregates the accesses from/to the outside Internet, thus reducing the impact of outside requests on the low-resource network.

Greetings,

peter

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Wednesday 27 January 2010 9:15
To: Zach Shelby
Cc: Van Der Stok, Peter; 6LoWAPP
Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Wed, 27 Jan 2010 09:50:53 +0100

Thanks Zach for summarize, it's fine.
Also the long poll approach suggested by Lisa, sounds better than the expensive repeated polling approach.

Adriano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: mercoledì 27 gennaio 2010 9.15
To: Zach Shelby
Cc: 6LoWAPP
Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Robert Cragie <[email-masked]>
Date: Wed, 27 Jan 2010 08:57:49 +0000

Regarding subscribe/notify: I came across RestMS 
(http://www.restms.org/article:introduction-to-restms) a while ago and 
whilst it is not aimed at CoAP environments, I think some of the models 
are applicable.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jan 2010 11:07:04 +0100

On Wed, Jan 27, 2010 at 09:04:54AM +0100, Romascanu, Dan (Dan) wrote:

> I would agree that asynchronous notifications as a default are a
> better model in a resource constrained environment. Polling could be
> used as an option when resources allow. The architecture and
> philosophy is similar to the one used in network management where
> devices send notifications at boot time (coldStart) or when an
> application initializes (warmStart), while a management application
> (typically not powered constrained) may poll periodically the
> devices to make sure notifications were not lost.

And from network management protocol experience, we know that it is
important that data is carrying sufficient 'meta data' to be able to
detect discontinuities, to determine the precision of data and to
identify the time when a value was measured and the frequency with
which it is updated. It is also important to detect "stale"
subscriptions since pushing data to non-interested receivers is not
particularly useful. Related to this, it is often useful to filter the
data a receiver is really interested in the subscription. But there
are of course trade offs with all that related to the complexity you
get on the device - so the usual approach is to allow devices to
implement different feature sets, depending on their capabilities.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Wed, 27 Jan 2010 11:30:11 +0100

Hi Zach,
let's to see the opposite case when a CoAP node subscribes to an HTTP server placed on Internet.
Consider a CoAP device in a home application switching off some low priority appliances when the price of energy crosses a threshold. The price of energy is a realtime data provided by Energy provider on its web server.

I do not know how realistic this scenario is. Please, consider it only as an example. 

A figure may help:

Actuator  <---------  coap --------->  Proxy <---------- http -----------> Server	 

	 CREATE subscribe /price		>>>	  POST subscribe /price
			   		OK		<<<	  OK (/sub1)	    
				   			LONG GET /sub1
				   			GET stays open....
												*/energy price changes*
			NOTIFY /price		<<<	  OK (/sub1)
		      OK
*/switch off appliances*

Adriano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adriano Pezzuto (apezzuto)
Sent: mercoledì 27 gennaio 2010 9.51
To: Zach Shelby; [email-masked]
Cc: 6LoWAPP
Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00

Adriano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: mercoledì 27 gennaio 2010 9.15
To: Zach Shelby
Cc: 6LoWAPP
Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Paul Duffy <[email-masked]>
Date: Wed, 27 Jan 2010 08:48:10 -0500

Couple related points...

- the proxy is slowing creeping away from a simple COAP to HTTP 
translator.  I expect it will further creep as time progresses.

- XMPP supports a pub/sub messaging pattern as well as 
request/response.  And presence can be used to report device status.  
Please excuse as I've been ducking in and out of this conversation.  
What was the verdict re: applicability of an XMPP-like protocol in this 
space?

On 1/27/2010 3:14 AM, Zach Shelby wrote:
> Sensor<---------  coap --------->   Proxy<---------- http ----------->  Client	
>

---

From: Guido Moritz <[email-masked]>
Date: Wed, 27 Jan 2010 15:09:52 +0100

The XMPP pub/sub messaging patterns benefits from endpoint/server structure.
Each client is connected to a server with a long live TCP connection. Ifs
subscribed, the server is responsible for data dissemination to the
corresponding clients via the existing TCP connection. This seems similar to
the COAP proxy approach with a central point for event/data dissemination.
But XMPP of course is a bit more powerful because of server-to-server
communication, server clustering, ...

There is also a ad-hoc mode for XMPP without this server based on mDNS
service discovery. Clients are also connected by long lived TCP connections,
but this time directly without intermediate server. However, this ad-hoc
mode would require 'application layer multicast', which is not a proper
solution due to multiple unicast connections to the endpoints for at least
one event (see my further mail(s)).

> Auftrag von Paul Duffy
> Gesendet: Mittwoch, 27. Januar 2010 14:48
> An: [email-masked]
> > Sensor<---------  coap --------->   Proxy<---------- http -----------
> >  Client
> >
> > 							     *
LONG GET
> /sub1
GET stays
> open....
> >> I think there is a misunderstanding there. Adriano was describing
> what technique could be used on the HTTP side to realize the mapping
> with the CoAP subscribe/notify feature. Obviously the CoAP side would
> use asynchronous notifications sent by the sensor node, no problem
> there. When a proxy (server node below) maps that to HTTP, you need to
> use some kind of long pull technique between the proxy and the HTTP
> subscriber. Lisa gave a good pointer that the new HYBI working group is
> chartered to develop a long pull approach for HTTP - which we may be
> able to make use of.
> >>
> >>> I would not be too happy about polling a sleeping device. It kind
> of beats the original purpose of having a subscription.
> >>>
> >>> Peter
> >>>
> >>> Basically, the issue here is that HTTP has a synchronous request-
> response model where a NOTIFY is an asynch event. Searching on the REST
> literature, there is cute way to handle asynch tasks within a synch
> model. Let to split the asynch operation into more synchronous
> requests. The first request spawns the operation, and the other
> requests let the client to be informed about the status of the
> operation.
> >>>
> >>> Let to consider a client node on the internet subscribing to a
> server node for a data event notification (e.g. temperature crossing a
> threshold). The server node is in the constrained environment and a
> CoAP/HTTP interworking function is running between client and server.
> >>>
> representing the event and put it in a queue.
> >>> Instead of keeping the client node waiting until the event happens,
> the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted
> and gives it a new URL that represents the new created resource.
> resource from the server queue.
> >>>
> 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?
> >>>
> 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.
> >>>
> >>> 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.
> >>>
> >>>
> >>>
> >>>
> >>> The information contained in this message may be confidential and
> legally protected under applicable law. The message is intended solely
> for the addressee(s). If you are not the intended recipient, you are
> hereby notified that any use, forwarding, dissemination, or
> reproduction of this message is strictly prohibited and may be
> unlawful. If you are not the intended recipient, please contact the
> sender by return e-mail and destroy all copies of the original message.
> >>>
> >> --
> >> http://www.sensinode.com
> >> 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.
> >>
> >>
> >>
> >>

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 28 Jan 2010 18:25:04 +0200

here a pointer to the draft Lisa was referring to: 
http://www.ietf.org/id/draft-loreto-http-bidirectional-01.txt
we authors are still working on (as personal submission) and also 
continuing to discuss in the HyBi ml
even if it was not accepted as an output of the HyBi wg

a bunch of us are also trying to define a request header to determine 
the timeout for a long poll request
so to let the client notify the Server(the proxy in your scenario) the 
right timeout value it is going to wait
for an answer if the event does not happen before.

cheers
Sal