Subject: [core] HTTP and CoAP - mapping and compression

From: Gilman Tolle <[email-masked]>
Date: Mon, 5 Apr 2010 12:38:48 -0700

I have a question about the HTTP<->CoAP mapping we're chartered to  
define...

Because the operations in draft-shelby-core-coap-00 are different from  
the standard HTTP methods, I'd suggest that any mapping is likely to  
lead to a leaky abstraction between the two protocols. In addition, a  
mapping could become a source of divergence between CoAP and HTTP as  
further innovation happens in these two separate spaces.

Do the CoAP protocol operations really need to be different from the  
HTTP protocol operations?

If we think about this as a compression problem instead of a mapping  
problem, we could define CoAP as semantically identical to HTTP, but  
with a more compact concrete representation. Because we're running in  
constrained networks, we don't have to maintain every arbitrary HTTP  
optional header across the compression boundary, but we can easily  
maintain the core protocol operations and naming systems that make  
HTTP so powerful. Essentially, we'd be defining the CoAP protocol as  
an easily-compressible profile of HTTP along with a stateless  
transformation between the compressed and uncompressed versions.

I'd like to point everyone to my EBHTTP draft (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00 
), which presents an alternative compressed-HTTP approach to the  
design of CoAP (as does the original Chopan draft, for that matter).

I think there are a few other benefits of EBHTTP worth considering:

* automatic stateless transcoding between EBHTTP and HTTP allows us to  
define upper layers (representation, discovery) once, but have them  
apply to both kinds of protocols
* allowing multiple EBHTTP requests to be packed into a single UDP  
message can increase the overall message efficiency
* EBHTTP can run over both UDP datagrams and TCP persistent connections
* having a "response-is-optional" header flag allows for more  
efficient unreliable message delivery and enables multicast message  
delivery
* making the sequence number/transaction id into an option means that  
we don't pay the sequence number overhead when we don't need it

If we take a compression approach instead of a mapping approach, we  
still might be introducing abstraction leakage around the size of the  
resources and the choice of optional HTTP headers that are allowed to  
make it through the compression process, but at least the basic  
protocol transformation will remain sound and able to take advantage  
of future progress in HTTP.

Gil

---

From: Kris Pister <[email-masked]>
Date: Mon, 05 Apr 2010 13:21:24 -0700

+1

Gilman Tolle wrote:
> I'd like to point everyone to my EBHTTP draft 
> (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which 
> presents an alternative compressed-HTTP approach to the design of CoAP 
> (as does the original Chopan draft, for that matter).
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Tue, 6 Apr 2010 00:12:39 +0300

Hi Gil,

At the WG meeting (and in the hallways) we actually discussed using standard GET, PUT, POST, DELETE method names in the next version of the CoAP draft. Semantically they are already very, very close. I have no problem with that suggestion (that is actually how we started out).

Some of the features you listed below I would surely be open to discussing for integration into our CoAP specification - they are already close in header and functionality. Let's discuss that! Sorry I haven't been able to give comments on your draft yet, recovering from the IETF takes some time...

Regarding Chopan, we have been working with Brian to integrate the ideas from Chopan for quite a while already. In fact CoAP is a combination of Chopan and a simple REST design from a clean slate. We had long discussions on the 6lowapp list during chartering about compressing HTTP, and my conclusion was that we should not do that (and are not chartered to do that). The protocol we design in CoRE should be pure to the REST architecture and semantics which are behind HTTP. If we are also smart about re-using a subset of HTTP codes etc. then I don't see that a CoAP conversion to HTTP would be more difficult than compression/decompression (it should be simpler). So our goal is the same here, we just took a clean slate approach to find the fundamental features behind HTTP.

Zach

On Apr 5, 2010, at 22:38 , Gilman Tolle wrote:

> I have a question about the HTTP<->CoAP mapping we're chartered to define...
> 
> Because the operations in draft-shelby-core-coap-00 are different from the standard HTTP methods, I'd suggest that any mapping is likely to lead to a leaky abstraction between the two protocols. In addition, a mapping could become a source of divergence between CoAP and HTTP as further innovation happens in these two separate spaces.
> 
> Do the CoAP protocol operations really need to be different from the HTTP protocol operations?
> 
> If we think about this as a compression problem instead of a mapping problem, we could define CoAP as semantically identical to HTTP, but with a more compact concrete representation. Because we're running in constrained networks, we don't have to maintain every arbitrary HTTP optional header across the compression boundary, but we can easily maintain the core protocol operations and naming systems that make HTTP so powerful. Essentially, we'd be defining the CoAP protocol as an easily-compressible profile of HTTP along with a stateless transformation between the compressed and uncompressed versions.
> 
> I'd like to point everyone to my EBHTTP draft (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which presents an alternative compressed-HTTP approach to the design of CoAP (as does the original Chopan draft, for that matter).
> 
> * automatic stateless transcoding between EBHTTP and HTTP allows us to define upper layers (representation, discovery) once, but have them apply to both kinds of protocols
> * allowing multiple EBHTTP requests to be packed into a single UDP message can increase the overall message efficiency
> * having a "response-is-optional" header flag allows for more efficient unreliable message delivery and enables multicast message delivery
> * making the sequence number/transaction id into an option means that we don't pay the sequence number overhead when we don't need it
> 
> If we take a compression approach instead of a mapping approach, we still might be introducing abstraction leakage around the size of the resources and the choice of optional HTTP headers that are allowed to make it through the compression process, but at least the basic protocol transformation will remain sound and able to take advantage of future progress in HTTP.
> 
> Gil
> 

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

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

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: Brian Frank <[email-masked]>
Date: Mon, 5 Apr 2010 19:34:01 -0400

Its not really just about compressing HTTP as-is, but the harder issue is
defining the subset of HTTP that is used (because few 6lowpan devices can
really support it all).  And even then it probably isn't a clean subset.
 For example the host header is required in HTTP, but we probably don't want
to require it in CoAP.

So after giving a lot of thought to how HTTP mapping happens with Chopan, I
lean towards saying CoAP is something new with a well defined scope.
 Perhaps we may reference semantics in the HTTP spec, but wouldn't derive
from it.  I suspect a new separate path will actually make for a better
mapping at the HTTP gateway.

But then again I can see the reverse position that the HTTP mapping becomes
a key aspect of our spec, in which case we are effectively defining a HTTP
subset anyhow.

On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby <[email-masked]> wrote:

> Hi Gil,
>
> At the WG meeting (and in the hallways) we actually discussed using
> standard GET, PUT, POST, DELETE method names in the next version of the CoAP
> draft. Semantically they are already very, very close. I have no problem
> with that suggestion (that is actually how we started out).
>
> Some of the features you listed below I would surely be open to discussing
> for integration into our CoAP specification - they are already close in
> header and functionality. Let's discuss that! Sorry I haven't been able to
> give comments on your draft yet, recovering from the IETF takes some time...
>
> Regarding Chopan, we have been working with Brian to integrate the ideas
> from Chopan for quite a while already. In fact CoAP is a combination of
> Chopan and a simple REST design from a clean slate. We had long discussions
> on the 6lowapp list during chartering about compressing HTTP, and my
> conclusion was that we should not do that (and are not chartered to do
> that). The protocol we design in CoRE should be pure to the REST
> architecture and semantics which are behind HTTP. If we are also smart about
> re-using a subset of HTTP codes etc. then I don't see that a CoAP conversion
> to HTTP would be more difficult than compression/decompression (it should be
> simpler). So our goal is the same here, we just took a clean slate approach
> to find the fundamental features behind HTTP.
>
> Zach
>
> the standard HTTP methods, I'd suggest that any mapping is likely to lead to
> a leaky abstraction between the two protocols. In addition, a mapping could
> become a source of divergence between CoAP and HTTP as further innovation
> happens in these two separate spaces.
> >
> problem, we could define CoAP as semantically identical to HTTP, but with a
> more compact concrete representation. Because we're running in constrained
> networks, we don't have to maintain every arbitrary HTTP optional header
> across the compression boundary, but we can easily maintain the core
> protocol operations and naming systems that make HTTP so powerful.
> Essentially, we'd be defining the CoAP protocol as an easily-compressible
> profile of HTTP along with a stateless transformation between the compressed
> and uncompressed versions.
> >
> > I'd like to point everyone to my EBHTTP draft (
> http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which presents an
> alternative compressed-HTTP approach to the design of CoAP (as does the
> original Chopan draft, for that matter).
> >
> define upper layers (representation, discovery) once, but have them apply to
> both kinds of protocols
> > * having a "response-is-optional" header flag allows for more efficient
> unreliable message delivery and enables multicast message delivery
> > * making the sequence number/transaction id into an option means that we
> don't pay the sequence number overhead when we don't need it
> >
> > If we take a compression approach instead of a mapping approach, we still
> might be introducing abstraction leakage around the size of the resources
> and the choice of optional HTTP headers that are allowed to make it through
> the compression process, but at least the basic protocol transformation will
> remain sound and able to take advantage of future progress in HTTP.
> >
> > Gil
> >
> This e-mail and all attached material are confidential and may contain
> legally privileged information. If you are not the intended recipient,
> please contact the sender and delete the e-mail from your system without
> producing, distributing or retaining copies thereof.
>
>
>
>

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 6 Apr 2010 10:10:14 -0700

I agree, defining a subset is much more valuable than defining a
compression, and that CoAP is something new that ought to steal many things
from HTTP.

Defining a mapping of HTTP for gateways to use can reasonably done in the
scale I understand gateways to have.  But that means that gateways have to
deal with the "deployed reality" of HTTP, which is pretty bad in terms of
compliance to the HTTP spec and documented interoperability (although it is
even worse when you add in HTML and cookies).  That tradeoff seems
reasonable -- requiring complex functionality in a node that can handle it
in order to get some very useful features.

Defining a compression of HTTP for the more constrained devices?  Not so
helpful.   I wrote up my thoughts in more detail
here<http://nih.blogspot.com/2010/04/its-not-entirely-intuitive-but-same.html>.

Lisa

On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank <[email-masked]> wrote:

>> resources and the choice of optional HTTP headers that are allowed to make
>> it through the compression process, but at least the basic protocol
>> transformation will remain sound and able to take advantage of future
>> progress in HTTP.
>> >
>> > Gil
>> >

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Apr 2010 21:54:21 +0200

On Apr 5, 2010, at 21:38, Gilman Tolle wrote:

> leaky abstraction 

Would that be a problem?  If yes, please explain how, best with an example.
(Would the mapping need to behave as if it were an abstraction at all?)

As far as I understand the point of the mapping, this is not about looking at a temp sensor with Firefox.
It is about using HTTP to access CoAP-enabled devices.
(Not in the sense of mis-using HTTP as a transport.
But the resources visible on the HTTP side might be recognizably CoAPy, which as you say they are likely to be in any case because of the message size limitations on the side of the constrained network.)

There is no fundamental difference in the achievable result space between
-- designing CoAP,
-- compressing, restricting, modifying, reinterpreting, and extending HTTP until we arrive at CoAP.
Except that the latter, processwise, is likely to lead to more complexity.
(Some of us still have the scars from making SIP almost, but not entirely, unlike HTTP.)

Gruesse, Carsten

(No WG chair hats were hurt in creating this message.)

---

From: Robert Cragie <[email-masked]>
Date: Wed, 07 Apr 2010 17:14:25 +0100

I think a big issue is not regarding the syntactic mapping and 
compression, but the transaction mapping of what is being proposed as a 
'quasi-synchronous' protocol to synchronous HTTP. Obviously it is 
straightforward to map synchronous transactions but if asynchronous 
transactions take place in the CoAP environment, they are not going to 
statelessly map onto synchronous HTTP. So the 'CoGII' (or whatever it 
was called) may resurface and may need to be defined.

On the same topic, I still don't see the need for NOTIFY in the current 
specification. Define the concept of clients with subscription agents 
(i.e. in a server role) and either define a comprehensive callback 
subscription mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL or take 
it out completely and define using the CRUD methods. I prefer the latter.

Robert

Robert Cragie (Pacific Gas & Electric)

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

On 06/04/2010 6:10 PM, Lisa Dusseault wrote:
> compression, and that CoAP is something new that ought to steal many 
> things from HTTP.
>
> Defining a mapping of HTTP for gateways to use can reasonably done in 
> the scale I understand gateways to have.  But that means that gateways 
> have to deal with the "deployed reality" of HTTP, which is pretty bad 
> in terms of compliance to the HTTP spec and documented 
> interoperability (although it is even worse when you add in HTML and 
> cookies).  That tradeoff seems reasonable -- requiring complex 
> functionality in a node that can handle it in order to get some very 
> useful features.
>
> Defining a compression of HTTP for the more constrained devices?  Not 
> so helpful.   I wrote up my thoughts in more detail here 
> <http://nih.blogspot.com/2010/04/its-not-entirely-intuitive-but-same.html> 
> .
>
> Lisa
>
> On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Its not really just about compressing HTTP as-is, but the harder
>     issue is defining the subset of HTTP that is used (because few
>     6lowpan devices can really support it all).  And even then it
>     probably isn't a clean subset.  For example the host header is
>     required in HTTP, but we probably don't want to require it in CoAP.
>
>     So after giving a lot of thought to how HTTP mapping happens with
>     Chopan, I lean towards saying CoAP is something new with a well
>     defined scope.  Perhaps we may reference semantics in the HTTP
>     spec, but wouldn't derive from it.  I suspect a new separate path
>     will actually make for a better mapping at the HTTP gateway.
>
>     But then again I can see the reverse position that the HTTP
>     mapping becomes a key aspect of our spec, in which case we are
>     effectively defining a HTTP subset anyhow.
>
>
>     On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi Gil,
>
>         At the WG meeting (and in the hallways) we actually discussed
>         using standard GET, PUT, POST, DELETE method names in the next
>         version of the CoAP draft. Semantically they are already very,
>         very close. I have no problem with that suggestion (that is
>         actually how we started out).
>
>         Some of the features you listed below I would surely be open
>         to discussing for integration into our CoAP specification -
>         they are already close in header and functionality. Let's
>         discuss that! Sorry I haven't been able to give comments on
>         your draft yet, recovering from the IETF takes some time...
>
>         Regarding Chopan, we have been working with Brian to integrate
>         the ideas from Chopan for quite a while already. In fact CoAP
>         is a combination of Chopan and a simple REST design from a
>         clean slate. We had long discussions on the 6lowapp list
>         during chartering about compressing HTTP, and my conclusion
>         was that we should not do that (and are not chartered to do
>         that). The protocol we design in CoRE should be pure to the
>         REST architecture and semantics which are behind HTTP. If we
>         are also smart about re-using a subset of HTTP codes etc. then
>         I don't see that a CoAP conversion to HTTP would be more
>         difficult than compression/decompression (it should be
>         simpler). So our goal is the same here, we just took a clean
>         slate approach to find the fundamental features behind HTTP.
>
>         Zach
>
>         > Because the operations in draft-shelby-core-coap-00 are
>         different from the standard HTTP methods, I'd suggest that any
>         mapping is likely to lead to a leaky abstraction between the
>         two protocols. In addition, a mapping could become a source of
>         divergence between CoAP and HTTP as further innovation happens
>         in these two separate spaces.
>         >
>         > If we think about this as a compression problem instead of a
>         mapping problem, we could define CoAP as semantically
>         identical to HTTP, but with a more compact concrete
>         representation. Because we're running in constrained networks,
>         we don't have to maintain every arbitrary HTTP optional header
>         across the compression boundary, but we can easily maintain
>         the core protocol operations and naming systems that make HTTP
>         so powerful. Essentially, we'd be defining the CoAP protocol
>         as an easily-compressible profile of HTTP along with a
>         stateless transformation between the compressed and
>         uncompressed versions.
>         >
>         presents an alternative compressed-HTTP approach to the design
>         of CoAP (as does the original Chopan draft, for that matter).
>         >
>         > * automatic stateless transcoding between EBHTTP and HTTP
>         allows us to define upper layers (representation, discovery)
>         once, but have them apply to both kinds of protocols
>         > * allowing multiple EBHTTP requests to be packed into a
>         single UDP message can increase the overall message efficiency
>         > * having a "response-is-optional" header flag allows for
>         more efficient unreliable message delivery and enables
>         multicast message delivery
>         > * making the sequence number/transaction id into an option
>         means that we don't pay the sequence number overhead when we
>         don't need it
>         >
>         > If we take a compression approach instead of a mapping
>         approach, we still might be introducing abstraction leakage
>         around the size of the resources and the choice of optional
>         HTTP headers that are allowed to make it through the
>         compression process, but at least the basic protocol
>         transformation will remain sound and able to take advantage of
>         future progress in HTTP.
>         >
>         > Gil
>         >
>         > [email-masked] <mailto:[email-masked]>
>         This e-mail and all attached material are confidential and may
>         contain legally privileged information. If you are not the
>         intended recipient, please contact the sender and delete the
>         e-mail from your system without producing, distributing or
>         retaining copies thereof.
>
>
>
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Thu, 8 Apr 2010 08:16:15 +0200

> I think a big issue is not regarding the syntactic mapping and compression, but the transaction mapping of what is being proposed as a 'quasi-synchronous' protocol to 

> synchronous HTTP. Obviously it is straightforward to map synchronous transactions but if asynchronous transactions take place in the CoAP environment, they are not

> going to statelessly map onto synchronous HTTP. So the 'CoGII' (or whatever it was called) may resurface and may need to be defined.

My opinion here is we do not need to resurface the 'CoGII' (or whatever it was called). CoAP spec does not need to define an interworking device. I think we need for a separate CoAP-HTTP spec where define exactly both the syntactic and semantic mapping among two protocols.

> On the same topic, I still don't see the need for NOTIFY in the current specification. Define the concept of clients with subscription agents (i.e. in a server role) and either

> define a comprehensive callback subscription mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL or take it out completely and define using the CRUD methods.

> I prefer the latter.

The point here is that CoAP needs for asynch methods due to the nature of its domain. We can choose to use any combination of CRUD methods to simulate an asynch data delivery or define a specific asynch methods but this does not change the point.

Adriano

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: mercoledì 7 aprile 2010 18.14
To: [email-masked]
Subject: Re: [core] HTTP and CoAP - mapping and compression

I think a big issue is not regarding the syntactic mapping and compression, but the transaction mapping of what is being proposed as a 'quasi-synchronous' protocol to synchronous HTTP. Obviously it is straightforward to map synchronous transactions but if asynchronous transactions take place in the CoAP environment, they are not going to statelessly map onto synchronous HTTP. So the 'CoGII' (or whatever it was called) may resurface and may need to be defined.

On the same topic, I still don't see the need for NOTIFY in the current specification. Define the concept of clients with subscription agents (i.e. in a server role) and either define a comprehensive callback subscription mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL or take it out completely and define using the CRUD methods. I prefer the latter.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

I agree, defining a subset is much more valuable than defining a compression, and that CoAP is something new that ought to steal many things from HTTP.

Defining a mapping of HTTP for gateways to use can reasonably done in the scale I understand gateways to have.  But that means that gateways have to deal with the "deployed reality" of HTTP, which is pretty bad in terms of compliance to the HTTP spec and documented interoperability (although it is even worse when you add in HTML and cookies).  That tradeoff seems reasonable -- requiring complex functionality in a node that can handle it in order to get some very useful features. 

Defining a compression of HTTP for the more constrained devices?  Not so helpful.   I wrote up my thoughts in more detail here <http://nih.blogspot.com/2010/04/its-not-entirely-intuitive-but-same.html>  .

Lisa

Its not really just about compressing HTTP as-is, but the harder issue is defining the subset of HTTP that is used (because few 6lowpan devices can really support it all).  And even then it probably isn't a clean subset.  For example the host header is required in HTTP, but we probably don't want to require it in CoAP. 

So after giving a lot of thought to how HTTP mapping happens with Chopan, I lean towards saying CoAP is something new with a well defined scope.  Perhaps we may reference semantics in the HTTP spec, but wouldn't derive from it.  I suspect a new separate path will actually make for a better mapping at the HTTP gateway.

But then again I can see the reverse position that the HTTP mapping becomes a key aspect of our spec, in which case we are effectively defining a HTTP subset anyhow.

Hi Gil,

Zach

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

---

From: Zach Shelby <[email-masked]>
Date: Thu, 8 Apr 2010 16:21:30 +0300

> I think a big issue is not regarding the syntactic mapping and compression, but the transaction mapping of what is being proposed as a 'quasi-synchronous' protocol to synchronous HTTP. Obviously it…

That is a good point, CoAP is required to support an asynchronous push model in addition to the typical synchronous model that HTTP uses. This is part of the HTTP mapping description, which could be realized in some COGII type thing. We don't need to define a COGII, just a mapping (which correctly will involve state). There will be multiple ways to realize this on the HTTP side including polling, long poll and other new bi-directional techniques. We'll need to explore and discuss those... 

> On the same topic, I still don't see the need for NOTIFY in the current specification. Define the concept of clients with subscription agents (i.e. in a server role) and either define a comprehensi…

True, it could be possible to realize the notification mechanism overloading a CRUD method. This gets more difficult if we start calling those GET, POST, PUT, DELETE. Sending a NOTIFY has very different semantics to the way synchronous methods work today. Also remember that notifications can be sent also without a subscription (unsolicited notification). The meaning of the URL in a notification is also inversed - as you are notifying about a resource on the initiating server, so the URL actually refers to a resource on the initiating node! Wouldn't it be pretty confusing to overload that with existing methods? This is the reasoning why it is a separate method. We did consider having subscribe/unsubscribe methods at some point, but wanted to minimize the number of methods. Plus these are fairly easy to design in a RESTful manner.   

Zach

> http://www.gridmerge.com
>> Defining a compression of HTTP for the more constrained devices?  Not so helpful.   I wrote up my thoughts in more detail here .
>> 
>> Lisa
>> 

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

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Thu, 8 Apr 2010 17:37:56 +0200

> Also remember that notifications can be sent also without a subscription (unsolicited notification).

Unsolicited notifications mean static (implicit or pre-provisioned) subscriptions. If we need for dynamic (explicit or on-request) notifications, the explicit Subscribe/Unsubscribe methods may be more useful, especially in the mobile/nomadic scenarios.

Adriano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: giovedì 8 aprile 2010 15.22
To: [email-masked]
Cc: [email-masked]
Subject: Re: [core] HTTP and CoAP - mapping and compression

Zach

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

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Apr 2010 16:47:10 +0100

Hi Zach,

Comments inline, bracketed by <RCC></RCC>.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

> That is a good point, CoAP is required to support an asynchronous push model in addition to the typical synchronous model that HTTP uses. This is part of the HTTP mapping description, which could b…
<RCC>I agree, the mapping should be sufficient if you include the 
stateful aspect.</RCC>
> True, it could be possible to realize the notification mechanism overloading a CRUD method. This gets more difficult if we start calling those GET, POST, PUT, DELETE. Sending a NOTIFY has very diff…
<RCC>
The way I see it is that NOTIFY doesn't fit in terms of abstraction:

(1) CoAP message
       ^
       |
(2) Request/response
       ^
       |
(3) CRUD methods

NOTIFY is defined at level (3) but really belongs at level (2), as it is 
just a message distinct from request/response from A to B without any 
further implied meaning other than what's in the payload. Even then, the 
use of request/response suggests synchronisation, but a request with the 
A bit clear doesn't require it so becomes very similar to a notify.

I don't see how an unsolicited notification to a URL is any different to 
an UPDATE. If it's unsolicited, the URL bears no obvious relationship to 
any initiating client, therefore it can be treated as a server. A 
solicited NOTIFY would be better served with an asynchronous READ 
request/response; the response is then clearly tagged to what solicited it.

Anyway, just some food for thought. I'm not going to get too hung up 
about this :-)
</RCC>

> Zach
>
>    
>> Robert
>> Robert Cragie (Pacific Gas&  Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com
>>
>>
>>> On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank<[email-masked]>  wrote:
>>> On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby<[email-masked]>  wrote:
>>> Hi Gil,
>>>

---

From: Zach Shelby <[email-masked]>
Date: Thu, 8 Apr 2010 23:11:19 +0300

On Apr 8, 2010, at 18:47 , Robert Cragie wrote:

> NOTIFY is defined at level (3) but really belongs at level (2), as it is just a message distinct from request/response from A to B without any further implied meaning other than what's in the payload. Even then, the use of request/response suggests synchronisation, but a request with the A bit clear doesn't require it so becomes very similar to a notify.

Got you. Sure, we could think about notification as a feature of req/res. I had considered that at some point, and even making an explicit notification message type. In agree we can live with just req/res messages though. 

> 
> I don't see how an unsolicited notification to a URL is any different to an UPDATE. If it's unsolicited, the URL bears no obvious relationship to any initiating client, therefore it can be treated as a server.

Any notification, even unsolicited, should be about a resource of the sender of the notification. I think this is more about REST modeling of notifications about resources and subscription rather than a transport protocol issue. Maybe we should approach this by designing how RESTful notification and subscription should function - and then figure out how to realize it in CoAP?

> A solicited NOTIFY would be better served with an asynchronous READ request/response; the response is then clearly tagged to what solicited it.

This is equivalent to an HTTP long poll. The request would stay open (not yet responded to) until there is a change/period at which point a response is sent. Would that cause any problem with transaction IDs for very long polls, and would this be a one-off mechanism or can a single request have more than one response? 

> 
> Anyway, just some food for thought. I'm not going to get too hung up about this :-)

No problem, useful discussion! I myself am pretty neutral on how to solve this one, we just need to find something that works. 

Zach

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

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 8 Apr 2010 19:31:35 -0700

<RCC>

> further implied meaning other than what's in the payload. Even then, the use
> of request/response suggests synchronisation, but a request with the A bit
> clear doesn't require it so becomes very similar to a notify.
>
> I don't see how an unsolicited notification to a URL is any different to an
> UPDATE. If it's unsolicited, the URL bears no obvious relationship to any
> initiating client, therefore it can be treated as a server. A solicited
> NOTIFY would be better served with an asynchronous READ request/response;
> the response is then clearly tagged to what solicited it.
>
That's an excellent point.  The CRUD operation on the resource might be PUSH
(or Reverse PUT, containing the resource representation in a broadcast or
unicast) or CHANGED (containing no body) but just NOTIFY is a transfer
semantic.

Lisa

---

From: Brian Frank <[email-masked]>
Date: Fri, 9 Apr 2010 08:48:07 -0400

Regarding async notification, lets keep in mind that existing HTTP
application level protocols such as oBIX and OPC-UA already have a
subscription and notification model (both using polls, potentially
long-polls).

On Thu, Apr 8, 2010 at 10:31 PM, Lisa Dusseault <[email-masked]>wrote:

>> an UPDATE. If it's unsolicited, the URL bears no obvious relationship to any
> That's an excellent point.  The CRUD operation on the resource might be
> PUSH (or Reverse PUT, containing the resource representation in a broadcast
> or unicast) or CHANGED (containing no body) but just NOTIFY is a transfer
> semantic.
>
> Lisa
>

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 9 Apr 2010 06:58:40 -0700

oBIX is an inappropriate technology for constrained devices.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Frank
Sent: Friday, April 09, 2010 5:48 AM
To: Lisa Dusseault
Cc: [email-masked]
Subject: Re: [core] HTTP and CoAP - mapping and compression

On Thu, Apr 8, 2010 at 10:31 PM, Lisa Dusseault <[email-masked]>
wrote:

<RCC>

(1) CoAP message
      ^
      |
(2) Request/response
      ^
      |
(3) CRUD methods

Anyway, just some food for thought. I'm not going to get too hung up about
this :-)
</RCC>

Lisa

---

From: Brian Frank <[email-masked]>
Date: Fri, 9 Apr 2010 19:22:50 -0400

Actually oBIX 1.1 defines a binary encoding, that makes oBIX quite well
suited to 6LoWPAN devices.  I would certainly hope that the resulting COAP
protocol will allow transparent mapping from XML/HTTP obix to binary/COAP
obix at the gateway.

On Fri, Apr 9, 2010 at 9:58 AM, Don Sturek <[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Brian Frank
> *Sent:* Friday, April 09, 2010 5:48 AM
> *To:* Lisa Dusseault
>
> *Cc:* [email-masked]
> *Subject:* Re: [core] HTTP and CoAP - mapping and compression
>
>
>

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 9 Apr 2010 16:55:03 -0700

Ah, my experience was with oBIX 1.0.  I will have a look.

In general, I think the RPC, SOAP mechanisms are a challenge for small
devices.  I am pretty hopeful that a REST architecture is the right solution
for CoRE.  I think at some point we need to recognize we are working on an
attribute protocol (REST) focused on data exchange versus a remote procedure
call type mechanism.  That said, offering a well known mapping between the
two works for me as well (as long as the REST solution is not encumbered).

Don

From: Brian Frank [mailto:[email-masked]] 
Sent: Friday, April 09, 2010 4:23 PM
To: [email-masked]
Cc: Lisa Dusseault; [email-masked]
Subject: Re: [core] HTTP and CoAP - mapping and compression

Don

Cc: [email-masked]

<RCC>

(1) CoAP message
      ^
      |
(2) Request/response
      ^
      |
(3) CRUD methods

Lisa