Subject: [core] Selecting a WG document for CoAP

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 May 2010 18:51:06 +0200

The CORE WG has a milestone to select a WG document for CoAP in April:

http://datatracker.ietf.org/wg/core/charter/
...
Apr 2010	Select WG document for basis of the CoAP protocol

Of the various documents that have been contributed, draft-shelby-core-coap has significant discussion, as well as the largest number of updates (including a previous version that was still called -6lowapp-coap).

Today, another updated version of that draft was announced.  See
http://www.ietf.org/mail-archive/web/core/current/msg00138.html
for the announcement and
http://tools.ietf.org/html/draft-shelby-core-coap-01
for the draft itself.

However, as the authors say, there are still significant TODOs.

Are we in a state yet where we can say whether this is the right direction for the WG to take?
If yes, is it the right direction?  Should we adopt it as a WG document?
If you don't think we can say yet, is there a set of technical decisions you would like the authors to take with priority?

Note that once a document has become a WG document, the authors act as editors for the working group, making (and usually fleshing out the details of) any change that the WG decides it needs.
If you think we can still improve the draft, this is not an obstacle to making it a WG document.
But of course we shouldn't do that if we intend to reverse its fundamental technical direction.

In order to stay roughly in sync with our milestones, we should reach at a decision on how to go forward this week.

Gruesse, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 13 May 2010 13:24:12 +0200

Dear C. Bormann, all,

before deciding for the final direction, I've the following
observations about draft-shelby-core-coap-01

While I mostly share Zach's view of the protocol approach, and
appreciate many aspects of the proposal, there are in my opinion still
some open issues that need to be at least discussed before the current
document can be selected.

In particular, I would like to highlight the following:

a) As it is now, it is not possible to have a straightforward
translation of HTTP -> CoAP and viceversa: see
http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this
impacts the scalability of the web service model too)

b) Moreover, CoAP's implementation is not as simple as it should be.
I've investigated the implementation and some design choices (as
Options) are leading to very high program complexity (ROM) on a
MSP430-based device.

c) Finally when comparing HTTP message size with CoAP message size,
the resulting compression isn't as good as you may expect.

Example:
HTTP: GET /sensor/temp.xml HTTP/1.0 = 32 B
CoAP: 24 B with options parsing procedure requiring an added
implementation complexity

Addressing all these points potentially leads to major technical
modifications (especially point a) on the current draft, hence it is
appropriate in my opinion to discuss these points before making the
final decision.

Best regards,

Angelo P. Castellani

On Mon, May 10, 2010 at 18:51, Carsten Bormann <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 13 May 2010 08:57:09 -0600

Angelo, 

I may be reading too much in between the lines here, but I think you are raising the overall design question of should we use some form of compressed HTTP, where we preserver the semantics of HTTP but encode it differently, or should we develop a protocol with a subset of the semantics of HTTP. Perhaps I have this all wrong and you are not raising that. Could you outline some proposed solutions to your a,b,c problems below and perhaps say a bit more about what the problem is. Once I understood a bit more about how you would propose to design the protocol to mitigate these problems, I think that would help everyone make informed choices. 

Thanks, Cullen

Few more questions inline ....

> impacts the scalability of the web service model too)

On the topic of how to encode the URI. I think that needs discussion but could easily happen (and would happen) even if the COAP document was adopted as a WG item now. 

> Options) are leading to very high program complexity (ROM) on a

Can you say more - particularly about proposals to fix it?

>> In order to stay roughly in sync with our milestones, we should reach at a decision on how to go forward this week.

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 14 May 2010 10:50:22 +0200

Cullen,

thanks for the excellent understanding of my doubts.

Point (a) is exactly about the very initial design approach to define
a new realization of REST (e.g.: CRUD methods were defined instead of
standard HTTP methods) instead of a feature-limited adaptation of HTTP
itself to constrained host/network environments.

There was even discussion on defining mapping of various protocols to
CoAP without clear focus on HTTP translation.

Doubts were raised that CoAP may be following the "reinvent HTTP"
road, killing itself just as WAP did. Discussion on URI-Code/BinaryURI
(as detailed in the Transparent proxying CoAP mail) is just the tip of
the iceberg.

Draft -01 has made some valid enhancements on this topic (see HTTP
methods), however the whole document subtly imply this design
objective throughout.

In my humble opinion the direction that can be followed is: If
HTTP/TCP is not viable on CoRE, we should find a way to adapt it to
this environment.

These days I was reading the R. Fielding PhD dissertation to fully
understand why HTTP was designed in that way and what are the
important principles to be preserved in a feature-limited compressed
adaptation.

Design philosophy: CoAP should be a *stateless* HTTP-translation and
we should start by understanding how we can compress HTTP preserving
its core principles to be *stateless*, providing an *uniform*
interface to access *diverse* content organized in a *hierarchical*
fashion, it should be easily *cacheable* and *translatable*.

Being pratical:
-* uniformity leads to only request and response (no notify, no other
message types, REST should be only REQ/RES)

-* hierarchy leads to URI and BinaryURI as in the transparent proxying
discussion (no flat codes like URI-Code)

-* stateless, translation, cacheability lead to URI->BinaryURI as a
stateless mapping (avoid stateful tables)

-* stateless and diversity suggest that content should be always fully
described Content-Lenght (req), Content-Type (req) and
Content-Enconding should be supported

-* cacheable flag should be included always (not an option)

-* stateless server and stateful resources? cookies are required (lets
use binary cookies)

Other considerations, important in my opinion, on the realization of
the protocol (more technical here):

-* translation and compression should focus on the URI

  a) It should be always present and not an option

  b) Using a flag we should understand whether we are using URI or the
lossy BinaryURI encoding

  c) URI is ASCII-7 and is usually formed by chars, numbers and a few
others? I propose to investigate compressed loss-less encodings. Now I
can think at least two different encodings:
      i) Represent the / (supposed to be most frequent char in URI)
using the left-most unused bit in the octet
      ii) Represent most frequent chars (regex format: [0-9a-zA-Z/])
using 6 bit encoding, use a NULL (\x00) octet to signal that an
uncompressed char is following. Every 3 compressed chars we have 6
unused bits that can map another char (0.75 ratio in the best case,
other cases to be evaluated).
        Maybe some predefined vocabularies can be agreed, and the used
vocabulary chosen in a preceding field (vocabulary 2 example:
[a-zA-Z%+._/\|=&?-])

-* option translation issues (addressing complex implementation),
general rule avoid variable length options (harder to handle):

 a) Messages with Payload should always carry Content-Length and
Content-Type before the payload

 b) Define which are the well-known request and response options we
want to support, without merging them (it seems not a good choice
because many are response specific only, and many other request
specific only).
     Well-known options present in the message should be represented
in a binary bitmask (like in 6LoWPAN HC) and carried in-line
(fixed-length is an important requirement, however variable length can
be handled if cannot be avoided)
     When similar options are available may be beneficial to prefer
the simplest and easiest to compress (fixed-length).
     Example: Last-Modified should be preferred to Etag, (1) it can be
represented as an unsigned integer, (2) with a binary flag
representing "Now" its insertion can be delegated to the HTTP
translating entity, (3) supports conditional GET.

 c) Other options compressed with the URI style encoding (better
vocabulary here is [a-zA-Z%+._/\|=&?-])

I'm quite confident that the final compression ratio is good and, if
properly investigated, it should retain the ability to do CoAP->HTTP
translation too (Host option required).

Moreover using CoAP realized like this leads to an easier
straightforward C implementation, mainly thanks to many specific
details especially bitmasks, fixed-length options, bitwise operations.

I hope I was able to give an idea of my thinking on these issues. A
more exhaustive and detailed list of the issues is not easy to provide
by e-mail, but I will be happy to draft a document with more details
if this is considered as an useful contribution to this discussion.

Best,
Angelo

---

From: Zach Shelby <[email-masked]>
Date: Fri, 14 May 2010 14:06:11 +0300

Hi Angelo,

> document can be selected.

Of course there are plenty of open issues. Remember that working group documents still undertake as much change and improvement as the WG wants, so by no means is coap-01 set in stone. I would expect at least 5-10 more revisions still along the way.  Already several of your ideas have been integrated into coap-01, and several more are under consideration, so it is coming along. Patience ;-) 

> impacts the scalability of the web service model too)

In coap-01 the Method names are now identical to HTTP methods. The Req/Res interaction is a direct translation. The URI hierarchy is compatible, and the URI binary code format we are still working on obviously. The only thing that takes some state to translate is Subscribe/Notify. But note, Subscribe/Notify takes some state no matter how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions.  

> Options) are leading to very high program complexity (ROM) on a

This we can definitely improve, and already made several optimizations from -00 to -01. Here I need some very concrete proposals though. Also remember that many things are optional, for example subscribe/notify is not required if you don't need it. 

> implementation complexity

Right, that is not how it will work in practice. Working with a real HTTP server that HTTP header will be more complex, and on the CoAP side you would chose shorter URLs. The biggest improvement possible here is from using binary coded URLs of course. We need to look at a wider range of interactions and real HTTP headers as well to check that we are efficient enough.  

> appropriate in my opinion to discuss these points before making the

I am not sure what else you have in mind for a). If we just forget about Subscribe/Notify then you are good to go. But then you are also not fulfilling the charter or the industry needs in that respect. 

Thanks,
Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 14 May 2010 14:14:07 +0200

Zach,

thanks for the comments, but please refer to my most recent e-mail for
a more specific list of technical issues I'm pointing to.

I want to do only a little integration to what I've written there.

In my very personal opinion, to maximize adherence with the REST model
and minimize implementation effort SUBSCRIBE and NOTIFY should be
mapped to methods (as discussed many times together...).

Uniform interface principle (Fielding PhD dissertation Section 5.1.5,
"The central feature that distinguishes the REST architectural style
[...]") states that to simplify the software architecture, resource
interfaces/interfaces should be as general as possible.

I agree with this principle in this specific case, mainly because
handling a special message type for notify leads node software design
to a more complex architecture.

The reason is that this new message type requires special handling and
introduces a complexity in the software modularization.

Best,
Angelo

---

From: Robert Quattlebaum <[email-masked]>
Date: Fri, 14 May 2010 13:23:27 -0700

Pardon if my reasoning seems a bit scattered, I have a lot of thoughts on the subject but not a lot of time to write this email.

It was my hope that CoAP might be the protocol to which, if devices conformed, I (as a consumer) would be able to know that they would be able to interoperate—perhaps not without configuration, but at least after such manual configuration they would be able to communicate with each other without a third device translating things. Things like light switches, motion sensors, moisture detectors, appliances, thermostats, etc. I was imagining something akin to a modernized, push version of SNMP; at least in spirit. (See <http://www.ietf.org/mail-archive/web/core/current/msg00119.html> for a better example)

My concern is that HTTP is a clearly client-server based protocol, with a very clear delineation between the clients and the servers. With CoAP, the cases where there is such a clear server/client delineation is likely going to be much less common than cases where everyone is a peer. Thus it seems reasonable to deviate (where appropriate) from the HTTP model—even in cases where there is no direct HTTP analogue. As such, I think having a SUBSCRIBE or PAIR method makes sense.

All of these devices are stateful to some degree, but there are two types of state: volatile (runtime) state, and non-volatile (configuration) state. I think that the subscriptions/pairings should be a non-volatile state. e.g.: no expirations. But I digress...

Taking a step back, what is the compelling use case for a strict mapping between HTTP and CoAP? I think HTTP might be useful as a model, but I haven't really understood why we should make mapping between the two a design consideration.

(As a related side observation, I think what would help is if we developed some specific use cases for how CoAP is envisioned to be used)

>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html

__________________
Robert Quattlebaum
Jabber: [email-masked]
eMail:  [email-masked]
www:    http://www.deepdarc.com/

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 14 May 2010 13:33:20 -0700

Hi Robert,

Here are, I think, the assumptions with CoRE:

1)       For constrained devices, we would like to re-use the web services
application design paradigm from the wider internet.  This would use HTTP

2)       However, we would like to avoid burdening the constrained devices
with many of the services that drive larger code size and complexity.

3)       We would like to deploy CoRE using UDP to avoid overhead and
complexity with TCP along with the issues around congestion control with TCP
in mesh wireless networks.

4)      We would like to re-use any security and other services applicable
to web services.

The better we can envision a mapping between CoRE and HTTP, the easier it
will be to enable development on the wider internet to include devices with
far less capabilities than are currently supported today.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Quattlebaum
Sent: Friday, May 14, 2010 1:23 PM
To: Angelo P. Castellani
Cc: core
Subject: Re: [core] Selecting a WG document for CoAP

Pardon if my reasoning seems a bit scattered, I have a lot of thoughts on
the subject but not a lot of time to write this email.

It was my hope that CoAP might be the protocol to which, if devices
conformed, I (as a consumer) would be able to know that they would be able
to interoperate-perhaps not without configuration, but at least after such
manual configuration they would be able to communicate with each other
without a third device translating things. Things like light switches,
motion sensors, moisture detectors, appliances, thermostats, etc. I was
imagining something akin to a modernized, push version of SNMP; at least in
spirit. (See
<http://www.ietf.org/mail-archive/web/core/current/msg00119.html> for a
better example)

My concern is that HTTP is a clearly client-server based protocol, with a
very clear delineation between the clients and the servers. With CoAP, the
cases where there is such a clear server/client delineation is likely going
to be much less common than cases where everyone is a peer. Thus it seems
reasonable to deviate (where appropriate) from the HTTP model-even in cases
where there is no direct HTTP analogue. As such, I think having a SUBSCRIBE
or PAIR method makes sense.

All of these devices are stateful to some degree, but there are two types of
state: volatile (runtime) state, and non-volatile (configuration) state. I
think that the subscriptions/pairings should be a non-volatile state. e.g.:
no expirations. But I digress...

Taking a step back, what is the compelling use case for a strict mapping
between HTTP and CoAP? I think HTTP might be useful as a model, but I
haven't really understood why we should make mapping between the two a
design consideration.

(As a related side observation, I think what would help is if we developed
some specific use cases for how CoAP is envisioned to be used)

Being pratical:

Best,
Angelo

 

Angelo,

I may be reading too much in between the lines here, but I think you are
raising the overall design question of should we use some form of compressed
HTTP, where we preserver the semantics of HTTP but encode it differently, or
should we develop a protocol with a subset of the semantics of HTTP. Perhaps
I have this all wrong and you are not raising that. Could you outline some
proposed solutions to your a,b,c problems below and perhaps say a bit more
about what the problem is. Once I understood a bit more about how you would
propose to design the protocol to mitigate these problems, I think that
would help everyone make informed choices.

Thanks, Cullen

Dear C. Bormann, all,

On the topic of how to encode the URI. I think that needs discussion but
could easily happen (and would happen) even if the COAP document was adopted
as a WG item now.

MSP430-based device.

 

Example:

final decision.

Best regards,

Angelo P. Castellani

...

Of the various documents that have been contributed, draft-shelby-core-coap
has significant discussion, as well as the largest number of updates
(including a previous version that was still called -6lowapp-coap).

for the announcement and

for the draft itself.

Are we in a state yet where we can say whether this is the right direction
for the WG to take?

If you don't think we can say yet, is there a set of technical decisions you
would like the authors to take with priority?

Note that once a document has become a WG document, the authors act as
editors for the working group, making (and usually fleshing out the details
of) any change that the WG decides it needs.

If you think we can still improve the draft, this is not an obstacle to
making it a WG document.

But of course we shouldn't do that if we intend to reverse its fundamental
technical direction.

In order to stay roughly in sync with our milestones, we should reach at a
decision on how to go forward this week.

Gruesse, Carsten

core mailing list

[email-masked]

core mailing list

[email-masked]

 

Cullen Jennings

 

__________________

Robert Quattlebaum

Jabber:  <xmpp:[email-masked]> [email-masked]

eMail:   <mailto:[email-masked]> [email-masked]

---

From: Robert Quattlebaum <[email-masked]>
Date: Fri, 14 May 2010 14:04:43 -0700

Hello Don!

On May 14, 2010, at 1:33 PM, Don Sturek wrote:

> 1)       For constrained devices, we would like to re-use the web services application design paradigm from the wider internet.  This would use HTTP
> 2)       However, we would like to avoid burdening the constrained devices with many of the services that drive larger code size and complexity.
> 3)       We would like to deploy CoRE using UDP to avoid overhead and complexity with TCP along with the issues around congestion control with TCP in mesh wireless networks.
> 4)      We would like to re-use any security and other services applicable to web services.
>  
> The better we can envision a mapping between CoRE and HTTP, the easier it will be to enable development on the wider internet to include devices with far less capabilities than are currently supported today.

I'm not trying to be difficult, I'm just trying to grok the paradigm that is being proposed with CoAP. I'm having trouble imagining specific use cases and how this mapping would be helpful to making the wider internet include severely constrained devices. Would the border gateways also have a CoAP->HTTP proxy? If that is not what is being proposed, then it is still going to be significant work to get the wider internet to adopt CoAP... I'm thinking that they just won't, because they won't care. 

__________________
Robert Quattlebaum

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 14 May 2010 16:25:31 -0700

Hi Robert,

The original bar BOF and BOF discussed a device called "CoGII" which was a
gateway from CoAP to and from HTTP.  That feature was dropped out of the
charter for CoRE.

That said, I think the hope is that some type of obvious mapping is
supported.  If not, we have to hope CoRE takes off as a programming
interface on the wider internet else CoRE will be supporting only machine to
machine exchange.

Don

From: Robert Quattlebaum [mailto:[email-masked]] 
Sent: Friday, May 14, 2010 2:05 PM
To: [email-masked]
Cc: 'Angelo P. Castellani'; 'core'
Subject: Re: [core] Selecting a WG document for CoAP

Hello Don!

I'm not trying to be difficult, I'm just trying to grok the paradigm that is
being proposed with CoAP. I'm having trouble imagining specific use cases
and how this mapping would be helpful to making the wider internet include
severely constrained devices. Would the border gateways also have a
CoAP->HTTP proxy? If that is not what is being proposed, then it is still
going to be significant work to get the wider internet to adopt CoAP... I'm
thinking that they just won't, because they won't care. 

__________________

Robert Quattlebaum

---

From: "Charles Palmer" <[email-masked]>
Date: Sat, 15 May 2010 13:06:55 +0100

Dear all

Those interested in the subscribe/notify discussion might like to look
at the draft Smart Energy Profile 2.0 Application Protocol
Specification. It is available here:
http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp
licationProfile.aspx

It manages subscribe/notify by using POST. This seems to remove the need
for SUBSCRIBE and notify.

"Imagine a host A, which exposes a resource at http{s}://A/resource and
a second host B, which wishes to learn of changes to this resource. To
facilitate a subscription/ notification mechanism, A would expose a
resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy.
To subscribe to notifications regarding http{s}://A/resource, B would
send a POST to the address http{s}://A/sub/B containing the URI of the
resource of interest (http{s}://A/resource) and the URI of B's
notification resource (http{s}://B/ntfy). Following this subscription
step, should A wish to notify B of a change to the resource addressed at
http{s}://A/resource, A would send a POST to the address
http{s}://B/ntfy containing the URI of the resource changed
(http{s}://A/resource) and the URI of A's subscription resource
(http{s}://A/sub/B), should A wish to change its subscription. The host
B can then query the resource (or not) at its leisure."

Sleepy nodes are not allowed to subscribe, and must poll.

Regards - Charles Palmer 

-----Original Message-----
Sent: 14 May 2010 13:14
To: Zach Shelby

Zach,

Best,
Angelo

On Fri, May 14, 2010 at 13:06, Zach Shelby <[email-masked]> wrote:
> Of course there are plenty of open issues. Remember that working group
documents still undertake as much change and improvement as the WG
wants, so by no means is coap-01 set in stone. I would expect at least
5-10 more revisions still along the way.  Already several of your ideas
have been integrated into coap-01, and several more are under
consideration, so it is coming along. Patience ;-)
> In coap-01 the Method names are now identical to HTTP methods. The
Req/Res interaction is a direct translation. The URI hierarchy is
compatible, and the URI binary code format we are still working on
obviously. The only thing that takes some state to translate is
Subscribe/Notify. But note, Subscribe/Notify takes some state no matter
how you do it, even with HTTP-HTTP there is no clean and easy way to
handle subscriptions.
> This we can definitely improve, and already made several optimizations
from -00 to -01. Here I need some very concrete proposals though. Also
remember that many things are optional, for example subscribe/notify is
not required if you don't need it.
> Right, that is not how it will work in practice. Working with a real
HTTP server that HTTP header will be more complex, and on the CoAP side
you would chose shorter URLs. The biggest improvement possible here is
from using binary coded URLs of course. We need to look at a wider range
of interactions and real HTTP headers as well to check that we are
efficient enough.
> I am not sure what else you have in mind for a). If we just forget
about Subscribe/Notify then you are good to go. But then you are also
not fulfilling the charter or the industry needs in that respect.
>>> Of the various documents that have been contributed,
draft-shelby-core-coap has significant discussion, as well as the
largest number of updates (including a previous version that was still
called -6lowapp-coap).
>>> If you don't think we can say yet, is there a set of technical
decisions you would like the authors to take with priority?
>>>
>>> Note that once a document has become a WG document, the authors act
as editors for the working group, making (and usually fleshing out the
details of) any change that the WG decides it needs.
>>> In order to stay roughly in sync with our milestones, we should
reach at a decision on how to go forward this week.

--------------------------------
Onzo is a limited company number 06097997 registered in England & Wales. The    
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

This email message may contain confidential and/or privileged information, and
is intended solely for the addressee(s). If you have received this email in     
error, please notify Onzo immediately. Unauthorised copying, disclosure or 
distribution of the material in this email is forbidden.
--------------------------------

---

From: Ivan Žužak <[email-masked]>
Date: Sat, 15 May 2010 15:28:19 +0200

Hi Charles, all,

> B can then query the resource (or not) at its leisure."

Underneath all this, as you probably know, is a simple concept called
webhooks which are callbacks for HTTP, - http://webhooks.org. The
webhooks community has also been iterating this design of a HTTP-level
publish-subscribe mechanism for arbitrary content:
http://webhooks.pbworks.com/RESTful-WebHooks

Since the number of subscribers for a specific resource could
potentially be very large (thus making the notification process
costly), another thing to look at is PubSubHubBub which enables
scalable distribution of notifications by use of intermediary hubs -
http://code.google.com/p/pubsubhubbub/. In essence, PubSubHubBub is a
protocol based on webhooks, so standard HTTP methods are used.
Although currently supporting only subscribing to and notifying
ATOM/RSS content, one of the the next versions will support arbitrary
content.

Best,
Ivan

---

From: [email-masked]
Date: Mon, 17 May 2010 17:44:27 +0200

Hi,

My comments about  the subscribe/notify mechanism of Zigbee IP.

Pros:
- Derived from the webhooks concept
- If used by CORE it will be easier to map to HTTP because it uses only
CRUD verbs.
- The subscription message is extendable and could support advanced options
(delays, increment, ...)
- Only one listening port whatever the transport binding is.

Cons:
- No interoperability without  well known URIs and a well defined
subscription message format (Not sure CoAP draft is the right place to
specify this).
- XML/EXI is too complex to be the required format for the default
subscription/notification mechanism.
- The notification should not require a subsequent GET to retrieve the
content.
- Subresource subscription is redundant.

Hope this could help,
Matthieu

             "Charles Palmer"                                              
             <charles.palmer@o                                             
             nzo.com>                                                    A 
             Envoyé par :              "core" <[email-masked]>              
             core-bounces@ietf                                          cc 
             .org                                                          
                                                                     Objet 
                                       Re: [core] Selecting a WG document  
             15/05/2010 14:06          for CoAP                            

                                                                           

Dear all

Regards - Charles Palmer

-----Original Message-----

Zach,

Best,
Angelo

--------------------------------
Onzo is a limited company number 06097997 registered in England & Wales.
The
registered office is 6 Great Newport Street, London, WC2H 7JB, United
Kingdom.

This email message may contain confidential and/or privileged information,
and
is intended solely for the addressee(s). If you have received this email in

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________

---

From: "Charles Palmer" <[email-masked]>
Date: Mon, 17 May 2010 16:55:42 +0100

Hi Matthieu

I guess the decision on format of message content (e.g. XML/EXI or not) can be taken independently of the POST/webhooks vs SUBSCRIBE/notify mechanism.

Could the second POST (effectively the Notify) be extended to include the changed data, to avoid the subsequent GET?

Regards - Charles Palmer 
Onzo Limited (Project Hydra Project Manager) 
Woodthorpe, Calver Road, Baslow, Derbyshire, DE45 1RR, United Kingdom 
Ph: +44 (0)1246 582 220, Mob: +44 (0)7977 577 627 
Email: [email-masked] Skype: Acutetech

From: [email-masked] [mailto:[email-masked]] 
Sent: 17 May 2010 16:44
To: Charles Palmer
Cc: core; [email-masked]
Subject: Re: [core] Selecting a WG document for CoAP

Hi,

Pros:
- Derived from the webhooks concept
- If used by CORE it will be easier to map to HTTP because it uses only CRUD verbs.
- The subscription message is extendable and could support advanced options (delays, increment, ...) 
- Only one listening port whatever the transport binding is.

Cons:
- No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this).
- XML/EXI is too complex to be the required format for the default subscription/notification mechanism.
- The notification should not require a subsequent GET to retrieve the content.
- Subresource subscription is redundant.

Hope this could help,
Matthieu

 "Charles Palmer" <[email-masked]>

"Charles Palmer" <[email-masked]> 
Envoyé par : [email-masked] 

15/05/2010 14:06

A

"core" <[email-masked]>

cc

Objet

Re: [core] Selecting a WG document for CoAP

Dear all

Regards - Charles Palmer 

-----Original Message-----

Zach,

Best,
Angelo

---

From: [email-masked]
Date: Mon, 17 May 2010 18:45:13 +0200

>I guess the decision on format of message content (e.g. XML/EXI or not)
can be taken independently of the POST/webhooks vs SUBSCRIBE/notify
mechanism.
Of course but I have the feeling that interoperability between CoAP devices
may suffer from the webhooks approach because of a new message definition
whatever it is.
I hope I'am wrong because I still prefer webhooks.

>Could the second POST (effectively the Notify) be extended to include the
changed data, to avoid the subsequent GET?
If the notification URI is different for each subscribed resource could
the POST content be as simple as the extra GET ?

Best regards,
Matthieu

             "Charles Palmer"                                              
             <charles.palmer@o                                             
             nzo.com>                                                    A 
                                       Matthieu                            
             17/05/2010 17:55          Vial/FR/Non/Schneider@Europe        
                                                                        cc 
                                       "core" <[email-masked]>,             
                                       <[email-masked]>             
                                                                     Objet 
                                       RE: [core] Selecting a WG document  
                                       for CoAP                            

                                                                           

From: [email-masked]
[mailto:[email-masked]]
Sent: 17 May 2010 16:44
To: Charles Palmer
Cc: core; [email-masked]
Subject: Re: [core] Selecting a WG document for CoAP

Hi,

Pros:

Cons:

Hope this could help,
Matthieu

Inactive hide details for "Charles Palmer" <[email-masked]>
"Charles Palmer" <[email-masked]>

 "Charles Palmer"                                                          
 <[email-masked]>                                                 
 Envoyé par :                                                              
 [email-masked]                                                     
                                                                         A 
                                                                           
 15/05/2010 14:06                               "core" <[email-masked]>     
                                                                           
                                                                        cc 

                                                                     Objet 
                                                                           
                                                Re: [core] Selecting a WG  
                                                document for CoAP          

                                                                           

Dear all

Regards - Charles Palmer

-----Original Message-----

Zach,

Best,
Angelo

-------------------------------- Onzo is a limited company number 06097997
registered in England & Wales. The registered office is 6 Great Newport
Street, London, WC2H 7JB, United Kingdom. This email message may contain
confidential and/or privileged information, and is intended solely for the
addressee(s). If you have received this email in error, please notify Onzo
immediately. Unauthorised copying, disclosure or distribution of the
material in this email is forbidden. --------------------------------
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________

---

From: Zach Shelby <[email-masked]>
Date: Mon, 24 May 2010 16:45:58 +0300

Angelo,

Thanks for the technical comments, now I better understand what you have in mind. 

> CoAP without clear focus on HTTP translation.

HTTP translation is not the only goal of the WG. CoAP should work on its own, and CoAP may very well be proxied with many protocols. However the WG does have the requirement of defining an HTTP mapping for CoAP. We of course want to make that as painless as possible! But it doesn't mean that CoAP is HTTP. 

> methods), however the whole document subtly imply this design

Thanks. You mean GET, POST, PUT, DELETE? Sure, that makes an HTTP mapping easier to understand. Otherwise I don't find coap-01 very difficult to map to HTTP. Sure, Subscribe/Notify takes some effort, but that even can't be mapped HTTP-HTTP today as there is no standard way to do it ;-) 

> HTTP/TCP is not viable on CoRE, we should find a way to adapt it to

This was discussed at length during chartering, and we decided not to do this. HTTP/TCP is a perfectly good solution on some kinds of devices and networks, and it should be used as is there. CoRE is aiming at a special class of constrained devices and networks. 

> fashion, it should be easily *cacheable* and *translatable*.

All these things are already in our CoAP design philosophy - we are making a RESTful protocol. However we are not compressing HTTP, or just doing an HTTP translation. We are designing a RESTful protocol, which *can* be mapped to HTTP. 

Now apart from philosophy here, we are technically already very close....  

> message types, REST should be only REQ/RES)

Uniformity of what? Notify actually gives a uniform way of notifying about a resource, and conceptually it does belong as a message. It is clearly not Req/Res, please see the original list exchange started by Robert Cragie. That is where we decided to make it a message instead of a Method.

> discussion (no flat codes like URI-Code)

URI-Code is just something we started with, I am open to any scheme. Already your Sum Modulo-255 is being discussed, below it seems you are suggesting a different one.  

> stateless mapping (avoid stateful tables)

Yep, you have a point there. 

> Content-Enconding should be supported

Um, wrong. Content-Length and Content-Type are not always needed. We already discussed on the list that we can do without Content-Encoding. 

> -* stateless server and stateful resources? cookies are required (lets

I need some more convincing here that we really need cookies. What is the use case?

>   a) It should be always present and not an option

Why? If your URL is / then there is no reason to necessarily include it. 

>   b) Using a flag we should understand whether we are using URI or the

Possible, basically combining two options into one. 

> vocabulary chosen in a preceding field (vocabulary 2 example:

Sure, such an encoding could be used for all URIs, at least 7-bit ASCII encoding would be easy and already now we are leaving out the / in coap-01. This is a different issue to the Binary URI encoding.

> general rule avoid variable length options (harder to handle):

We can avoid most variable length options at cost to flexibility, sure. URIs are an exception obviously. 

> Content-Type before the payload

I am not buying that. Content-Length is only needed when packing multiple messages in a UDP payload or over a stream. In many applications you don't explicitly need the Content-Type (and mapping from HTTP you might not always get it).

> translating entity, (3) supports conditional GET.

This we can discuss. The working group is going to have to find a balance between flexibility in options and efficiency/complexity. I originally proposed (coap-req-01) having a totally fixed header with no options, but the WG clearly wanted options. You can't have your cake and eat it too.

> translation too (Host option required).

There are all really optimizations, which I am confident we will work through as a WG. I am also sure we can still simplify and improve coap! 

> if this is considered as an useful contribution to this discussion.

All discussion and input are useful here. In the future it might be easier to split this up into smaller subject threads rather than a large list of issues all at once. 

Thanks,
Zach

---

From: Zach Shelby <[email-masked]>
Date: Mon, 24 May 2010 18:49:34 +0300

(thread renamed)

We have two different paths with regard to a subscribe/notify mechanism for CoAP:

1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really does not include this concept. 
1a) Notify as a message and SUBSCRIBE as a method. This is currently used in coap-01. 
1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a good list discussion about this leading to a. In practice it doesn't make a big difference if notification is a message or method. 

2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 proposal or GENA. 

So far we have focused on 1 in the WG, and every now and again 2 comes up. At least I am not convinced that we need to suffer the drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in reality very much as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may end up anyways translating between multiple HTTP frameworks depending on the application. So instead of doing a CoAP Notify/Subscribe to Webhooks mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping. 

From what I have heard so far 1 still seems like a wise choice, although I need to look at Webhooks more deeply. In reality many applications specify their own way of doing a push interface using REST methods and specific payloads (ZigBee SE2.0 is such an example). That is just fine, and might be used instead of a specific CoAP notify/subscribe in that case. So 1 doesn't prevent the application using its own mechanism, it just provides a native way for doing push.

What do people think?

Zach

---

From: Paul Duffy <[email-masked]>
Date: Mon, 24 May 2010 22:48:06 -0400

Recommend something like #2, primarily to avoid introducing non HTTP 
method semantics, simplifying HTTP/COAP translation.gateways, etc.

> So far we have focused on 1 in the WG, and every now and again 2 comes up. At least I am not convinced that we need to suffer the drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP…

I don't understand this last para.  If CoAP sticks to the semantics of 
the current HTTP methods, would this not offer a fairly straightforward 
translation to/from HTTP?

>> "Charles Palmer"<[email-masked]>
>>
>>
>>
>>
>> "Charles Palmer"<[email-masked]>
>> "core"<[email-masked]>
>> On Fri, May 14, 2010 at 13:06, Zach Shelby<[email-masked]>  wrote:
>>      
>>> Hi Angelo,
>>>
>>>> appreciate many aspects of the proposal, there are in my opinion
>>>>          
>> still
>>      
>>>> some open issues that need to be at least discussed before the
>>>>          
>> current
>>      
>>>> On Mon, May 10, 2010 at 18:51, Carsten Bormann<[email-masked]>  wrote:
>>>>          
>>>>> The CORE WG has a milestone to select a WG document for CoAP in
>>>>>            
>> April:
>>      
>>>>> Are we in a state yet where we can say whether this is the right
>>>>>            
>> direction for the WG to take?
>>      
>>>>> If yes, is it the right direction?  Should we adopt it as a WG
>>>>>            
>> document?
>>      
>>>>> If you think we can still improve the draft, this is not an obstacle
>>>>>            
>> to making it a WG document.
>>      
>>>>> But of course we shouldn't do that if we intend to reverse its
>>>>>            
>> fundamental technical direction.
>>      
>> Onzo is a limited company number 06097997 registered in England&  Wales. The

---

From: "Charles Palmer" <[email-masked]>
Date: Tue, 25 May 2010 23:23:03 +0100

Hi folks 

It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with their subscribe/notify process.

Regards - Charles

---

From: Paul Duffy <[email-masked]>
Date: Tue, 25 May 2010 18:31:17 -0400

> It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with t…

Which is based upon existing HTTP methods and not introducing new 
methods to support subscriptions.

The intent is to make it possible to interchange HTTP and COAP as 
necessary/appropriate.

---

From: Zach Shelby <[email-masked]>
Date: Wed, 26 May 2010 00:41:14 +0200

Hi,

> It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with t…

I am not sure I understand that. I mean, ZigBee SE2.0 is defining an application specific subscribe/notify mechanism for that purpose so far for HTTP. This uses standard HTTP methods and some custom payload and REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 in that respect, so alignment is already OK there. Nothing stopping someone from using SE2.0 over CoAP.

Specifying a native susbcription/notify into CoAP is another matter. We can't adopt a solution specific to one application as that won't solve the problems of other applications nor general HTTP mapping at all (probably would make it worse). It seems that for the near future there will be a bunch of HTTP push mechanisms in use without any clear standard appearing - or am I wrong there?

Zach

---

From: Paul Duffy <[email-masked]>
Date: Tue, 25 May 2010 18:47:04 -0400

> Specifying a native susbcription/notify into CoAP is another matter. We can't adopt a solution specific to one application as that won't solve the problems of other applications nor general HTTP ma…

If COAP extends HTTP semantics with new subscription methods, it will 
not be possible to easily interchange HTTP/COAP, and translation 
gateways will become more complex to implement.

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Wed, 26 May 2010 08:17:17 +0200

Hi,
it looks to me that CoAP should use an explicit sub/notify mechanism since this is the core of the machine-to-machine interaction model.
HTTP suffers of this lack and we have seen a plethora of solutions to give an asynch taste to it. Webhooks and websockets are only the lasts of the list.
As someone has already pointed out on this list, it is theoretically possible to describe sub/notify using only CRUD methods but it looks a little bit tricky and verbose.

Now we have a chance to build from scratch a new protocol with and I think using explicit sub/notify methods with a clear and well defined semantic is the best option. It is easily understanding from every developer and will prevent to build other fanny solutions on top of the CoAP. HTTP does not have this well defined semantic and (for hundreds of other reasons also) it is not used as wide protocol for machine-to-machine communication.

CoAP - as binary protocol - and with an explicit asynch model has a chance to be a really wide protocol for M2M communication not only for constrained environments.

my 2 cents

- adriano

---

From: [email-masked]
Date: Wed, 26 May 2010 10:14:33 +0200

Hi

>It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0
work, so that it is as easy as possible for ZigBee SE to use CoRE when
ready. That suggests to me that we should align with their subscribe/notify
process.

Does it mean that all CoAP nodes shall support XML/EXI? If so I am not sure
this is the right solution.

I think we will achieve better interoperability between CoAP nodes with a
native solution. I also agree with Zach that alignement with HTTP is
already there in CoAP.
However if the native subscribe/notify is not enough extensible, many
applications will fallback to a specific subscribe. Zigbee ZCL, bacnet,
have a higher degree of control for notifications than just a simple update
(delays, values...). Maybe CORE shall provide at least guidelines to
support extended controls on notification conditions.

Regards,
Matthieu

             "Charles Palmer"                                              
             <charles.palmer@o                                             
             nzo.com>                                                    A 
             Envoyé par :              <[email-masked]>, "Zach Shelby"  
             core-bounces@ietf         <[email-masked]>                
             .org                                                       cc 
                                       core <[email-masked]>                
                                                                     Objet 
             26/05/2010 00:23          Re: [core] Subscribe/Notify for     
                                       CoAP                                

                                                                           

Hi folks

It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0
work, so that it is as easy as possible for ZigBee SE to use CoRE when
ready. That suggests to me that we should align with their subscribe/notify
process.

Regards - Charles

-----Original Message-----
Paul Duffy

On 5/24/2010 11:49 AM, Zach Shelby wrote:
> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had
a good list discussion about this leading to a. In practice it doesn't make
a big difference if notification is a message or method.
> So far we have focused on 1 in the WG, and every now and again 2 comes
up. At least I am not convinced that we need to suffer the drawbacks of
HTTP here. Anyways 2 does not help our mapping to HTTP in reality very much
as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy
may end up anyways translating between multiple HTTP frameworks depending
on the application. So instead of doing a CoAP Notify/Subscribe to Webhooks
mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA
mapping.

> > From what I have heard so far 1 still seems like a wise choice,
although I need to look at Webhooks more deeply. In reality many
applications specify their own way of doing a push interface using REST
methods and specific payloads (ZigBee SE2.0 is such an example). That is
just fine, and might be used instead of a specific CoAP notify/subscribe in
that case. So 1 doesn't prevent the application using its own mechanism, it
just provides a native way for doing push.
CRUD verbs.
content.
Kingdom.

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 26 May 2010 12:09:04 +0200

Zach,

thanks for the interesting discussion.

In my opinion in the CoAP specification process HTTP interoperability
should not be solved with a simple mapping between two different
protocols.

I think that can be more useful, reusable and interoperable to define
a standard HTTP binary-compressed *bidirectional* translation of HTTP.

After this is done we can focus on specific features (e.g. M2M
communication through subscribe/notify, etc.) not included in the HTTP
design goals.

The current focus (not the result maybe) of coap-01 is quite different
from this.

Philosophy ended :)

> Uniformity of what? Notify actually gives a uniform way of notifying about a resource, and conceptually it does belong as a message. It is clearly not Req/Res, please see the original list exchange…

I can handle it as a different message type, but in my sw components
interface specification this leads to the need to specify a completely
different interface for pushing notifications to a resource. This
introduces complexity in my constrained device software architecture.

REQ/RES only interaction was selected to provide an uniform interface.
That choice was an application of a well-known SW engineering
principle: generalizing component interfaces simplifies the overall
system architecture.

> URI-Code is just something we started with, I am open to any scheme. Already your Sum Modulo-255 is being discussed, below it seems you are suggesting a different one.

Yes, I'm proposing actually two different formats. Depending upon the
use case we can use one or the other.

> Um, wrong. Content-Length and Content-Type are not always needed. We already discussed on the list that we can do without Content-Encoding.

Right, Options bitmap fields are a very good solution for this kind of
options then..

> I need some more convincing here that we really need cookies. What is the use case?

Suppose an user has a recurrent interaction with a generic resource,
state informations about this interaction can be saved into a binary
cookie and the complexity of memorizing that is left to the user not
to the constrained device.

> Sure, such an encoding could be used for all URIs, at least 7-bit ASCII encoding would be easy and already now we are leaving out the / in coap-01. This is a different issue to the Binary URI encod…

Yes is different, both are useful and depending upon the use-case we
can choose which is better.

CoAP -> HTTP translation requires the compressed URI format to
interoperate with HTTP

HTTP -> CoAP is supposed to use the BinaryURI format because if node
resources have been added without collisions

> This we can discuss. The working group is going to have to find a balance between flexibility in options and efficiency/complexity. I originally proposed (coap-req-01) having a totally fixed header…

In my opinion split request and response options and put well-known
Options in a bitmap is a very useful feature to reduce complexity and
minimize packet size. If this is done, URI can be an Option because
the result is quite the same :)

> There are all really optimizations, which I am confident we will work through as a WG. I am also sure we can still simplify and improve coap!

Sure, I'm quite interested in providing help, if I'm able to..

> All discussion and input are useful here. In the future it might be easier to split this up into smaller subject threads rather than a large list of issues all at once.

Thanks for the useful comments, sorry I will write the issues
separately the next time..

Best,
Angelo

---

From: Robert Cragie <[email-masked]>
Date: Wed, 26 May 2010 19:09:23 +0100

Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can 
always map an asynchronous protocol to a synchronous one but, as we see 
in HTTP, it always ends up as a kludge to do it the other way round. The 
efforts which have been gone to to make HTTP quasi-asynchronous via all 
the schemes mentioned below and many more besides (all non-interoperable 
of course) is testament to how important this is for M2M communication.

So, back to Zach's list, I favor 1a) for the following reasons:

Foundation level of messages:

   1. request/response can be asynchronous or synchronous messages (as
      there is a transaction ID in there)
   2. notify is an asynchronous message

Derived methods:

I think it makes sense to add a pub/sub model as a useful mechanism for M2M.

So, looking at it the other way round: It will be entirely possible to 
translate whatever is currently built on HTTP to CoAP based on the 
above, with all its restrictions regarding synchronous and client/server 
transactions. What may be harder is to translate directly is a 
CoAP-based application to HTTP. So I guess the question is: Do we want 
to be hamstrung to synchronous client/server transactions as dictated by 
HTTP and provide a direct mapping to HTTP, then have to come up with 
similar kludges for asynchronous peer-to-peer transactions as has been 
done in numerous ways for HTTP, or do we want to define the protocol 
cleanly to start with and accept that some sort of transaction 
relaying/conversion would have to take place at a mapping node?

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Thu, 27 May 2010 20:08:34 +0200

Hi Robert,

in my personal opinion, the option 1a) brings some sort of ambiguity to CoAP specs.

My be my understatement of new CoAP specs is not so deep,  but now we have 5 methods and 3 message types: request, response and notify. Which methods are allowed with which messages types?

I suppose you have to use PUT/POST method with notify message for asynch data notification. How to make a subscribe? I suppose you would use a SUBSCRIBE method with request/response message or SUBSCRIBE with notify message? Also what about POST/DELETE methods in a notify message? They not make any sense..

I think the choice is between: option 1) -> only CRUD methods and option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both solutions.

Adriano

From: Robert Cragie [mailto:[email-masked]] 
Sent: mercoledì 26 maggio 2010 20.09
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); Zach Shelby; core
Subject: Re: [core] Subscribe/Notify for CoAP

Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can always map an asynchronous protocol to a synchronous one but, as we see in HTTP, it always ends up as a kludge to do it the other way round. The efforts which have been gone to to make HTTP quasi-asynchronous via all the schemes mentioned below and many more besides (all non-interoperable of course) is testament to how important this is for M2M communication.

1.	request/response can be asynchronous or synchronous messages (as there is a transaction ID in there)
2.	notify is an asynchronous message

Derived methods:

So, looking at it the other way round: It will be entirely possible to translate whatever is currently built on HTTP to CoAP based on the above, with all its restrictions regarding synchronous and client/server transactions. What may be harder is to translate directly is a CoAP-based application to HTTP. So I guess the question is: Do we want to be hamstrung to synchronous client/server transactions as dictated by HTTP and provide a direct mapping to HTTP, then have to come up with similar kludges for asynchronous peer-to-peer transactions as has been done in numerous ways for HTTP, or do we want to define the protocol cleanly to start with and accept that some sort of transaction relaying/conversion would have to take place at a mapping node?

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

Hi,

 
my 2 cents
 
- adriano
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Duffy (paduffy)
Sent: mercoledì 26 maggio 2010 0.47
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

	Hi,

	    

		Hi folks

		      

 

 

	Zach

		Regards - Charles

		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Duffy
		Sent: 25 May 2010 03:48
		To: Zach Shelby
		Cc: core
		Subject: Re: [core] Subscribe/Notify for CoAP

			(thread renamed)

			 

			        

		     

			What do people think?
			 
			Zach

			       

				Hi,

				Pros:
				 
				Cons:
				 
				Hope this could help,
				Matthieu

				"Charles Palmer"<[email-masked]> <mailto:[email-masked]> 

				 
				"Charles Palmer"<[email-masked]> <mailto:[email-masked]> 
				Envoyé par : [email-masked]
				15/05/2010 14:06
				 
				A
				"core"<[email-masked]> <mailto:[email-masked]> 
				cc
				Objet
				Re: [core] Selecting a WG document for CoAP
				 
				Dear all

				 

				Regards - Charles Palmer
				 
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] On Behalf Of
				Angelo P. Castellani
				Sent: 14 May 2010 13:14
				To: Zach Shelby
				Cc: core
				Subject: Re: [core] Selecting a WG document for CoAP
				 
				Zach,

				 

				 
				 
				Best,
				Angelo
				 
				On Fri, May 14, 2010 at 13:06, Zach Shelby<[email-masked]> <mailto:[email-masked]>    wrote:

					Hi Angelo,

					           

					Dear C. Bormann, all,

					              

				still

					              

				current

					              

					            

				          

					 

					            

				          

					              

					            

				          

					 
					Example:

					            

				          

					              

					            

				          

					Thanks,
					Zach

					Best regards,
					 
					Angelo P. Castellani

					On Mon, May 10, 2010 at 18:51, Carsten Bormann<[email-masked]> <mailto:[email-masked]>    wrote:

					                

				April:

					 

				          

					 

				          

					                

				document?

					                

				          

					                

				          

					                

				          

					                

				          

					                

				          

					Gruesse, Carsten

					               

					              

					--
					Zach Shelby, Chief Nerd, Sensinode Ltd.
					http://zachshelby.org  - My blog "On the Internet of Things" <http://6lowpan.net-Mybook> 
					http://6lowpan.net - My book " <http://6lowpan.net-Mybook> 6LoWPAN: The Wireless Embedded Internet"
					Mobile: +358 40 7796297

---

From: Zach Shelby <[email-masked]>
Date: Fri, 28 May 2010 11:17:54 +0200

Hi,

> I suppose you have to use PUT/POST method with notify message for asynch data notification. How to make a subscribe? I suppose you would use a SUBSCRIBE method with request/response message or SUBS…

Just for clarification, in coap-01 the Notify message has no method at all. Correct, subscription is done with a Request using the SUBSCRIBE method. Personally I have no problem with doing notify also as a method (as in coap-00) if that is what we want as a working group. Robert had a nice point that Notify does belong as a message type but functionally it works well also as a method.

Zach

> 	• request/response can be asynchronous or synchronous messages (as there is a transaction ID in there)
> 	• notify is an asynchronous message
> Derived methods:
> 
> http://www.gridmerge.com

---

From: Robert Cragie <[email-masked]>
Date: Fri, 28 May 2010 10:53:03 +0100

I think the point here is that there are two levels we are considering.

At the lowest (foundation) level, there are the transaction messages as 
described below. This provides a flexible mechanism for the application 
with regard to synchronicity and threading. This is important for the 
types of devices CoAP is being aimed at.

Above that, the methods can be used according to the architectural 
style. So in this case, it is RESTful (COnstrained Restful 
Environments), which will naturally limit the number of methods and how 
transactions occur.

The actual architecture using a combination of the methods and messages 
also depends on what is required at the application layer. Consider a 
typical client which wants to subscribe to a resource. That client 
controls the feed of data but needs a component which is capable of 
handling (possibly buffering) the data it receives through 
notifications. Is this a separate server? Or would we want to consider 
it part of an enhanced client model which is able to process feeds of 
data? These are the sort of models which have led to the myriad of 
solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) 
based around HTTP which are all essentially ingenious ways of getting 
around the limitations imposed by HTTP and how it is processed for 
anything which deviates from the classic web page access model.

I think the aim of CoAP should be clean from the word go with regard to 
supporting these more peer-to-peer transactions, where the client can 
exist on either entity and both entities can feed data to each other; 
typical in M2M applications.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:
> My be my understatement of new CoAP specs is not so deep,  but now we 
> have 5 methods and 3 message types: request, response and notify. 
> Which methods are allowed with which messages types?
>
> I suppose you have to use PUT/POST method with notify message for 
> asynch data notification. How to make a subscribe? I suppose you would 
> use a SUBSCRIBE method with request/response message or SUBSCRIBE with 
> notify message? Also what about POST/DELETE methods in a notify 
> message? They not make any sense..
>
> I think the choice is between: option 1) -> only CRUD methods and 
> option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits 
> of both solutions.
>
> Adriano
>
> *From:* Robert Cragie [mailto:[email-masked]]
> *Sent:* mercoledì 26 maggio 2010 20.09
> *To:* Adriano Pezzuto (apezzuto)
> *Cc:* Paul Duffy (paduffy); Zach Shelby; core
> *Subject:* Re: [core] Subscribe/Notify for CoAP
>
> Hi Adrian,
>
> always map an asynchronous protocol to a synchronous one but, as we 
> see in HTTP, it always ends up as a kludge to do it the other way 
> round. The efforts which have been gone to to make HTTP 
> quasi-asynchronous via all the schemes mentioned below and many more 
> besides (all non-interoperable of course) is testament to how 
> important this is for M2M communication.
>
> above, with all its restrictions regarding synchronous and 
> client/server transactions. What may be harder is to translate 
> directly is a CoAP-based application to HTTP. So I guess the question 
> is: Do we want to be hamstrung to synchronous client/server 
> transactions as dictated by HTTP and provide a direct mapping to HTTP, 
> then have to come up with similar kludges for asynchronous 
> peer-to-peer transactions as has been done in numerous ways for HTTP, 
> or do we want to define the protocol cleanly to start with and accept 
> that some sort of transaction relaying/conversion would have to take 
> place at a mapping node?
>
> Robert
>
> From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of Paul Duffy (paduffy)
>         From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of Paul Duffy
>
>         Sent: 25 May 2010 03:48
>
>         To: Zach Shelby
>
>         Cc: core
>
>             On May 17, 2010, at 6:44 PM,[email-masked]  <mailto:[email-masked]>  wrote:
>
>               
>
>               
>
>                     
>
>                      
>
>                 Hi,
>
>                   
>
>                 Envoyé par :[email-masked]  <mailto:[email-masked]>
>
>                 15/05/2010 14:06
>
>                   
>
>
>                 A
>
>
>                 From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of
>
>                 Angelo P. Castellani
>
>                 Sent: 14 May 2010 13:14
>
>                 To: Zach Shelby
>
>                 Cc: core
>
>                             [email-masked]  <mailto:[email-masked]>
>
>                         [email-masked]  <mailto:[email-masked]>
>
>                     http://6lowpan.net - My book "  <http://6lowpan.net-Mybook>6LoWPAN: The Wireless Embedded Internet"
>
>                     Mobile: +358 40 7796297
>
>                       
>
>                       
>
>                       
>
>                                 
>
>                                  
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>
> [email-masked]  <mailto:[email-masked]>
> [email-masked]  <mailto:[email-masked]>

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Fri, 28 May 2010 12:50:20 +0200

Hi Roberto,

I understand your point and personally agree on M2M is quite different from web page model. On the architectural RESTful style, the method information tells the server what to do with data kept in the URI information.

So strictly speaking, both NOTIFY and SUBSCRIBE are message types not  methods!

Adriano 

Sent: venerdì 28 maggio 2010 11.53

At the lowest (foundation) level, there are the transaction messages as described below. This provides a flexible mechanism for the application with regard to synchronicity and threading. This is important for the types of devices CoAP is being aimed at.

Above that, the methods can be used according to the architectural style. So in this case, it is RESTful (COnstrained Restful Environments), which will naturally limit the number of methods and how transactions occur.

The actual architecture using a combination of the methods and messages also depends on what is required at the application layer. Consider a typical client which wants to subscribe to a resource. That client controls the feed of data but needs a component which is capable of handling (possibly buffering) the data it receives through notifications. Is this a separate server? Or would we want to consider it part of an enhanced client model which is able to process feeds of data? These are the sort of models which have led to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) based around HTTP which are all essentially ingenious ways of getting around the limitations imposed by HTTP and how it is processed for anything which deviates from the classic web page access model.

I think the aim of CoAP should be clean from the word go with regard to supporting these more peer-to-peer transactions, where the client can exist on either entity and both entities can feed data to each other; typical in M2M applications.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

Hi Robert,

Adriano

Hi Adrian,

Derived methods:

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

Hi,

 
my 2 cents
 
- adriano
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Duffy (paduffy)
Sent: mercoledì 26 maggio 2010 0.47
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

	Hi,

	    

		Hi folks

		      

 

 

	Zach

		Regards - Charles

		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Duffy
		Sent: 25 May 2010 03:48
		To: Zach Shelby
		Cc: core
		Subject: Re: [core] Subscribe/Notify for CoAP

			(thread renamed)

			 

			        

		     

			What do people think?
			 
			Zach

			       

				Hi,

				Pros:
				 
				Cons:
				 
				Hope this could help,
				Matthieu

				 

				A
				 
				Dear all

				 

				Regards - Charles Palmer
				 
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] On Behalf Of
				Angelo P. Castellani
				Sent: 14 May 2010 13:14
				To: Zach Shelby
				Cc: core
				Subject: Re: [core] Selecting a WG document for CoAP
				 
				Zach,

				 

				 
				 
				Best,
				Angelo

				          

					Hi Angelo,

					           

					Dear C. Bormann, all,

					              

				still

					              

				current

					              

					            

				          

					 

					            

				          

					              

					            

				          

					 
					Example:

					            

				          

					              

					            

				          

					Thanks,
					Zach

					Best regards,
					 
					Angelo P. Castellani

					              

					                

				April:

					 

				          

					 

				          

					                

				document?

					                

				          

					                

				          

					                

				          

					                

				          

					                

				          

					Gruesse, Carsten

---

From: [email-masked]
Date: Fri, 28 May 2010 13:51:40 +0200

> So strictly speaking, both NOTIFY and SUBSCRIBE are message types not
methods!

SUBSCRIBE can be just an asynchronous GET on update  then I think it is a
method and NOTIFY is an asynchronous response so a message.
But if we want to have selective notifications when a resource is created,
updated or deleted then I think you're right NOTIFY and SUBSCRIBE are
messages.

Does that make sense ?

Matthieu

             "Adriano Pezzuto                                              
             (apezzuto)"                                                   
             <[email-masked]                                           A 
             om>                       <[email-masked]>       
             Envoyé par :                                               cc 
             core-bounces@ietf         core <[email-masked]>                
             .org                                                    Objet 
                                       Re: [core] Subscribe/Notify for     
                                       CoAP                                
             28/05/2010 12:50                                              

Hi Roberto,
I understand your point and personally agree on M2M is quite different from
web page model. On the architectural RESTful style, the method information
tells the server what to do with data kept in the URI information.

So strictly speaking, both NOTIFY and SUBSCRIBE are message types not
methods!

Adriano

At the lowest (foundation) level, there are the transaction messages as
described below. This provides a flexible mechanism for the application
with regard to synchronicity and threading. This is important for the types
of devices CoAP is being aimed at.

Above that, the methods can be used according to the architectural style.
So in this case, it is RESTful (COnstrained Restful Environments), which
will naturally limit the number of methods and how transactions occur.

The actual architecture using a combination of the methods and messages
also depends on what is required at the application layer. Consider a
typical client which wants to subscribe to a resource. That client controls
the feed of data but needs a component which is capable of handling
(possibly buffering) the data it receives through notifications. Is this a
separate server? Or would we want to consider it part of an enhanced client
model which is able to process feeds of data? These are the sort of models
which have led to the myriad of solutions (GENA, Webhooks, long polling,
pubsubhubbub, RESTMS etc.) based around HTTP which are all essentially
ingenious ways of getting around the limitations imposed by HTTP and how it
is processed for anything which deviates from the classic web page access
model.

I think the aim of CoAP should be clean from the word go with regard to
supporting these more peer-to-peer transactions, where the client can exist
on either entity and both entities can feed data to each other; typical in
M2M applications.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

in my personal opinion, the option 1a) brings some sort of ambiguity to
CoAP specs.

My be my understatement of new CoAP specs is not so deep,  but now we have
5 methods and 3 message types: request, response and notify. Which methods
are allowed with which messages types?
I suppose you have to use PUT/POST method with notify message for asynch
data notification. How to make a subscribe? I suppose you would use a
SUBSCRIBE method with request/response message or SUBSCRIBE with notify
message? Also what about POST/DELETE methods in a notify message? They not
make any sense..

I think the choice is between: option 1) -> only CRUD methods and option
1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both
solutions.

Adriano

Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can
always map an asynchronous protocol to a synchronous one but, as we see in
HTTP, it always ends up as a kludge to do it the other way round. The
efforts which have been gone to to make HTTP quasi-asynchronous via all the
schemes mentioned below and many more besides (all non-interoperable of
course) is testament to how important this is for M2M communication.

I think it makes sense to add a pub/sub model as a useful mechanism for
M2M.

So, looking at it the other way round: It will be entirely possible to
translate whatever is currently built on HTTP to CoAP based on the above,
with all its restrictions regarding synchronous and client/server
transactions. What may be harder is to translate directly is a CoAP-based
application to HTTP. So I guess the question is: Do we want to be hamstrung
to synchronous client/server transactions as dictated by HTTP and provide a
direct mapping to HTTP, then have to come up with similar kludges for
asynchronous peer-to-peer transactions as has been done in numerous ways
for HTTP, or do we want to define the protocol cleanly to start with and
accept that some sort of transaction relaying/conversion would have to take
place at a mapping node?

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
Hi,
it looks to me that CoAP should use an explicit sub/notify mechanism since
this is the core of the machine-to-machine interaction model.
HTTP suffers of this lack and we have seen a plethora of solutions to give
an asynch taste to it. Webhooks and websockets are only the lasts of the
list.
As someone has already pointed out on this list, it is theoretically
possible to describe sub/notify using only CRUD methods but it looks a
little bit tricky and verbose.

Now we have a chance to build from scratch a new protocol with and I think
using explicit sub/notify methods with a clear and well defined semantic is
the best option. It is easily understanding from every developer and will
prevent to build other fanny solutions on top of the CoAP. HTTP does not
have this well defined semantic and (for hundreds of other reasons also) it
is not used as wide protocol for machine-to-machine communication.

CoAP - as binary protocol - and with an explicit asynch model has a chance
to be a really wide protocol for M2M communication not only for constrained
environments.

my 2 cents

- adriano

-----Original Message-----
Paul Duffy (paduffy)

      Hi,

            Hi folks

            It occurs to me that CoRE should be keeping a close eye on
            ZigBee SE2.0 work, so that it is as easy as possible for ZigBee
            SE to use CoRE when ready. That suggests to me that we should
            align with their subscribe/notify process.

      I am not sure I understand that. I mean, ZigBee SE2.0 is defining an
      application specific subscribe/notify mechanism for that purpose so
      far for HTTP. This uses standard HTTP methods and some custom payload
      and REST interfaces. CoAP Req/Res is already totally compatible with
      SE2.0 in that respect, so alignment is already OK there. Nothing
      stopping someone from using SE2.0 over CoAP.

      Specifying a native susbcription/notify into CoAP is another matter.
      We can't adopt a solution specific to one application as that won't
      solve the problems of other applications nor general HTTP mapping at
      all (probably would make it worse). It seems that for the near future
      there will be a bunch of HTTP push mechanisms in use without any
      clear standard appearing - or am I wrong there?

      Zach

            Regards - Charles

            -----Original Message-----
            From: [email-masked] [mailto:[email-masked]] On
            Behalf Of Paul Duffy
            Sent: 25 May 2010 03:48
            To: Zach Shelby
            Cc: core
            Subject: Re: [core] Subscribe/Notify for CoAP

            Recommend something like #2, primarily to avoid introducing non
            HTTP
            method semantics, simplifying HTTP/COAP translation.gateways,
            etc.

                  (thread renamed)

                  We have two different paths with regard to a
                  subscribe/notify mechanism for CoAP:

                  1. Use specific Subscription and Notify mechanisms for
                  CoAP as HTTP really does not include this concept.
                  1a) Notify as a message and SUBSCRIBE as a method. This
                  is currently used in coap-01.
                  1b) NOTIFY and SUBSCRIBE as methods. This was used in
                  coap-00, but we had a good list discussion about this
                  leading to a. In practice it doesn't make a big
                  difference if notification is a message or method.

                  2. Use an HTTP specific framework such as Webhooks, the
                  ZigBee SE2.0 proposal or GENA.

                  So far we have focused on 1 in the WG, and every now and
                  again 2 comes up. At least I am not convinced that we
                  need to suffer the drawbacks of HTTP here. Anyways 2 does
                  not help our mapping to HTTP in reality very much as
                  there is no standard way of doing this over HTTP. Thus a
                  CoAP-HTTP proxy may end up anyways translating between
                  multiple HTTP frameworks depending on the application. So
                  instead of doing a CoAP Notify/Subscribe to Webhooks
                  mapping, you will could end up having to do a CoAP
                  Webhooks to HTTP GENA mapping.

            I don't understand this last para.  If CoAP sticks to the
            semantics of
            the current HTTP methods, would this not offer a fairly
            straightforward
            translation to/from HTTP?

                         From what I have heard so far 1 still seems like a
                        wise choice, although I need to look at Webhooks
                        more deeply. In reality many applications specify
                        their own way of doing a push interface using REST
                        methods and specific payloads (ZigBee SE2.0 is such
                        an example). That is just fine, and might be used
                        instead of a specific CoAP notify/subscribe in that
                        case. So 1 doesn't prevent the application using
                        its own mechanism, it just provides a native way
                        for doing push.

                  What do people think?

                  Zach

                  On May 17, 2010, at 6:44 PM,
                  [email-masked] wrote:

                        Hi,

                        My comments about the subscribe/notify mechanism of
                        Zigbee IP.

                        Pros:
                        - Derived from the webhooks concept
                        - If used by CORE it will be easier to map to HTTP
                        because it uses only CRUD verbs.
                        - The subscription message is extendable and could
                        support advanced options (delays, increment, ...)
                        - Only one listening port whatever the transport
                        binding is.

                        Cons:
                        - No interoperability without well known URIs and a
                        well defined subscription message format (Not sure
                        CoAP draft is the right place to specify this).
                        - XML/EXI is too complex to be the required format
                        for the default subscription/notification
                        mechanism.
                        - The notification should not require a subsequent
                        GET to retrieve the content.
                        - Subresource subscription is redundant.

                        Hope this could help,
                        Matthieu

                        "Charles Palmer"

                        A
                        "core"<[email-masked]>
                        cc
                        Objet

                        Dear all

                        Those interested in the subscribe/notify discussion
                        might like to look
                        at the draft Smart Energy Profile 2.0 Application
                        Protocol
                        Specification. It is available here:
                        http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp
                        licationProfile.aspx

                        It manages subscribe/notify by using POST. This
                        seems to remove the need
                        for SUBSCRIBE and notify.

                        "Imagine a host A, which exposes a resource at http
                        {s}://A/resource and
                        a second host B, which wishes to learn of changes
                        to this resource. To
                        facilitate a subscription/ notification mechanism,
                        A would expose a
                        resource http{s}://A/sub and B would expose a
                        resource http{s}://B/ntfy.
                        To subscribe to notifications regarding http
                        {s}://A/resource, B would
                        send a POST to the address http{s}://A/sub/B
                        containing the URI of the
                        resource of interest (http{s}://A/resource) and the
                        URI of B's
                        notification resource (http{s}://B/ntfy). Following
                        this subscription
                        step, should A wish to notify B of a change to the
                        resource addressed at
                        http{s}://A/resource, A would send a POST to the
                        address
                        http{s}://B/ntfy containing the URI of the resource
                        changed
                        (http{s}://A/resource) and the URI of A's
                        subscription resource
                        (http{s}://A/sub/B), should A wish to change its
                        subscription. The host
                        B can then query the resource (or not) at its
                        leisure."

                        Sleepy nodes are not allowed to subscribe, and must
                        poll.

                        Regards - Charles Palmer

                        -----Original Message-----
                        From: [email-masked] [
                        mailto:[email-masked]] On Behalf Of
                        Angelo P. Castellani
                        Sent: 14 May 2010 13:14
                        To: Zach Shelby
                        Cc: core
                        Subject: Re: [core] Selecting a WG document for
                        CoAP

                        Zach,

                        thanks for the comments, but please refer to my
                        most recent e-mail for
                        a more specific list of technical issues I'm
                        pointing to.

                        I want to do only a little integration to what I've
                        written there.

                        In my very personal opinion, to maximize adherence
                        with the REST model
                        and minimize implementation effort SUBSCRIBE and
                        NOTIFY should be
                        mapped to methods (as discussed many times
                        together...).

                        Uniform interface principle (Fielding PhD
                        dissertation Section 5.1.5,
                        "The central feature that distinguishes the REST
                        architectural style
                        [...]") states that to simplify the software
                        architecture, resource
                        interfaces/interfaces should be as general as
                        possible.

                        I agree with this principle in this specific case,
                        mainly because
                        handling a special message type for notify leads
                        node software design
                        to a more complex architecture.

                        The reason is that this new message type requires
                        special handling and
                        introduces a complexity in the software
                        modularization.

                        Best,
                        Angelo

                        On Fri, May 14, 2010 at 13:06, Zach Shelby
                        <[email-masked]>   wrote:

                              Hi Angelo,

                              On May 13, 2010, at 14:24 , Angelo P.
                              Castellani wrote:

                                    Dear C. Bormann, all,

                                    before deciding for the final
                                    direction, I've the following
                                    observations about
                                    draft-shelby-core-coap-01

                                    While I mostly share Zach's view of the
                                    protocol approach, and
                                    appreciate many aspects of the
                                    proposal, there are in my opinion

                        still

                                    some open issues that need to be at
                                    least discussed before the

                        current

                              Of course there are plenty of open issues.
                              Remember that working group

                        documents still undertake as much change and
                        improvement as the WG
                        wants, so by no means is coap-01 set in stone. I
                        would expect at least
                        5-10 more revisions still along the way.  Already
                        several of your ideas
                        have been integrated into coap-01, and several more
                        are under
                        consideration, so it is coming along. Patience ;-)

                                    In particular, I would like to
                                    highlight the following:

                                    a) As it is now, it is not possible to
                                    have a straightforward
                                    translation of HTTP ->   CoAP and
                                    viceversa: see
                                    http://www.ietf.org/mail-archive/web/core/current/msg00133.html
                                     (this
                                    impacts the scalability of the web
                                    service model too)

                              In coap-01 the Method names are now identical
                              to HTTP methods. The

                        Req/Res interaction is a direct translation. The
                        URI hierarchy is
                        compatible, and the URI binary code format we are
                        still working on
                        obviously. The only thing that takes some state to
                        translate is
                        Subscribe/Notify. But note, Subscribe/Notify takes
                        some state no matter
                        how you do it, even with HTTP-HTTP there is no
                        clean and easy way to
                        handle subscriptions.

                                    b) Moreover, CoAP's implementation is
                                    not as simple as it should be.
                                    I've investigated the implementation
                                    and some design choices (as
                                    Options) are leading to very high
                                    program complexity (ROM) on a
                                    MSP430-based device.

                              This we can definitely improve, and already
                              made several optimizations

                        from -00 to -01. Here I need some very concrete
                        proposals though. Also
                        remember that many things are optional, for example
                        subscribe/notify is
                        not required if you don't need it.

                                    c) Finally when comparing HTTP message
                                    size with CoAP message size,
                                    the resulting compression isn't as good
                                    as you may expect.

                                    Example:
                                    HTTP: GET /sensor/temp.xml HTTP/1.0 =
                                    32 B
                                    CoAP: 24 B with options parsing
                                    procedure requiring an added
                                    implementation complexity

                              Right, that is not how it will work in
                              practice. Working with a real

                        HTTP server that HTTP header will be more complex,
                        and on the CoAP side
                        you would chose shorter URLs. The biggest
                        improvement possible here is
                        from using binary coded URLs of course. We need to
                        look at a wider range
                        of interactions and real HTTP headers as well to
                        check that we are
                        efficient enough.

                                    Addressing all these points potentially
                                    leads to major technical
                                    modifications (especially point a) on
                                    the current draft, hence it is
                                    appropriate in my opinion to discuss
                                    these points before making the
                                    final decision.

                              I am not sure what else you have in mind for
                              a). If we just forget

                        about Subscribe/Notify then you are good to go. But
                        then you are also
                        not fulfilling the charter or the industry needs in
                        that respect.

                              Thanks,
                              Zach

                                    Best regards,

                                    Angelo P. Castellani

                                    On Mon, May 10, 2010 at 18:51, Carsten
                                    Bormann<[email-masked]>   wrote:

                                          The CORE WG has a milestone to
                                          select a WG document for CoAP in

                        April:

                                          http://datatracker.ietf.org/wg/core/charter/
                                          ...
                                          Apr 2010        Select WG
                                          document for basis of the CoAP
                                          protocol

                                          Of the various documents that
                                          have been contributed,

                        draft-shelby-core-coap has significant discussion,
                        as well as the
                        largest number of updates (including a previous
                        version that was still
                        called -6lowapp-coap).

                                          Today, another updated version of
                                          that draft was announced.  See
                                          http://www.ietf.org/mail-archive/web/core/current/msg00138.html
                                          for the announcement and
                                          http://tools.ietf.org/html/draft-shelby-core-coap-01
                                          for the draft itself.

                                          However, as the authors say,
                                          there are still significant
                                          TODOs.

                                          Are we in a state yet where we
                                          can say whether this is the right

                                          If yes, is it the right
                                          direction?  Should we adopt it as
                                          a WG

                        document?

                                          If you don't think we can say
                                          yet, is there a set of technical

                        decisions you would like the authors to take with
                        priority?

                                          Note that once a document has
                                          become a WG document, the authors
                                          act

                        as editors for the working group, making (and
                        usually fleshing out the
                        details of) any change that the WG decides it
                        needs.

                                          If you think we can still improve
                                          the draft, this is not an
                                          obstacle

                                          But of course we shouldn't do
                                          that if we intend to reverse its

                                          In order to stay roughly in sync
                                          with our milestones, we should

                                          Gruesse, Carsten

                              --
                              Zach Shelby, Chief Nerd, Sensinode Ltd.
                              http://zachshelby.org  - My blog "On the
                              Internet of Things"
                              http://6lowpan.net - My book "6LoWPAN: The
                              Wireless Embedded Internet"
                              Mobile: +358 40 7796297

                        --------------------------------
                        Onzo is a limited company number 06097997
                        registered in England&   Wales. The
                        registered office is 6 Great Newport Street,
                        London, WC2H 7JB, United Kingdom.

                        This email message may contain confidential and/or
                        privileged information, and
                        is intended solely for the addressee(s). If you
                        have received this email in
                        error, please notify Onzo immediately. Unauthorised
                        copying, disclosure or
                        distribution of the material in this email is
                        forbidden.
                        --------------------------------

                        ______________________________________________________________________
                        This email has been scanned by the MessageLabs
                        Email Security System.
                        ______________________________________________________________________

            --------------------------------
            Onzo is a limited company number 06097997 registered in
            England&  Wales. The
            registered office is 6 Great Newport Street, London, WC2H 7JB,
            United Kingdom.

            This email message may contain confidential and/or privileged
            information, and
            is intended solely for the addressee(s). If you have received
            this email in
            error, please notify Onzo immediately. Unauthorised copying,
            disclosure or
            distribution of the material in this email is forbidden.
            --------------------------------

---

From: Robert Cragie <[email-masked]>
Date: Fri, 28 May 2010 13:08:38 +0100

Hi Matthieu,

I am not sure what you mean here. Do you mean that some other client can 
subscribe to be notified whenever some method is acted upon for a 
particular resource? Can you describe the transaction model?

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 28/05/2010 12:51 PM, [email-masked] wrote:
> SUBSCRIBE can be just an asynchronous GET on update then I think it is 
> a method and NOTIFY is an asynchronous response so a message.
> But if we want to have selective notifications when a resource is 
> created, updated or deleted then I think you're right NOTIFY and 
> SUBSCRIBE are messages.
>
> Does that make sense ?
>
> Matthieu
>
> Inactive hide details for "Adriano Pezzuto (apezzuto)" 
> <[email-masked]>"Adriano Pezzuto (apezzuto)" <[email-masked]>
>
>
>
>
>                         *"Adriano Pezzuto (apezzuto)"
>                         <[email-masked]>*
> <[email-masked]>
>
> cc
> 	
> core <[email-masked]>
>
> Objet
> 	
> Re: [core] Subscribe/Notify for CoAP
>
> 	
>
>
> Hi Roberto,
> I understand your point and personally agree on M2M is quite different 
> from web page model. On the architectural RESTful style, the method 
> information tells the server what to do with data kept in the URI 
> information.
>
> *From:* Robert Cragie [mailto:[email-masked]] *
> Sent:* venerdì 28 maggio 2010 11.53*
> To:* Adriano Pezzuto (apezzuto)*
> Cc:* Paul Duffy (paduffy); Zach Shelby; core*
> Subject:* Re: [core] Subscribe/Notify for CoAP
>
> At the lowest (foundation) level, there are the transaction messages 
> as described below. This provides a flexible mechanism for the 
> application with regard to synchronicity and threading. This is 
> important for the types of devices CoAP is being aimed at.
>
> Environments), which will naturally limit the number of methods and 
> how transactions occur.
>
> The actual architecture using a combination of the methods and 
> messages also depends on what is required at the application layer. 
> Consider a typical client which wants to subscribe to a resource. That 
> client controls the feed of data but needs a component which is 
> capable of handling (possibly buffering) the data it receives through 
> I think the aim of CoAP should be clean from the word go with regard 
> to supporting these more peer-to-peer transactions, where the client 
> can exist on either entity and both entities can feed data to each 
> other; typical in M2M applications.
>
> Robert
>
> +1 415 513 0064_
> __http://www.gridmerge.com_ <http://www.gridmerge.com/>
>
> *From:* Robert Cragie [_mailto:[email-masked]] *
> Sent:* mercoledì 26 maggio 2010 20.09*
> To:* Adriano Pezzuto (apezzuto)*
> Cc:* Paul Duffy (paduffy); Zach Shelby; core*
> Subject:* Re: [core] Subscribe/Notify for CoAP
>
> Hi Adrian,
>
> +1 415 513 0064_
> __http://www.gridmerge.com_ <http://www.gridmerge.com/>
>
> it looks to me that CoAP should use an explicit sub/notify mechanism 
> since this is the core of the machine-to-machine interaction model.
> HTTP suffers of this lack and we have seen a plethora of solutions to 
> give an asynch taste to it. Webhooks and websockets are only the lasts 
> of the list.
> Now we have a chance to build from scratch a new protocol with and I 
> think using explicit sub/notify methods with a clear and well defined 
> semantic is the best option. It is easily understanding from every 
> developer and will prevent to build other fanny solutions on top of 
> the CoAP. HTTP does not have this well defined semantic and (for 
> hundreds of other reasons also) it is not used as wide protocol for 
> machine-to-machine communication.
>
> CoAP - as binary protocol - and with an explicit asynch model has a 
> chance to be a really wide protocol for M2M communication not only for 
> constrained environments.
>
> my 2 cents
>
> - adriano
>
> From: [email-masked] <mailto:[email-masked]> 
> [_mailto:[email-masked]] On Behalf Of Paul Duffy (paduffy)
>                         It occurs to me that CoRE should be keeping a
>                         close eye on ZigBee SE2.0 work, so that it is
>                         as easy as possible for ZigBee SE to use CoRE
>                         when ready. That suggests to me that we should
>             I am not sure I understand that. I mean, ZigBee SE2.0 is
>             defining an application specific subscribe/notify
>             mechanism for that purpose so far for HTTP. This uses
>             standard HTTP methods and some custom payload and REST
>             interfaces. CoAP Req/Res is already totally compatible
>             with SE2.0 in that respect, so alignment is already OK
>             there. Nothing stopping someone from using SE2.0 over CoAP.
>
>             Specifying a native susbcription/notify into CoAP is
>             another matter. We can't adopt a solution specific to one
>             application as that won't solve the problems of other
>             applications nor general HTTP mapping at all (probably
>             would make it worse). It seems that for the near future
>             there will be a bunch of HTTP push mechanisms in use
>             without any clear standard appearing - or am I wrong there?
>
>
>
>
>                         From: [email-masked]
>                         <mailto:[email-masked]>
>                         [_mailto:[email-masked]] On Behalf Of
>                         Paul Duffy
>                         Sent: 25 May 2010 03:48
>                         To: Zach Shelby
>                         Cc: core
>                                     We have two different paths with
>                                     regard to a subscribe/notify
>                                     mechanism for CoAP:
>
>                                     1. Use specific Subscription and
>                                     Notify mechanisms for CoAP as HTTP
>                                     really does not include this concept.
>                                     1a) Notify as a message and
>                                     SUBSCRIBE as a method. This is
>                                     currently used in coap-01.
>                                     1b) NOTIFY and SUBSCRIBE as
>                                     methods. This was used in coap-00,
>                                     but we had a good list discussion
>                                     about this leading to a. In
>                                     practice it doesn't make a big
>                                     2. Use an HTTP specific framework
>                                     such as Webhooks, the ZigBee SE2.0
>                                     proposal or GENA.
>
>                                     So far we have focused on 1 in the
>                                     WG, and every now and again 2
>                                     comes up. At least I am not
>                                     convinced that we need to suffer
>                                     the drawbacks of HTTP here.
>                                     Anyways 2 does not help our
>                                     mapping to HTTP in reality very
>                                     much as there is no standard way
>                                     of doing this over HTTP. Thus a
>                                     CoAP-HTTP proxy may end up anyways
>                                     translating between multiple HTTP
>                                     frameworks depending on the
>                                     application. So instead of doing a
>                                     CoAP Notify/Subscribe to Webhooks
>                                     mapping, you will could end up
>                                     having to do a CoAP Webhooks to
>                                     HTTP GENA mapping.
>
>
>
>                                                 From what I have heard
>                                                 so far 1 still seems
>                                                 like a wise choice,
>                                                 although I need to
>                                                 look at Webhooks more
>                                                 deeply. In reality
>                                                 many applications
>                                                 specify their own way
>                                                 of doing a push
>                                                 interface using REST
>                                                 methods and specific
>                                                 payloads (ZigBee SE2.0
>                                                 is such an example).
>                                                 That is just fine, and
>                                                 might be used instead
>                                                 of a specific CoAP
>                                                 notify/subscribe in
>                                                 that case. So 1
>                                                 doesn't prevent the
>                                                 application using its
>                                                 own mechanism, it just
>                                                 provides a native way
>                                     [email-masked]
>                                     <mailto:[email-masked]>
>                                     wrote:
>
>
>
>                                                 Hi,
>
>                                                 My comments about the
>                                                 subscribe/notify
>                                                 mechanism of Zigbee IP.
>
>                                                 Pros:
>                                                 - Derived from the
>                                                 webhooks concept
>                                                 - If used by CORE it
>                                                 will be easier to map
>                                                 to HTTP because it
>                                                 uses only CRUD verbs.
>                                                 - The subscription
>                                                 message is extendable
>                                                 and could support
>                                                 advanced options
>                                                 (delays, increment, ...)
>                                                 - Only one listening
>                                                 port whatever the
>                                                 transport binding is.
>
>                                                 Cons:
>                                                 - No interoperability
>                                                 without well known
>                                                 URIs and a well
>                                                 defined subscription
>                                                 message format (Not
>                                                 sure CoAP draft is the
>                                                 right place to specify
>                                                 this).
>                                                 - XML/EXI is too
>                                                 complex to be the
>                                                 required format for
>                                                 the default
>                                                 - The notification
>                                                 should not require a
>                                                 subsequent GET to
>                                                 retrieve the content.
>                                                 "Charles
>                                                 Palmer"_<[email-masked]>_
>                                                 <mailto:[email-masked]>
>
>
>
>
>                                                 "Charles
>                                                 Palmer"_<[email-masked]>_
>                                                 <mailto:[email-masked]>
>                                                 Envoyé par :
>                                                 [email-masked] <mailto:[email-masked]>
>                                                 15/05/2010 14:06
>
>                                                 A
>                                                 "core"_<[email-masked]>_ <mailto:[email-masked]>
>                                                 cc
>                                                 Objet
>                                                 Re: [core] Selecting a
>                                                 WG document for CoAP
>
>                                                 Dear all
>
>                                                 Those interested in
>                                                 the subscribe/notify
>                                                 discussion might like
>                                                 to look
>                                                 at the draft Smart
>                                                 Energy Profile 2.0
>                                                 Application Protocol
>                                                 Specification. It is
>                                                 available here:
>                                                 _http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp_
>                                                 licationProfile.aspx
>
>                                                 It manages
>                                                 subscribe/notify by
>                                                 using POST. This seems
>                                                 to remove the need
>                                                 "Imagine a host A,
>                                                 which exposes a
>                                                 resource at
>                                                 http{s}://A/resource and
>                                                 a second host B, which
>                                                 wishes to learn of
>                                                 changes to this
>                                                 resource. To
>                                                 facilitate a
>                                                 subscription/
>                                                 notification
>                                                 mechanism, A would
>                                                 expose a
>                                                 resource
>                                                 http{s}://A/sub and B
>                                                 would expose a
>                                                 To subscribe to
>                                                 notifications
>                                                 regarding
>                                                 http{s}://A/resource,
>                                                 B would
>                                                 send a POST to the
>                                                 http{s}://A/sub/B
>                                                 resource of interest
>                                                 (http{s}://A/resource)
>                                                 and the URI of B's
>                                                 notification resource
>                                                 (http{s}://B/ntfy).
>                                                 Following this
>                                                 subscription
>                                                 step, should A wish to
>                                                 notify B of a change
>                                                 to the resource
>                                                 addressed at
>                                                 http{s}://A/resource,
>                                                 A would send a POST to
>                                                 the address
>                                                 http{s}://B/ntfy
>                                                 containing the URI of
>                                                 the resource changed
>                                                 (http{s}://A/sub/B),
>                                                 should A wish to
>                                                 change its
>                                                 B can then query the
>                                                 resource (or not) at
>                                                 its leisure."
>                                                 Sleepy nodes are not
>                                                 allowed to subscribe,
>                                                 and must poll.
>                                                 From:
>                                                 [email-masked] <mailto:[email-masked]>
>                                                 [_mailto:[email-masked]]
>                                                 On Behalf Of
>                                                 Angelo P. Castellani
>                                                 Sent: 14 May 2010 13:14
>                                                 To: Zach Shelby
>                                                 Cc: core
>                                                 Subject: Re: [core]
>                                                 Selecting a WG
>                                                 document for CoAP
>
>                                                 Zach,
>
>                                                 thanks for the
>                                                 comments, but please
>                                                 refer to my most
>                                                 recent e-mail for
>                                                 a more specific list
>                                                 of technical issues
>                                                 I'm pointing to.
>
>                                                 I want to do only a
>                                                 little integration to
>                                                 what I've written there.
>
>                                                 In my very personal
>                                                 opinion, to maximize
>                                                 adherence with the
>                                                 REST model
>                                                 and minimize
>                                                 implementation effort
>                                                 SUBSCRIBE and NOTIFY
>                                                 should be
>                                                 mapped to methods (as
>                                                 discussed many times
>                                                 together...).
>
>                                                 Uniform interface
>                                                 principle (Fielding
>                                                 PhD dissertation
>                                                 Section 5.1.5,
>                                                 "The central feature
>                                                 that distinguishes the
>                                                 REST architectural style
>                                                 [...]") states that to
>                                                 simplify the software
>                                                 architecture, resource
>                                                 interfaces/interfaces
>                                                 should be as general
>                                                 as possible.
>
>                                                 I agree with this
>                                                 principle in this
>                                                 specific case, mainly
>                                                 because
>                                                 handling a special
>                                                 message type for
>                                                 notify leads node
>                                                 software design
>                                                 to a more complex
>                                                 architecture.
>
>                                                 The reason is that
>                                                 this new message type
>                                                 requires special
>                                                 handling and
>                                                 introduces a
>                                                 complexity in the
>                                                 software modularization.
>
>                                                 Best,
>                                                 Angelo
>
>                                                 On Fri, May 14, 2010
>                                                 at 13:06, Zach
>                                                 Shelby_<[email-masked]>_
>                                                 <mailto:[email-masked]>
>                                                 wrote:
>
>
>                                                             Hi Angelo,
>
>                                                             On May 13,
>                                                             2010, at
>                                                             14:24 ,
>                                                             Angelo P.
>                                                             Castellani
>                                                             wrote:
>
>
>
>                                                                         Dear
>                                                                         C.
>                                                                         Bormann,
>                                                                         all,
>
>                                                                         before
>                                                                         deciding
>                                                                         for
>                                                                         the
>                                                                         final
>                                                                         direction,
>                                                                         I've
>                                                                         the
>                                                                         following
>                                                                         observations
>                                                                         about
>                                                                         While
>                                                                         I mostly
>                                                                         share
>                                                                         Zach's
>                                                                         view
>                                                                         of
>                                                                         the
>                                                                         approach,
>                                                                         appreciate
>                                                                         many
>                                                                         aspects
>                                                                         of
>                                                                         the
>                                                                         proposal,
>                                                                         there
>                                                                         are
>                                                                         in
>                                                                         my
>                                                                         opinion
>                                                                         some
>                                                                         open
>                                                                         issues
>                                                                         that
>                                                                         need
>                                                                         to
>                                                                         be
>                                                                         at
>                                                                         least
>                                                                         discussed
>                                                                         before
>                                                                         the
>                                                                         document
>                                                                         can
>                                                                         be
>                                                                         selected.
>                                                             Of course
>                                                             there are
>                                                             plenty of
>                                                             open
>                                                             issues.
>                                                             Remember
>                                                             that
>                                                             working group
>                                                 documents still
>                                                 undertake as much
>                                                 change and improvement
>                                                 as the WG
>                                                 wants, so by no means
>                                                 is coap-01 set in
>                                                 stone. I would expect
>                                                 at least
>                                                 5-10 more revisions
>                                                 still along the way.
>                                                 Already several of
>                                                 your ideas
>                                                 have been integrated
>                                                 into coap-01, and
>                                                 several more are under
>                                                 consideration, so it
>                                                 is coming along.
>                                                 Patience ;-)
>                                                                         In
>                                                                         particular,
>                                                                         I would
>                                                                         like
>                                                                         to
>                                                                         highlight
>                                                                         the
>                                                                         following:
>                                                                         a)
>                                                                         As
>                                                                         it
>                                                                         is
>                                                                         now,
>                                                                         it
>                                                                         is
>                                                                         not
>                                                                         possible
>                                                                         to
>                                                                         have
>                                                                         a straightforward
>                                                                         translation
>                                                                         of
>                                                                         ->
>                                                                         viceversa:
>                                                                         see
>                                                                         _http://www.ietf.org/mail-archive/web/core/current/msg00133.html_
>                                                                         (this
>                                                                         impacts
>                                                                         the
>                                                                         scalability
>                                                                         of
>                                                                         the
>                                                                         web
>                                                                         service
>                                                                         model
>                                                                         too)
>
>
>                                                             In coap-01
>                                                             the Method
>                                                             names are
>                                                             now
>                                                             identical
>                                                             to HTTP
>                                                             methods. The
>
>
>                                                 Req/Res interaction is
>                                                 a direct translation.
>                                                 The URI hierarchy is
>                                                 compatible, and the
>                                                 URI binary code format
>                                                 we are still working on
>                                                 obviously. The only
>                                                 thing that takes some
>                                                 state to translate is
>                                                 Subscribe/Notify. But
>                                                 note, Subscribe/Notify
>                                                 takes some state no matter
>                                                 how you do it, even
>                                                 with HTTP-HTTP there
>                                                 is no clean and easy
>                                                 way to
>                                                 handle subscriptions.
>
>
>
>                                                                         b)
>                                                                         Moreover,
>                                                                         CoAP's
>                                                                         implementation
>                                                                         is
>                                                                         not
>                                                                         as
>                                                                         simple
>                                                                         as
>                                                                         it
>                                                                         should
>                                                                         be.
>                                                                         I've
>                                                                         investigated
>                                                                         the
>                                                                         implementation
>                                                                         and
>                                                                         some
>                                                                         design
>                                                                         choices
>                                                                         (as
>                                                                         Options)
>                                                                         are
>                                                                         leading
>                                                                         to
>                                                                         very
>                                                                         high
>                                                                         program
>                                                                         complexity
>                                                                         (ROM)
>                                                                         on
>                                                                         a
>                                                                         MSP430-based
>                                                                         device.
>
>
>                                                             This we
>                                                             can
>                                                             definitely
>                                                             improve,
>                                                             and
>                                                             already
>                                                             made
>                                                             several
>                                                             optimizations
>
>
>                                                 from -00 to -01. Here
>                                                 I need some very
>                                                 concrete proposals
>                                                 though. Also
>                                                 remember that many
>                                                 things are optional,
>                                                 for example
>                                                 subscribe/notify is
>                                                 not required if you
>                                                 don't need it.
>
>
>
>                                                                         c)
>                                                                         Finally
>                                                                         when
>                                                                         comparing
>                                                                         HTTP
>                                                                         message
>                                                                         size
>                                                                         with
>                                                                         CoAP
>                                                                         message
>                                                                         size,
>                                                                         the
>                                                                         resulting
>                                                                         compression
>                                                                         isn't
>                                                                         as
>                                                                         good
>                                                                         as
>                                                                         you
>                                                                         may
>                                                                         expect.
>
>                                                                         Example:
>                                                                         HTTP:
>                                                                         GET
>                                                                         /sensor/temp.xml
>                                                                         HTTP/1.0
>                                                                         = 32
>                                                                         B
>                                                                         CoAP:
>                                                                         24
>                                                                         B with
>                                                                         options
>                                                                         parsing
>                                                                         procedure
>                                                                         requiring
>                                                                         an
>                                                                         added
>                                                                         implementation
>                                                                         complexity
>
>
>                                                             Right,
>                                                             that is
>                                                             not how it
>                                                             will work
>                                                             in
>                                                             practice.
>                                                             Working
>                                                             with a real
>
>
>                                                 HTTP server that HTTP
>                                                 header will be more
>                                                 complex, and on the
>                                                 CoAP side
>                                                 you would chose
>                                                 shorter URLs. The
>                                                 biggest improvement
>                                                 possible here is
>                                                 from using binary
>                                                 coded URLs of course.
>                                                 We need to look at a
>                                                 wider range
>                                                 of interactions and
>                                                 real HTTP headers as
>                                                 well to check that we are
>                                                 efficient enough.
>
>
>
>                                                                         Addressing
>                                                                         all
>                                                                         these
>                                                                         points
>                                                                         potentially
>                                                                         leads
>                                                                         to
>                                                                         major
>                                                                         technical
>                                                                         modifications
>                                                                         (especially
>                                                                         point
>                                                                         a)
>                                                                         on
>                                                                         the
>                                                                         current
>                                                                         draft,
>                                                                         hence
>                                                                         it
>                                                                         is
>                                                                         appropriate
>                                                                         in
>                                                                         my
>                                                                         opinion
>                                                                         to
>                                                                         discuss
>                                                                         these
>                                                                         points
>                                                                         before
>                                                                         making
>                                                                         the
>                                                                         final
>                                                                         decision.
>
>
>                                                             I am not
>                                                             sure what
>                                                             else you
>                                                             have in
>                                                             mind for
>                                                             a). If we
>                                                             just forget
>
>
>                                                 about Subscribe/Notify
>                                                 then you are good to
>                                                 go. But then you are also
>                                                 not fulfilling the
>                                                 charter or the
>                                                 industry needs in that
>                                                 respect.
>
>
>                                                             Thanks,
>                                                             Zach
>
>
>
>                                                                         Best
>                                                                         regards,
>
>                                                                         Angelo
>                                                                         P.
>                                                                         Castellani
>
>
>                                                                         On
>                                                                         Mon,
>                                                                         May
>                                                                         10,
>                                                                         2010
>                                                                         at
>                                                                         18:51,
>                                                                         Carsten
>                                                                         Bormann_<[email-masked]>_
>                                                                         <mailto:[email-masked]>
>                                                                         wrote:
>
>
>                                                                                     The
>                                                                                     CORE
>                                                                                     WG
>                                                                                     has
>                                                                                     a milestone
>                                                                                     to
>                                                                                     select
>                                                                                     a WG
>                                                                                     document
>                                                                                     for
>                                                                                     CoAP
>                                                                                     in
>
>
>                                                 April:
>
>
>                                                                                     _http://datatracker.ietf.org/wg/core/charter/_
>                                                                                     ...
>                                                                                     Apr
>                                                                                     2010
>                                                                                     Select
>                                                                                     WG
>                                                                                     document
>                                                                                     for
>                                                                                     basis
>                                                                                     of
>                                                                                     the
>                                                                                     CoAP
>                                                                                     protocol
>
>                                                                                     Of
>                                                                                     the
>                                                                                     various
>                                                                                     documents
>                                                                                     that
>                                                                                     have
>                                                                                     been
>                                                                                     contributed,
>
>
>                                                 draft-shelby-core-coap
>                                                 has significant
>                                                 discussion, as well as the
>                                                 largest number of
>                                                 updates (including a
>                                                 previous version that
>                                                 was still
>                                                 called -6lowapp-coap).
>
>
>                                                                                     Today,
>                                                                                     another
>                                                                                     updated
>                                                                                     version
>                                                                                     of
>                                                                                     that
>                                                                                     draft
>                                                                                     was
>                                                                                     announced.
>                                                                                     See
>                                                                                     _http://www.ietf.org/mail-archive/web/core/current/msg00138.html_
>                                                                                     for
>                                                                                     the
>                                                                                     announcement
>                                                                                     and
>                                                                                     _http://tools.ietf.org/html/draft-shelby-core-coap-01_
>                                                                                     for
>                                                                                     the
>                                                                                     draft
>                                                                                     itself.
>
>                                                                                     However,
>                                                                                     as
>                                                                                     the
>                                                                                     authors
>                                                                                     say,
>                                                                                     there
>                                                                                     are
>                                                                                     still
>                                                                                     significant
>                                                                                     TODOs.
>
>                                                                                     Are
>                                                                                     we
>                                                                                     in
>                                                                                     a state
>                                                                                     yet
>                                                                                     where
>                                                                                     we
>                                                                                     can
>                                                                                     say
>                                                                                     whether
>                                                                                     this
>                                                                                     is
>                                                                                     the
>                                                                                     right
>
>
>                                                 direction for the WG
>                                                 to take?
>
>
>                                                                                     If
>                                                                                     yes,
>                                                                                     is
>                                                                                     it
>                                                                                     the
>                                                                                     right
>                                                                                     direction?
>                                                                                     Should
>                                                                                     we
>                                                                                     adopt
>                                                                                     it
>                                                                                     as
>                                                                                     a WG
>
>
>                                                 document?
>
>
>                                                                                     If
>                                                                                     you
>                                                                                     don't
>                                                                                     think
>                                                                                     we
>                                                                                     can
>                                                                                     say
>                                                                                     yet,
>                                                                                     is
>                                                                                     there
>                                                                                     a set
>                                                                                     of
>                                                                                     technical
>
>
>                                                 decisions you would
>                                                 like the authors to
>                                                 take with priority?
>
>
>                                                                                     Note
>                                                                                     that
>                                                                                     once
>                                                                                     a document
>                                                                                     has
>                                                                                     become
>                                                                                     a WG
>                                                                                     document,
>                                                                                     the
>                                                                                     authors
>                                                                                     act
>
>
>                                                 as editors for the
>                                                 working group, making
>                                                 (and usually fleshing
>                                                 out the
>                                                 details of) any change
>                                                 that the WG decides it
>                                                 needs.
>
>
>                                                                                     If
>                                                                                     you
>                                                                                     think
>                                                                                     we
>                                                                                     can
>                                                                                     still
>                                                                                     improve
>                                                                                     the
>                                                                                     draft,
>                                                                                     this
>                                                                                     is
>                                                                                     not
>                                                                                     an
>                                                                                     obstacle
>
>
>                                                 to making it a WG
>                                                 document.
>
>
>                                                                                     But
>                                                                                     of
>                                                                                     course
>                                                                                     we
>                                                                                     shouldn't
>                                                                                     do
>                                                                                     that
>                                                                                     if
>                                                                                     we
>                                                                                     intend
>                                                                                     to
>                                                                                     reverse
>                                                                                     its
>
>
>                                                 fundamental technical
>                                                 direction.
>
>
>                                                                                     In
>                                                                                     order
>                                                                                     to
>                                                                                     stay
>                                                                                     roughly
>                                                                                     in
>                                                                                     sync
>                                                                                     with
>                                                                                     our
>                                                                                     milestones,
>                                                                                     we
>                                                                                     should
>
>
>                                                 reach at a decision on
>                                                 how to go forward this
>                                                 week.
>
>
>                                                                                     Gruesse,
>                                                                                     Carsten
>
>                                                                                     core
>                                                                                     mailing
>                                                                                     list
>                                                                                     [email-masked]
>                                                                                     <mailto:[email-masked]>
>                                                                                     _https://www.ietf.org/mailman/listinfo/core_
>
>
>
>                                                                         core
>                                                                         mailing
>                                                                         list
>                                                                         [email-masked]
>                                                                         <mailto:[email-masked]>
>                                                                         _https://www.ietf.org/mailman/listinfo/core_
>
>
>                                                             --
>                                                             Zach
>                                                             Shelby,
>                                                             Chief
>                                                             Nerd,
>                                                             Sensinode Ltd.
>                                                             _http://zachshelby.org_
>                                                             <http://zachshelby.org/>
>                                                             - My blog
>                                                             "On the
>                                                             Internet
>                                                             of
>                                                             Things_"_
>                                                             <http://6lowpan.net-mybook/>
>                                                             _http://6lowpan.net
>                                                             - My book
>                                                             "_
>                                                             <http://6lowpan.net-mybook/>6LoWPAN:
>                                                             The
>                                                             Wireless
>                                                             Embedded
>                                                             Internet"
>                                                             Mobile:
>                                                             +358 40
>                                                             7796297
>
>
>
>
>                                                 [email-masked]
>                                                 <mailto:[email-masked]>
>                                                 _https://www.ietf.org/mailman/listinfo/core_
>
>                                                 Onzo is a limited
>                                                 company number
>                                                 06097997 registered in
>                                                 This email message may
>                                                 contain confidential
>                                                 and/or privileged
>                                                 is intended solely for
>                                                 the addressee(s). If
>                                                 you have received this
>                                                 email in
>                                                 error, please notify
>                                                 Onzo immediately.
>                                                 Unauthorised copying,
>                                                 distribution of the
>                                                 material in this email
>                                                 is forbidden.
>                                                 [email-masked]
>                                                 <mailto:[email-masked]>
>                                                 _https://www.ietf.org/mailman/listinfo/core_
>
>                                                 This email has been
>                                                 scanned by the
>                                                 MessageLabs Email
>                                                 Security System.
>                                                 [email-masked]
>                                                 <mailto:[email-masked]>
>                                                 _https://www.ietf.org/mailman/listinfo/core_
>
>
>
>                         [email-masked] <mailto:[email-masked]>
>                         _https://www.ietf.org/mailman/listinfo/core_
>
> [email-masked] <mailto:[email-masked]>
> _https://www.ietf.org/mailman/listinfo/core_
> [email-masked] <mailto:[email-masked]>
> _https://www.ietf.org/mailman/listinfo/core_
>
>
>
> _____________________________________________________________________________________________________________________
> core mailing list
> [email-masked]

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Fri, 28 May 2010 14:08:37 +0200

Hello,

with this flavor, the SUBSCRIBE may be replaced by a simple POST. So no needs to have an explicit SUBSCRIBE method.

If we want support a more oriented peer-to-peer transaction on CoAP, it looks to me both SUB and NOTIFY should be treated as messages.

Adriano

From: [email-masked] [mailto:[email-masked]] 
Sent: venerdì 28 maggio 2010 13.52
To: Adriano Pezzuto (apezzuto)
Cc: core; [email-masked]; [email-masked]
Subject: Re: [core] Subscribe/Notify for CoAP

> So strictly speaking, both NOTIFY and SUBSCRIBE are message types not  methods!

SUBSCRIBE can be just an asynchronous GET on update then I think it is a method and NOTIFY is an asynchronous response so a message.
But if we want to have selective notifications when a resource is created, updated or deleted then I think you're right NOTIFY and SUBSCRIBE are messages.

Does that make sense ?

Matthieu

 "Adriano Pezzuto (apezzuto)" <[email-masked]>

"Adriano Pezzuto (apezzuto)" <[email-masked]> 
Envoyé par : [email-masked] 

28/05/2010 12:50

A

cc

core <[email-masked]>

Objet

Hi Roberto,

Adriano 

Robert 

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

Adriano

From: Robert Cragie [mailto:[email-masked] <mailto:[email-masked]> ] 

Hi Adrian,

Derived methods:

Robert 

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

my 2 cents

- adriano

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Paul Duffy (paduffy)
Sent: mercoledì 26 maggio 2010 0.47
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

Hi,

Hi folks

Zach

Regards - Charles

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Paul Duffy
Sent: 25 May 2010 03:48
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

(thread renamed)

What do people think?

Zach

On May 17, 2010, at 6:44 PM, [email-masked] <mailto:[email-masked]>  wrote:

Hi,

Pros:

Cons:

Hope this could help,
Matthieu

"Charles Palmer"<[email-masked]> <mailto:[email-masked]> 
Envoyé par : [email-masked] <mailto:[email-masked]> 
15/05/2010 14:06

A

Dear all

Those interested in the subscribe/notify discussion might like to look
at the draft Smart Energy Profile 2.0 Application Protocol
Specification. It is available here:
http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp <http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp> 
licationProfile.aspx

Regards - Charles Palmer

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of
Angelo P. Castellani
Sent: 14 May 2010 13:14
To: Zach Shelby
Cc: core
Subject: Re: [core] Selecting a WG document for CoAP

Zach,

Best,
Angelo

Hi Angelo,

Dear C. Bormann, all,

still

current

 

a) As it is now, it is not possible to have a straightforward
translation of HTTP -> CoAP and viceversa: see
http://www.ietf.org/mail-archive/web/core/current/msg00133.html <http://www.ietf.org/mail-archive/web/core/current/msg00133.html>  (this
impacts the scalability of the web service model too)

 

 

Example:

 

Thanks,
Zach

Best regards,

Angelo P. Castellani

April:

http://datatracker.ietf.org/wg/core/charter/ <http://datatracker.ietf.org/wg/core/charter/> 
...
Apr 2010 Select WG document for basis of the CoAP protocol

Today, another updated version of that draft was announced. See
http://www.ietf.org/mail-archive/web/core/current/msg00138.html <http://www.ietf.org/mail-archive/web/core/current/msg00138.html> 
for the announcement and
http://tools.ietf.org/html/draft-shelby-core-coap-01 <http://tools.ietf.org/html/draft-shelby-core-coap-01> 
for the draft itself.

document?

Gruesse, Carsten

_______________________________________________
core mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core> 

_______________________________________________
core mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core> 

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org <http://zachshelby.org/>  - My blog "On the Internet of Things" <http://6lowpan.net-mybook/> 
http://6lowpan.net - My book " <http://6lowpan.net-mybook/> 6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

_______________________________________________
core mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core> 

_______________________________________________
core mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core> 

_______________________________________________
core mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core> 

_______________________________________________
core mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core> 

 

_______________________________________________
core mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core> 
_______________________________________________
core mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>

---

From: [email-masked]
Date: Fri, 28 May 2010 14:39:14 +0200

Hi Robert,

subscribe to be notified whenever some method is acted upon for a
particular resource? Can you describe the transaction model?
Excatly I want to be notified when a resource is deleted but not just
updated for example. So I send a subscribe message and the method of that
message is delete.

But the main usage of subscribe will be notifications upon modification of
a resource, so I'am fine with subscribe as method and notify as message.
Dynamic resources will probably be part of a collection, so we can still
monitor the modifications of the collection instead of an individual item.

Matthieu

Robert

             Robert Cragie                                                 
             <robert.cragie@gr                                             
             idmerge.com>                                                A 
                                       Matthieu                            
             28/05/2010 14:08          Vial/FR/Non/Schneider@Europe        
                                                                        cc 
                                       "Adriano Pezzuto (apezzuto)"        
             Veuillez répondre         <[email-masked]>, core          
                     à                 <[email-masked]>,                    
             robert.cragie@gri         [email-masked]               
                dmerge.com                                           Objet 
                                       Re: [core] Subscribe/Notify for     
                                       CoAP                                

                                                                           

Hi Matthieu,

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

      > So strictly speaking, both NOTIFY and SUBSCRIBE are message types
      not  methods!

      SUBSCRIBE can be just an asynchronous GET on update then I think it
      is a method and NOTIFY is an asynchronous response so a message.
      But if we want to have selective notifications when a resource is
      created, updated or deleted then I think you're right NOTIFY and
      SUBSCRIBE are messages.

      Does that make sense ?

      Matthieu

                                                                           
                         "Adriano Pezzuto                                  
                         (apezzuto)"                                       
                         <apezzuto@cisco.                                  
                         com>                                              
                         Envoyé par :                                    A 
                         core-bounces@iet                                  
                         f.org                           <robert.cragie@gr 
                                                         idmerge.com>      
                                                                           
                         28/05/2010 12:50                               cc 
                                                                           
                                                         core              
                                                         <[email-masked]>   
                                                                           
                                                                     Objet 
                                                                           
                                                         Re: [core]        
                                                         Subscribe/Notify  
                                                         for CoAP          

                                                                           

      Hi Roberto,
      I understand your point and personally agree on M2M is quite
      different from web page model. On the architectural RESTful style,
      the method information tells the server what to do with data kept in
      the URI information.

      Adriano

      I think the point here is that there are two levels we are
      considering.

      The actual architecture using a combination of the methods and
      messages also depends on what is required at the application layer.
      Consider a typical client which wants to subscribe to a resource.
      That client controls the feed of data but needs a component which is
      capable of handling (possibly buffering) the data it receives through
      notifications. Is this a separate server? Or would we want to
      consider it part of an enhanced client model which is able to process
      feeds of data? These are the sort of models which have led to the
      myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub,
      RESTMS etc.) based around HTTP which are all essentially ingenious
      ways of getting around the limitations imposed by HTTP and how it is
      processed for anything which deviates from the classic web page
      access model.

      Robert

      Gridmerge Ltd.
      89 Greenfield Crescent,
      Wakefield, WF4 4WA, UK
      +44 1924 910888
      +1 415 513 0064
      http://www.gridmerge.com

      in my personal opinion, the option 1a) brings some sort of ambiguity
      to CoAP specs.

      My be my understatement of new CoAP specs is not so deep, but now we
      have 5 methods and 3 message types: request, response and notify.
      Which methods are allowed with which messages types?
      I suppose you have to use PUT/POST method with notify message for
      asynch data notification. How to make a subscribe? I suppose you
      would use a SUBSCRIBE method with request/response message or
      SUBSCRIBE with notify message? Also what about POST/DELETE methods in
      a notify message? They not make any sense..

      I think the choice is between: option 1) -> only CRUD methods and
      option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind
      cost/benefits of both solutions.

      Adriano

      Hi Adrian,

      I would also prefer to keep the protocol in CoAP asynchronous. You
      can always map an asynchronous protocol to a synchronous one but, as
      we see in HTTP, it always ends up as a kludge to do it the other way
      round. The efforts which have been gone to to make HTTP
      quasi-asynchronous via all the schemes mentioned below and many more
      besides (all non-interoperable of course) is testament to how
      important this is for M2M communication.

            1. request/response can be asynchronous or synchronous messages
            (as there is a transaction ID in there)
            2. notify is an asynchronous message
      Derived methods:

      I think it makes sense to add a pub/sub model as a useful mechanism
      for M2M.

      So, looking at it the other way round: It will be entirely possible
      to translate whatever is currently built on HTTP to CoAP based on the
      above, with all its restrictions regarding synchronous and
      client/server transactions. What may be harder is to translate
      directly is a CoAP-based application to HTTP. So I guess the question
      is: Do we want to be hamstrung to synchronous client/server
      transactions as dictated by HTTP and provide a direct mapping to
      HTTP, then have to come up with similar kludges for asynchronous
      peer-to-peer transactions as has been done in numerous ways for HTTP,
      or do we want to define the protocol cleanly to start with and accept
      that some sort of transaction relaying/conversion would have to take
      place at a mapping node?

      Robert

      Gridmerge Ltd.
      89 Greenfield Crescent,
      Wakefield, WF4 4WA, UK
      +44 1924 910888
      +1 415 513 0064
      http://www.gridmerge.com

      On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
      Hi,
      it looks to me that CoAP should use an explicit sub/notify mechanism
      since this is the core of the machine-to-machine interaction model.
      HTTP suffers of this lack and we have seen a plethora of solutions to
      give an asynch taste to it. Webhooks and websockets are only the
      lasts of the list.
      As someone has already pointed out on this list, it is theoretically
      possible to describe sub/notify using only CRUD methods but it looks
      a little bit tricky and verbose.

      CoAP - as binary protocol - and with an explicit asynch model has a
      chance to be a really wide protocol for M2M communication not only
      for constrained environments.

      my 2 cents

      - adriano

      -----Original Message-----
      From: [email-masked] [mailto:[email-masked]] On Behalf
      Of Paul Duffy (paduffy)
      Sent: mercoledì 26 maggio 2010 0.47
      To: Zach Shelby
      Cc: core
      Subject: Re: [core] Subscribe/Notify for CoAP

                  Hi,

                              Hi folks

                              It occurs to me that CoRE should be keeping a
                              close eye on ZigBee SE2.0 work, so that it is
                              as easy as possible for ZigBee SE to use CoRE
                              when ready. That suggests to me that we
                              should align with their subscribe/notify
                              process.

                  there. Nothing stopping someone from using SE2.0 over
                  CoAP.

                  without any clear standard appearing - or am I wrong
                  there?

                  Zach

                              Regards - Charles

                              -----Original Message-----

                              Recommend something like #2, primarily to
                              avoid introducing non HTTP
                              method semantics, simplifying HTTP/COAP
                              translation.gateways, etc.

                                          (thread renamed)

                                          1. Use specific Subscription and
                                          Notify mechanisms for CoAP as
                                          HTTP really does not include this
                                          concept.
                                          1a) Notify as a message and
                                          SUBSCRIBE as a method. This is
                                          currently used in coap-01.
                                          1b) NOTIFY and SUBSCRIBE as
                                          methods. This was used in
                                          coap-00, but we had a good list
                                          discussion about this leading to
                                          a. In practice it doesn't make a
                                          big difference if notification is
                                          a message or method.

                                          2. Use an HTTP specific framework
                                          such as Webhooks, the ZigBee
                                          SE2.0 proposal or GENA.

                                          So far we have focused on 1 in
                                          the WG, and every now and again 2
                                          comes up. At least I am not
                                          convinced that we need to suffer
                                          the drawbacks of HTTP here.
                                          Anyways 2 does not help our
                                          mapping to HTTP in reality very
                                          much as there is no standard way
                                          of doing this over HTTP. Thus a
                                          CoAP-HTTP proxy may end up
                                          anyways translating between
                                          multiple HTTP frameworks
                                          depending on the application. So
                                          instead of doing a CoAP
                                          Notify/Subscribe to Webhooks
                                          mapping, you will could end up
                                          having to do a CoAP Webhooks to
                                          HTTP GENA mapping.

                              I don't understand this last para. If CoAP
                              sticks to the semantics of
                              the current HTTP methods, would this not
                              offer a fairly straightforward
                              translation to/from HTTP?

                                                      From what I have
                                                      heard so far 1 still
                                                      seems like a wise
                                                      choice, although I
                                                      need to look at
                                                      Webhooks more deeply.
                                                      In reality many
                                                      applications specify
                                                      their own way of
                                                      doing a push
                                                      interface using REST
                                                      methods and specific
                                                      payloads (ZigBee
                                                      SE2.0 is such an
                                                      example). That is
                                                      just fine, and might
                                                      be used instead of a
                                                      specific CoAP
                                                      notify/subscribe in
                                                      that case. So 1
                                                      doesn't prevent the
                                                      application using its
                                                      own mechanism, it
                                                      just provides a
                                                      native way for doing
                                                      push.

                                          What do people think?

                                          Zach

                                          On May 17, 2010, at 6:44 PM,
                                          [email-masked]
                                           wrote:

                                                      Hi,

                                                      My comments about the
                                                      subscribe/notify
                                                      mechanism of Zigbee
                                                      IP.

                                                      Pros:
                                                      - Derived from the
                                                      webhooks concept
                                                      - If used by CORE it
                                                      will be easier to map
                                                      to HTTP because it
                                                      uses only CRUD verbs.
                                                      - The subscription
                                                      message is extendable
                                                      and could support
                                                      advanced options
                                                      (delays,
                                                      increment, ...)
                                                      - Only one listening
                                                      port whatever the
                                                      transport binding is.

                                                      Cons:
                                                      - No interoperability
                                                      without well known
                                                      URIs and a well
                                                      defined subscription
                                                      message format (Not
                                                      sure CoAP draft is
                                                      the right place to
                                                      specify this).
                                                      - XML/EXI is too
                                                      complex to be the
                                                      required format for
                                                      the default
                                                      subscription/notification
 mechanism.
                                                      - The notification
                                                      should not require a
                                                      subsequent GET to
                                                      retrieve the content.
                                                      - Subresource
                                                      subscription is
                                                      redundant.

                                                      Hope this could help,
                                                      Matthieu

                                                      "Charles
                                                      Palmer"

                                                      "Charles Palmer"

                                                      Envoyé par :
                                                      [email-masked]
                                                      15/05/2010 14:06

                                                      A
                                                      "core"<[email-masked]>
                                                      cc
                                                      Objet
                                                      Re: [core] Selecting
                                                      a WG document for
                                                      CoAP

                                                      Dear all

                                                      Those interested in
                                                      the subscribe/notify
                                                      discussion might like
                                                      to look
                                                      at the draft Smart
                                                      Energy Profile 2.0
                                                      Application Protocol
                                                      Specification. It is
                                                      available here:

                                                      licationProfile.aspx

                                                      It manages
                                                      subscribe/notify by
                                                      using POST. This
                                                      seems to remove the
                                                      need
                                                      for SUBSCRIBE and
                                                      notify.

                                                      "Imagine a host A,
                                                      which exposes a
                                                      resource at http
                                                      {s}://A/resource and
                                                      a second host B,
                                                      which wishes to learn
                                                      of changes to this
                                                      resource. To
                                                      facilitate a
                                                      subscription/
                                                      notification
                                                      mechanism, A would
                                                      expose a
                                                      resource http
                                                      {s}://A/sub and B
                                                      would expose a
                                                      resource http
                                                      {s}://B/ntfy.
                                                      To subscribe to
                                                      notifications
                                                      regarding http
                                                      {s}://A/resource, B
                                                      would
                                                      send a POST to the
                                                      address http
                                                      {s}://A/sub/B
                                                      containing the URI of
                                                      the
                                                      resource of interest
                                                      (http
                                                      {s}://A/resource) and
                                                      the URI of B's
                                                      notification resource
                                                      (http{s}://B/ntfy).
                                                      Following this
                                                      subscription
                                                      step, should A wish
                                                      to notify B of a
                                                      change to the
                                                      resource addressed at
                                                      http{s}://A/resource,
                                                      A would send a POST
                                                      to the address
                                                      http{s}://B/ntfy
                                                      containing the URI of
                                                      the resource changed
                                                      (http
                                                      {s}://A/resource) and
                                                      the URI of A's
                                                      subscription resource
                                                      (http{s}://A/sub/B),
                                                      should A wish to
                                                      change its
                                                      subscription. The
                                                      host
                                                      B can then query the
                                                      resource (or not) at
                                                      its leisure."

                                                      Sleepy nodes are not
                                                      allowed to subscribe,
                                                      and must poll.

                                                      Regards - Charles
                                                      Palmer

                                                      -----Original
                                                      Message-----
                                                      From:
                                                      [email-masked]
                                                      [
                                                      mailto:[email-masked]
                                                      ] On Behalf Of
                                                      Angelo P. Castellani
                                                      Sent: 14 May 2010
                                                      13:14
                                                      To: Zach Shelby
                                                      Cc: core
                                                      Subject: Re: [core]
                                                      Selecting a WG
                                                      document for CoAP

                                                      Zach,

                                                      thanks for the
                                                      comments, but please
                                                      refer to my most
                                                      recent e-mail for
                                                      a more specific list
                                                      of technical issues
                                                      I'm pointing to.

                                                      I want to do only a
                                                      little integration to
                                                      what I've written
                                                      there.

                                                      In my very personal
                                                      opinion, to maximize
                                                      adherence with the
                                                      REST model
                                                      and minimize
                                                      implementation effort
                                                      SUBSCRIBE and NOTIFY
                                                      should be
                                                      mapped to methods (as
                                                      discussed many times
                                                      together...).

                                                      Uniform interface
                                                      principle (Fielding
                                                      PhD dissertation
                                                      Section 5.1.5,
                                                      "The central feature
                                                      that distinguishes
                                                      the REST
                                                      architectural style
                                                      [...]") states that
                                                      to simplify the
                                                      software
                                                      architecture,
                                                      resource
                                                      interfaces/interfaces
                                                      should be as general
                                                      as possible.

                                                      I agree with this
                                                      principle in this
                                                      specific case, mainly
                                                      because
                                                      handling a special
                                                      message type for
                                                      notify leads node
                                                      software design
                                                      to a more complex
                                                      architecture.

                                                      The reason is that
                                                      this new message type
                                                      requires special
                                                      handling and
                                                      introduces a
                                                      complexity in the
                                                      software
                                                      modularization.

                                                      Best,
                                                      Angelo

                                                      On Fri, May 14, 2010
                                                      at 13:06, Zach Shelby
                                                      <[email-masked]>
                                                      wrote:

                                                                  Hi
                                                                  Angelo,

                                                                  On May
                                                                  13, 2010,
                                                                  at
                                                                  14:24 ,
                                                                  Angelo P.
                                                                  Castellani
 wrote:

   Dear C. Bormann, all,

                                                      still

                                                      current

                                                                  Of course
                                                                  there are
                                                                  plenty of
                                                                  open
                                                                  issues.
                                                                  Remember
                                                                  that
                                                                  working
                                                                  group

                                                      documents still
                                                      undertake as much
                                                      change and
                                                      improvement as the WG
                                                      wants, so by no means
                                                      is coap-01 set in
                                                      stone. I would expect
                                                      at least
                                                      5-10 more revisions
                                                      still along the way.
                                                      Already several of
                                                      your ideas
                                                      have been integrated
                                                      into coap-01, and
                                                      several more are
                                                      under
                                                      consideration, so it
                                                      is coming along.
                                                      Patience ;-)

                                                                  In
                                                                  coap-01
                                                                  the
                                                                  Method
                                                                  names are
                                                                  now
                                                                  identical
                                                                  to HTTP
                                                                  methods.
                                                                  The

                                                      Req/Res interaction
                                                      is a direct
                                                      translation. The URI
                                                      hierarchy is
                                                      compatible, and the
                                                      URI binary code
                                                      format we are still
                                                      working on
                                                      obviously. The only
                                                      thing that takes some
                                                      state to translate is
                                                      Subscribe/Notify. But
                                                      note,
                                                      Subscribe/Notify
                                                      takes some state no
                                                      matter
                                                      how you do it, even
                                                      with HTTP-HTTP there
                                                      is no clean and easy
                                                      way to
                                                      handle subscriptions.

                                                                  This we
                                                                  can
                                                                  definitely
 improve, and already made several optimizations

                                                      from -00 to -01. Here
                                                      I need some very
                                                      concrete proposals
                                                      though. Also
                                                      remember that many
                                                      things are optional,
                                                      for example
                                                      subscribe/notify is
                                                      not required if you
                                                      don't need it.

   Example:

                                                                  Right,
                                                                  that is
                                                                  not how
                                                                  it will
                                                                  work in
                                                                  practice.
                                                                  Working
                                                                  with a
                                                                  real

                                                      HTTP server that HTTP
                                                      header will be more
                                                      complex, and on the
                                                      CoAP side
                                                      you would chose
                                                      shorter URLs. The
                                                      biggest improvement
                                                      possible here is
                                                      from using binary
                                                      coded URLs of course.
                                                      We need to look at a
                                                      wider range
                                                      of interactions and
                                                      real HTTP headers as
                                                      well to check that we
                                                      are
                                                      efficient enough.

                                                                  I am not
                                                                  sure what
                                                                  else you
                                                                  have in
                                                                  mind for
                                                                  a). If we
                                                                  just
                                                                  forget

                                                      about
                                                      Subscribe/Notify then
                                                      you are good to go.
                                                      But then you are also
                                                      not fulfilling the
                                                      charter or the
                                                      industry needs in
                                                      that respect.

                                                                  Thanks,
                                                                  Zach

   Best regards,

   Angelo P. Castellani

               The CORE WG has a milestone to select a WG document for CoAP
               in

                                                      April:

                                                      draft-shelby-core-coap
 has significant discussion, as well as the
                                                      largest number of
                                                      updates (including a
                                                      previous version that
                                                      was still
                                                      called
                                                      -6lowapp-coap).

               Today, another updated version of that draft was announced.
               See
               http://www.ietf.org/mail-archive/web/core/current/msg00138.html

               for the announcement and

               However, as the authors say, there are still significant
               TODOs.

               Are we in a state yet where we can say whether this is the
               right

                                                      direction for the WG
                                                      to take?

               If yes, is it the right direction? Should we adopt it as a
               WG

                                                      document?

               If you don't think we can say yet, is there a set of
               technical

                                                      decisions you would
                                                      like the authors to
                                                      take with priority?

               Note that once a document has become a WG document, the
               authors act

                                                      as editors for the
                                                      working group, making
                                                      (and usually fleshing
                                                      out the
                                                      details of) any
                                                      change that the WG
                                                      decides it needs.

               If you think we can still improve the draft, this is not an
               obstacle

                                                      to making it a WG
                                                      document.

               But of course we shouldn't do that if we intend to reverse
               its

                                                      fundamental technical
                                                      direction.

               In order to stay roughly in sync with our milestones, we
               should

                                                      reach at a decision
                                                      on how to go forward
                                                      this week.

               Gruesse, Carsten

                                                                  --
                                                                  Zach
                                                                  Shelby,
                                                                  Chief
                                                                  Nerd,
                                                                  Sensinode
                                                                  Ltd.
                                                                  http://zachshelby.org
                                                                   - My
                                                                  blog "On
                                                                  the
                                                                  Internet
                                                                  of Things
                                                                  "
                                                                  http://6lowpan.net
 - My book "
                                                                  6LoWPAN:
                                                                  The
                                                                  Wireless
                                                                  Embedded
                                                                  Internet"
                                                                  Mobile:
                                                                  +358 40
                                                                  7796297

                                                      core mailing list
                                                      [email-masked]

                                                      Onzo is a limited
                                                      company number
                                                      06097997 registered
                                                      in England& Wales.
                                                      The
                                                      registered office is
                                                      6 Great Newport
                                                      Street, London, WC2H
                                                      7JB, United Kingdom.

                                                      This email message
                                                      may contain
                                                      confidential and/or
                                                      privileged
                                                      information, and
                                                      is intended solely
                                                      for the addressee(s).
                                                      If you have received
                                                      this email in
                                                      error, please notify
                                                      Onzo immediately.
                                                      Unauthorised copying,
                                                      disclosure or
                                                      distribution of the
                                                      material in this
                                                      email is forbidden.

                                                      core mailing list
                                                      [email-masked]

                                                      This email has been
                                                      scanned by the
                                                      MessageLabs Email
                                                      Security System.

                                                      core mailing list
                                                      [email-masked]

                              core mailing list
                              [email-masked]

                              This email message may contain confidential
                              and/or privileged information, and
                              is intended solely for the addressee(s). If
                              you have received this email in
                              error, please notify Onzo immediately.
                              Unauthorised copying, disclosure or
                              distribution of the material in this email is
                              forbidden.
                              --------------------------------

---

From: Zach Shelby <[email-masked]>
Date: Fri, 28 May 2010 15:50:12 +0300

Hi,

This is a really good conversation. One thing we need to do is remember what our minimum requirements are for subscribe/notify and not try to solve something more than we should. From what I know it is sufficient to be able to receive notifications when a URI changes or periodically. You might consider new URIs under this URI path to be changes to a URI though... 

> with this flavor, the SUBSCRIBE may be replaced by a simple POST. So no needs to have an explicit SUBSCRIBE method.

This is what coap-01 assumes. 

> If we want support a more oriented peer-to-peer transaction on CoAP, it looks to me both SUB and NOTIFY should be treated as messages.

The Request/Response model can be used peer-to-peer, and in CoAP you can even use a Request asynchronously. Additionally, we want a native RESTful subscribe/notify technique, that is, we want to subscribe to resources and be susequently notified about those resources when they change.

In that sense, you can think of a subscription as a request to receive asynchronous notifications about a resource (about a URI). This can be achieved by:

1.  as a SUBSCRIBE Request on the URI with some option indicating the lifetime as in coap-01,
2.  as a Subcsribe message (no methods) on the URI with some option, 
3.  or as a POST Request on the URI with options indicating that this is actually a subscription and the lifetime.  This bends the meaning of POST quite a bit and might be prone to mistakes?

The asynchronous response is a harder one. Can we bend the meaning of a Request for making asynchronous notifications? Also a notification includes a URI about a resource on the requestor, which is inverse from normal Requests in REST. So the options here are:

1. as a Notify message about a URI (no methods) as in coap-01,
2. as a NOTIFY Request about a URI as was in coap-00,
3. hmmm... reusing CRUD methods really doesn't work for this one at all... 

I wonder what the HTTP designers would have done if this would have been a requirement back then? Maybe we should ask them...

Zach

> On May 17, 2010, at 6:44 PM,[email-masked] wrote:
> 
> 
> 
> Hi,
> 
> On Mon, May 10, 2010 at 18:51, Carsten Bormann<[email-masked]>wrote:
> 
>

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 28 May 2010 15:13:20 +0200

In my opinion Subscribe/Notify are special methods of interaction
between resources.

1) SUBSCRIBE: Any resource A can send a Request to SUBSCRIBE with a
resource B (to the resource B URI).

When B receives the request, B can (should/must?) answer with a
Response to the SUBSCRIBE Request, telling the result of the request
(subscription accepted/denied/unsupported?).

2) NOTIFY: When subscription condition fires the resource B sends a
NOTIFY Request to resource A URI.

When A receives the request, A can (should/must?) answer with a
Response to the NOTIFY Request, telling the result of the request (OK,
cancel subscription, change notify options?).

In each Request must be specified the URI of the resource doing the
Request too (Option? From-URI?).

Angelo

---

From: [email-masked]
Date: Fri, 28 May 2010 15:24:21 +0200

Hi,

The Waka protocol from Roy Fielding has a new monitor verb
http://en.wikipedia.org/wiki/Waka_%28protocol%29

Matthieu

             Zach Shelby                                                   
             <[email-masked]                                             
             om>                                                         A 
                                       Adriano Pezzuto (apezzuto)          
             28/05/2010 14:50          <[email-masked]>                
                                                                        cc 
                                       Matthieu                            
                                       Vial/FR/Non/Schneider@Europe, core  
                                       <[email-masked]>                     
                                                                     Objet 
                                       Re: [core] Subscribe/Notify for     
                                       CoAP                                

                                                                           

Hi,

This is a really good conversation. One thing we need to do is remember
what our minimum requirements are for subscribe/notify and not try to solve
something more than we should. From what I know it is sufficient to be able
to receive notifications when a URI changes or periodically. You might
consider new URIs under this URI path to be changes to a URI though...

On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote:

> Hello,
> with this flavor, the SUBSCRIBE may be replaced by a simple POST. So no
needs to have an explicit SUBSCRIBE method.

> If we want support a more oriented peer-to-peer transaction on CoAP, it
looks to me both SUB and NOTIFY should be treated as messages.

The Request/Response model can be used peer-to-peer, and in CoAP you can
even use a Request asynchronously. Additionally, we want a native RESTful
subscribe/notify technique, that is, we want to subscribe to resources and
be susequently notified about those resources when they change.

In that sense, you can think of a subscription as a request to receive
asynchronous notifications about a resource (about a URI). This can be
achieved by:

1.  as a SUBSCRIBE Request on the URI with some option indicating the
lifetime as in coap-01,
2.  as a Subcsribe message (no methods) on the URI with some option,
3.  or as a POST Request on the URI with options indicating that this is
actually a subscription and the lifetime.  This bends the meaning of POST
quite a bit and might be prone to mistakes?

The asynchronous response is a harder one. Can we bend the meaning of a
Request for making asynchronous notifications? Also a notification includes
a URI about a resource on the requestor, which is inverse from normal
Requests in REST. So the options here are:

I wonder what the HTTP designers would have done if this would have been a
requirement back then? Maybe we should ask them...

Zach

methods!
> But if we want to have selective notifications when a resource is
created, updated or deleted then I think you're right NOTIFY and SUBSCRIBE
are messages.
methods!
CoAP specs.
M2M.
> HTTP suffers of this lack and we have seen a plethora of solutions to
give an asynch taste to it. Webhooks and websockets are only the lasts of
the list.
think using explicit sub/notify methods with a clear and well defined
semantic is the best option. It is easily understanding from every
developer and will prevent to build other fanny solutions on top of the
CoAP. HTTP does not have this well defined semantic and (for hundreds of
other reasons also) it is not used as wide protocol for machine-to-machine
communication.
Paul Duffy (paduffy)
> I am not sure I understand that. I mean, ZigBee SE2.0 is defining an
application specific subscribe/notify mechanism for that purpose so far for
HTTP. This uses standard HTTP methods and some custom payload and REST
interfaces. CoAP Req/Res is already totally compatible with SE2.0 in that
respect, so alignment is already OK there. Nothing stopping someone from
using SE2.0 over CoAP.
>
> Specifying a native susbcription/notify into CoAP is another matter. We
can't adopt a solution specific to one application as that won't solve the
problems of other applications nor general HTTP mapping at all (probably
would make it worse). It seems that for the near future there will be a
bunch of HTTP push mechanisms in use without any clear standard appearing -
or am I wrong there?
Paul Duffy
> From what I have heard so far 1 still seems like a wise choice, although
I need to look at Webhooks more deeply. In reality many applications
specify their own way of doing a push interface using REST methods and
specific payloads (ZigBee SE2.0 is such an example). That is just fine, and
might be used instead of a specific CoAP notify/subscribe in that case. So
1 doesn't prevent the application using its own mechanism, it just provides
a native way for doing push.
CRUD verbs.
content.
Kingdom.
information, and
Kingdom.
information, and

---

From: Zach Shelby <[email-masked]>
Date: Fri, 28 May 2010 17:29:15 +0300

> In my opinion Subscribe/Notify are special methods of interaction

This is definitely one valid way to look at it.

> resource B (to the resource B URI).

Small correction, it is not a resource sending the SUBSCRIBE, it is an end-point (source address + port) sending it. Correct, it is being sent for resource B. So end-point A sends a SUBSCRIBE for resource B.

> When B receives the request, B can (should/must?) answer with a

MUST I would say (so the A flag must be set).

> (subscription accepted/denied/unsupported?).

Yep.

> NOTIFY Request to resource A URI.

The end-point sends a NOTIFY Request about resource B's URI to end-point A. So there is not a source and destination "resource", instead there is just resource B. 

> cancel subscription, change notify options?).

The A flag would control the need for a response.

> Request too (Option? From-URI?).

Actually, this is the URI (resource B) so you only need one URI. This is why I say that a notification is like an inverse GET request. 

Zach

---

From: Robert Cragie <[email-masked]>
Date: Fri, 28 May 2010 18:22:44 +0100

I think sometimes it makes more sense to think about threads of execution.

Forgive me for this lengthy preamble but it will hopefully put things 
into context.

In the most abstract sense, processing is governed by a thread of 
execution, which sequences a series of data transformations to expedite 
the required processing. If a data transformation can be completed 
synchronously in the thread of execution, then the thread is 
conceptually easier to understand and follow. Most threading models 
assume this to be the case and if the data transformation cannot 
complete, it usually blocks pending the required event to complete the 
transformation. During blocking, the thread is suspended. In simple CPU 
models without any sort of scheduler, there are two threads of 
execution: A main thread, pre-emptable by an interrupt thread, usually 
not pre-emptable. In the main thread, sub-threads are emulated; data 
transformations can be simply function calls which don't block and 
therefore return effectively immediately and synchronously. Blocking 
data transformations are emulated by storing state relevant to each 
sub-thread then marshaling each event as it is received e.g. through 
interrupt handling, which causes the second thread to run and thus 
allows changing sub-thread state so when the main thread runs, the 
blocking data transformation can complete. Operating system schedulers 
for these simple CPUs simply abstract this operation through a kernel 
and associated task/thread scheduling calls. Continuations are a simpler 
form used in memory-constrained implementations.

Why the lengthy pre-amble? However you look at it, what essentially is 
required for any threading model (using kernel/scheduler, continuations, 
emulated, whatever) are fundamentally three primitives:

    * Request
    * Response
    * Notify

A thread of execution will call request and will typically (though not 
necessarily - see emulated blocking/continuations) wait for a response. 
If the thread blocks, it is typically woken by another worker thread 
handling a notify. The worker thread handles notifies asynchronously and 
buffers and/or signals the associated task accordingly.

This is why I think the current foundation level of messages in coap-01 
is right.

On top of this, the payload of the messages can reflect the actual 
method. Personally, I don't see the need for a specific SUBSCRIBE 
message; a POST/create to a subscription resource seems adequate to me. 
The notify message can carry a PUT or POST depending on whether the 
resource was simply updated or appended to (again it is no accident the 
data types in JSON are as they are).

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 28/05/2010 2:13 PM, Angelo P. Castellani wrote:
> On Fri, May 28, 2010 at 14:50, Zach Shelby<[email-masked]>  wrote:
>    
>> Hi,
>>
>>> "Adriano Pezzuto (apezzuto)"<[email-masked]>
>>>
>>>
>>>
>>>
>>> "Adriano Pezzuto (apezzuto)"<[email-masked]>
>>> core<[email-masked]>
>>> Robert Cragie (Pacific Gas&  Electric)
>>>
>>> Gridmerge Ltd.
>>> 89 Greenfield Crescent,
>>> Wakefield, WF4 4WA, UK
>>> +44 1924 910888
>>> +1 415 513 0064
>>> http://www.gridmerge.com
>>>
>>> Robert Cragie (Pacific Gas&  Electric)
>>>
>>> Gridmerge Ltd.
>>> 89 Greenfield Crescent,
>>> Wakefield, WF4 4WA, UK
>>> +44 1924 910888
>>> +1 415 513 0064
>>> http://www.gridmerge.com
>>>

---

From: Brian Frank <[email-masked]>
Date: Fri, 28 May 2010 17:21:30 -0400

My two cents:

Personally I find it confusing to have both a message type *and* a method.

Do we really need both?  It seems we just combine the two into a single
method byte.  Maybe reserve a bit to say a message is a response to a GET,
PUT, DELETE, etc.

On Fri, May 28, 2010 at 1:22 PM, Robert Cragie
<[email-masked]>wrote:

> Forgive me for this lengthy preamble but it will hopefully put things into
> context.
>
> execution, which sequences a series of data transformations to expedite the
> required processing. If a data transformation can be completed synchronously
> in the thread of execution, then the thread is conceptually easier to
> understand and follow. Most threading models assume this to be the case and
> if the data transformation cannot complete, it usually blocks pending the
> required event to complete the transformation. During blocking, the thread
> is suspended. In simple CPU models without any sort of scheduler, there are
> two threads of execution: A main thread, pre-emptable by an interrupt
> thread, usually not pre-emptable. In the main thread, sub-threads are
> emulated; data transformations can be simply function calls which don't
> block and therefore return effectively immediately and synchronously.
> Blocking data transformations are emulated by storing state relevant to each
> interrupt handling, which causes the second thread to run and thus allows
> changing sub-thread state so when the main thread runs, the blocking data
> transformation can complete. Operating system schedulers for these simple
> CPUs simply abstract this operation through a kernel and associated
> task/thread scheduling calls. Continuations are a simpler form used in
> memory-constrained implementations.
>
>    - Request
>    - Response
>    - Notify
> necessarily - see emulated blocking/continuations) wait for a response. If
> the thread blocks, it is typically woken by another worker thread handling a
> notify. The worker thread handles notifies asynchronously and buffers and/or
> signals the associated task accordingly.
>
> This is why I think the current foundation level of messages in coap-01 is
> right.
>
> On top of this, the payload of the messages can reflect the actual method.
> Personally, I don't see the need for a specific SUBSCRIBE message; a
> POST/create to a subscription resource seems adequate to me. The notify
> message can carry a PUT or POST depending on whether the resource was simply
> updated or appended to (again it is no accident the data types in JSON are
> as they are).
>
> Robert
>
> On Fri, May 28, 2010 at 14:50, Zach Shelby <[email-masked]> <[email-masked]> wrote:
>
>
>  Hi,
>
> From: [email-masked] [mailto:[email-masked] <[email-masked]>]
> "Adriano Pezzuto (apezzuto)" <[email-masked]> <[email-masked]>
>
>
>
>
> "Adriano Pezzuto (apezzuto)" <[email-masked]> <[email-masked]>
> <[email-masked]> <[email-masked]>
> cc
> core <[email-masked]> <[email-masked]>
> Objet
> From: Robert Cragie [mailto:[email-masked] <[email-masked]>]
> +1 415 513 0064http://www.gridmerge.com
>
> From: Robert Cragie [mailto:[email-masked] <[email-masked]>]
> +1 415 513 0064http://www.gridmerge.com
>
> From: [email-masked] [mailto:[email-masked] <[email-masked]>] On Behalf Of Paul Duffy (paduffy)
> From: [email-masked] [mailto:[email-masked] <[email-masked]>] On Behalf Of Paul Duffy
> Sent: 25 May 2010 03:48
> To: Zach Shelby
> Cc: core
> "Charles Palmer"<[email-masked]> <[email-masked]>
>
>
>
>
> "Charles Palmer"<[email-masked]> <[email-masked]>
> "core"<[email-masked]> <[email-masked]>
> cc
> Objet
> Specification. It is available here:http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp
> licationProfile.aspx
>
> From: [email-masked] [mailto:[email-masked] <[email-masked]>] On Behalf Of
> Angelo P. Castellani
> Sent: 14 May 2010 13:14
> To: Zach Shelby
> Cc: core
> On Fri, May 14, 2010 at 13:06, Zach Shelby<[email-masked]> <[email-masked]> wrote:
>
>
> Hi Angelo,
>
> translation of HTTP -> CoAP and viceversa: seehttp://www.ietf.org/mail-archive/web/core/current/msg00133.html (this
> On Mon, May 10, 2010 at 18:51, Carsten Bormann<[email-masked]> <[email-masked]>wrote:
>
>
> Today, another updated version of that draft was announced. Seehttp://www.ietf.org/mail-archive/web/core/current/msg00138.html
> for the announcement andhttp://tools.ietf.org/html/draft-shelby-core-coap-01
> for the draft itself.
>
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
>
>
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.http://zachshelby.org - My blog "On the Internet of Things"
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
>
>
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
>
>
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
>  --
> Zach Shelby, Chief Nerd, Sensinode Ltd.http://zachshelby.org  - My blog "On the Internet of Things"
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
>

---

From: [email-masked]
Date: Mon, 31 May 2010 10:57:59 +0200

Hi Robert,

Here is a complete scenario:

The resource /event is a collection of events that occured in device A.
Device B wants to be notified each time a new event has occured in A.

One solution could be to subscribe when the method POST (thus a creation)
is acted upon /event.
A would send a notify message with the URI of the new event
(/event/1, /event/2 ...).

The second solution using the actual COAP specification is to
define /event/last as an alias to the last created event.
Device B would receive a notification each time /event/last has changed.
The definition of "changed" becomes tricky if 2 successive events are
identical.
The content of /event/last is identical but it points to a different
resource.
Of course the etag could reflect that change.

So what is the RESTfulest solution ?

Matthieu

             Robert Cragie                                                 
             <robert.cragie@gr                                             
             idmerge.com>                                                A 
                                       Matthieu                            

                                                                           

Hi Matthieu,

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

      Does that make sense ?

      Matthieu

                                                                           
                         "Adriano Pezzuto                                  
                         (apezzuto)"                                       
                         <apezzuto@cisco.                                  
                         com>                                              
                         Envoyé par :                                    A 
                         core-bounces@iet                                  
                         f.org                           <robert.cragie@gr 
                                                         idmerge.com>      
                                                                           
                         28/05/2010 12:50                               cc 
                                                                           
                                                         core              
                                                         <[email-masked]>   
                                                                           
                                                                     Objet 
                                                                           
                                                         Re: [core]        
                                                         Subscribe/Notify  
                                                         for CoAP          

                                                                           

      Hi Roberto,

      Adriano

      Robert

      Gridmerge Ltd.
      89 Greenfield Crescent,
      Wakefield, WF4 4WA, UK
      +44 1924 910888
      +1 415 513 0064
      http://www.gridmerge.com

      Adriano

      Hi Adrian,

      Robert

      Gridmerge Ltd.
      89 Greenfield Crescent,
      Wakefield, WF4 4WA, UK
      +44 1924 910888
      +1 415 513 0064
      http://www.gridmerge.com

      my 2 cents

      - adriano

      -----Original Message-----
      From: [email-masked] [mailto:[email-masked]] On Behalf
      Of Paul Duffy (paduffy)
      Sent: mercoledì 26 maggio 2010 0.47
      To: Zach Shelby
      Cc: core
      Subject: Re: [core] Subscribe/Notify for CoAP

                  Hi,

                              Hi folks

                  Zach

                              Regards - Charles

                              -----Original Message-----

                                          (thread renamed)

                                                      From what I have
                                                      heard so far 1 still
                                                      seems like a wise
                                                      choice, although I
                                                      need to look at
                                                      Webhooks more deeply.
                                                      In reality many
                                                      applications specify
                                                      their own way of
                                                      doing a push
                                                      interface using REST
                                                      methods and specific
                                                      payloads (ZigBee
                                                      SE2.0 is such an
                                                      example). That is
                                                      just fine, and might
                                                      be used instead of a
                                                      specific CoAP
                                                      notify/subscribe in
                                                      that case. So 1
                                                      doesn't prevent the
                                                      application using its
                                                      own mechanism, it
                                                      just provides a
                                                      native way for doing
                                                      push.

                                          What do people think?

                                          Zach

                                                      Hi,

                                                      My comments about the
                                                      subscribe/notify
                                                      mechanism of Zigbee
                                                      IP.

                                                      Pros:
                                                      - Derived from the
                                                      webhooks concept
                                                      - If used by CORE it
                                                      will be easier to map
                                                      to HTTP because it
                                                      uses only CRUD verbs.
                                                      - The subscription
                                                      message is extendable
                                                      and could support
                                                      advanced options
                                                      (delays,
                                                      increment, ...)
                                                      - Only one listening
                                                      port whatever the
                                                      transport binding is.

                                                      Cons:
                                                      - No interoperability
                                                      without well known
                                                      URIs and a well
                                                      defined subscription
                                                      message format (Not
                                                      sure CoAP draft is
                                                      the right place to
                                                      specify this).
                                                      - XML/EXI is too
                                                      complex to be the
                                                      required format for
                                                      the default

                                                      Hope this could help,
                                                      Matthieu

                                                      "Charles
                                                      Palmer"

                                                      "Charles Palmer"

                                                      Envoyé par :
                                                      [email-masked]
                                                      15/05/2010 14:06

                                                      A
                                                      "core"<[email-masked]>
                                                      cc
                                                      Objet
                                                      Re: [core] Selecting
                                                      a WG document for
                                                      CoAP

                                                      Dear all

                                                      Those interested in
                                                      the subscribe/notify
                                                      discussion might like
                                                      to look
                                                      at the draft Smart
                                                      Energy Profile 2.0
                                                      Application Protocol
                                                      Specification. It is
                                                      available here:

                                                      licationProfile.aspx

                                                      It manages
                                                      subscribe/notify by
                                                      using POST. This
                                                      seems to remove the
                                                      need
                                                      for SUBSCRIBE and
                                                      notify.

                                                      "Imagine a host A,
                                                      which exposes a
                                                      resource at http
                                                      {s}://A/resource and
                                                      a second host B,
                                                      which wishes to learn
                                                      of changes to this
                                                      resource. To
                                                      facilitate a
                                                      subscription/
                                                      notification
                                                      mechanism, A would
                                                      expose a
                                                      resource http
                                                      {s}://A/sub and B
                                                      would expose a
                                                      resource http
                                                      {s}://B/ntfy.
                                                      To subscribe to
                                                      notifications
                                                      regarding http
                                                      {s}://A/resource, B
                                                      would
                                                      send a POST to the
                                                      address http
                                                      {s}://A/sub/B
                                                      containing the URI of
                                                      the
                                                      resource of interest
                                                      (http
                                                      {s}://A/resource) and
                                                      the URI of B's
                                                      notification resource
                                                      (http{s}://B/ntfy).
                                                      Following this
                                                      subscription
                                                      step, should A wish
                                                      to notify B of a
                                                      change to the
                                                      resource addressed at
                                                      http{s}://A/resource,
                                                      A would send a POST
                                                      to the address
                                                      http{s}://B/ntfy
                                                      containing the URI of
                                                      the resource changed
                                                      (http
                                                      {s}://A/resource) and
                                                      the URI of A's
                                                      subscription resource
                                                      (http{s}://A/sub/B),
                                                      should A wish to
                                                      change its
                                                      subscription. The
                                                      host
                                                      B can then query the
                                                      resource (or not) at
                                                      its leisure."

                                                      Sleepy nodes are not
                                                      allowed to subscribe,
                                                      and must poll.

                                                      Regards - Charles
                                                      Palmer

                                                      -----Original
                                                      Message-----
                                                      From:
                                                      [email-masked]
                                                      [

                                                      Zach,

                                                      thanks for the
                                                      comments, but please
                                                      refer to my most
                                                      recent e-mail for
                                                      a more specific list
                                                      of technical issues
                                                      I'm pointing to.

                                                      I want to do only a
                                                      little integration to
                                                      what I've written
                                                      there.

                                                      In my very personal
                                                      opinion, to maximize
                                                      adherence with the
                                                      REST model
                                                      and minimize
                                                      implementation effort
                                                      SUBSCRIBE and NOTIFY
                                                      should be
                                                      mapped to methods (as
                                                      discussed many times
                                                      together...).

                                                      Uniform interface
                                                      principle (Fielding
                                                      PhD dissertation
                                                      Section 5.1.5,
                                                      "The central feature
                                                      that distinguishes
                                                      the REST
                                                      architectural style
                                                      [...]") states that
                                                      to simplify the
                                                      software
                                                      architecture,
                                                      resource
                                                      interfaces/interfaces
                                                      should be as general
                                                      as possible.

                                                      I agree with this
                                                      principle in this
                                                      specific case, mainly
                                                      because
                                                      handling a special
                                                      message type for
                                                      notify leads node
                                                      software design
                                                      to a more complex
                                                      architecture.

                                                      The reason is that
                                                      this new message type
                                                      requires special
                                                      handling and
                                                      introduces a
                                                      complexity in the
                                                      software
                                                      modularization.

                                                      Best,
                                                      Angelo

                                                      On Fri, May 14, 2010
                                                      at 13:06, Zach Shelby
                                                      <[email-masked]>
                                                      wrote:

                                                                  Hi
                                                                  Angelo,

                                                                  On May
                                                                  13, 2010,
                                                                  at
                                                                  14:24 ,
                                                                  Angelo P.
                                                                  Castellani
 wrote:

   Dear C. Bormann, all,

                                                      still

                                                      current

                                                                  Of course
                                                                  there are
                                                                  plenty of
                                                                  open
                                                                  issues.
                                                                  Remember
                                                                  that
                                                                  working
                                                                  group

                                                      documents still
                                                      undertake as much
                                                      change and
                                                      improvement as the WG
                                                      wants, so by no means
                                                      is coap-01 set in
                                                      stone. I would expect
                                                      at least
                                                      5-10 more revisions
                                                      still along the way.
                                                      Already several of
                                                      your ideas
                                                      have been integrated
                                                      into coap-01, and
                                                      several more are
                                                      under
                                                      consideration, so it
                                                      is coming along.
                                                      Patience ;-)

                                                                  In
                                                                  coap-01
                                                                  the
                                                                  Method
                                                                  names are
                                                                  now
                                                                  identical
                                                                  to HTTP
                                                                  methods.
                                                                  The

                                                      Req/Res interaction
                                                      is a direct
                                                      translation. The URI
                                                      hierarchy is
                                                      compatible, and the
                                                      URI binary code
                                                      format we are still
                                                      working on
                                                      obviously. The only
                                                      thing that takes some
                                                      state to translate is
                                                      Subscribe/Notify. But
                                                      note,
                                                      Subscribe/Notify
                                                      takes some state no
                                                      matter
                                                      how you do it, even
                                                      with HTTP-HTTP there
                                                      is no clean and easy
                                                      way to
                                                      handle subscriptions.

                                                                  This we
                                                                  can
                                                                  definitely

                                                      from -00 to -01. Here
                                                      I need some very
                                                      concrete proposals
                                                      though. Also
                                                      remember that many
                                                      things are optional,
                                                      for example
                                                      subscribe/notify is
                                                      not required if you
                                                      don't need it.

   Example:

                                                                  Right,
                                                                  that is
                                                                  not how
                                                                  it will
                                                                  work in
                                                                  practice.
                                                                  Working
                                                                  with a
                                                                  real

                                                      HTTP server that HTTP
                                                      header will be more
                                                      complex, and on the
                                                      CoAP side
                                                      you would chose
                                                      shorter URLs. The
                                                      biggest improvement
                                                      possible here is
                                                      from using binary
                                                      coded URLs of course.
                                                      We need to look at a
                                                      wider range
                                                      of interactions and
                                                      real HTTP headers as
                                                      well to check that we
                                                      are
                                                      efficient enough.

                                                                  I am not
                                                                  sure what
                                                                  else you
                                                                  have in
                                                                  mind for
                                                                  a). If we
                                                                  just
                                                                  forget

                                                      about
                                                      Subscribe/Notify then
                                                      you are good to go.
                                                      But then you are also
                                                      not fulfilling the
                                                      charter or the
                                                      industry needs in
                                                      that respect.

                                                                  Thanks,
                                                                  Zach

   Best regards,

   Angelo P. Castellani

                                                      April:

                                                      draft-shelby-core-coap

               for the announcement and

                                                      direction for the WG
                                                      to take?

                                                      document?

                                                      decisions you would
                                                      like the authors to
                                                      take with priority?

                                                      as editors for the
                                                      working group, making
                                                      (and usually fleshing
                                                      out the
                                                      details of) any
                                                      change that the WG
                                                      decides it needs.

                                                      to making it a WG
                                                      document.

                                                      fundamental technical
                                                      direction.

                                                      reach at a decision
                                                      on how to go forward
                                                      this week.

               Gruesse, Carsten

                                                                  --
                                                                  Zach
                                                                  Shelby,
                                                                  Chief
                                                                  Nerd,
                                                                  Sensinode
                                                                  Ltd.
                                                                  http://zachshelby.org
                                                                   - My
                                                                  blog "On
                                                                  the
                                                                  Internet
                                                                  of Things
                                                                  "
                                                                  http://6lowpan.net
 - My book "
                                                                  6LoWPAN:
                                                                  The
                                                                  Wireless
                                                                  Embedded
                                                                  Internet"
                                                                  Mobile:
                                                                  +358 40
                                                                  7796297

                                                      core mailing list
                                                      [email-masked]

                                                      Onzo is a limited
                                                      company number
                                                      06097997 registered
                                                      in England& Wales.
                                                      The
                                                      registered office is
                                                      6 Great Newport
                                                      Street, London, WC2H
                                                      7JB, United Kingdom.

                                                      This email message
                                                      may contain
                                                      confidential and/or
                                                      privileged
                                                      information, and
                                                      is intended solely
                                                      for the addressee(s).
                                                      If you have received
                                                      this email in
                                                      error, please notify
                                                      Onzo immediately.
                                                      Unauthorised copying,
                                                      disclosure or
                                                      distribution of the
                                                      material in this
                                                      email is forbidden.

                                                      core mailing list
                                                      [email-masked]

                                                      This email has been
                                                      scanned by the
                                                      MessageLabs Email
                                                      Security System.

                                                      core mailing list
                                                      [email-masked]

                              core mailing list
                              [email-masked]

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 31 May 2010 12:09:11 +0200

Zach, Robert, all,

I want add a short clarification about my previous message.

To integrate SUBSCRIBE/NOTIFY in a RESTful protocol, the entities
involved in the process should be *both* resources and not an endpoint
and a resource.

In my opinion when we talk of REST, the main concept is that every
destination of an interaction is a resource.

However SUBSCRIBE/NOTIFY interaction methods are different from the
GET/POST/PUT/etc. methods, because they're stateful by design. In its
very radical design constraints REST does not want to retain state
informations about anything.

So in my opinion to better cope with this paradoxical requirement we
should work to retain the best stateless design for a stateful
interaction.

This is the reason why when we require a SUBSCRIBE to a resource, the
resource itself should became an endpoint that has to access a
different resource (the NOTIFY resource!).

End-points in REST retain state, and for this reason the subscribed
resource has become an endpoint.

This is why I think that SUBSCRIBE/NOTIFY methods require two different URI:
 - Destination-URI (the traditional URI), that specifies the resource
destination of the interaction
 - Source-URI, that specifies the resource *source* of the interaction

Best,
Angelo