Subject: [core] draft-ietf-core-coap-06 2.2 Request/ Response model....

From: Paul Duffy <[email-masked]>
Date: Fri, 06 May 2011 00:24:35 -0400

States...

"CoAP makes use of GET, PUT, POST and DELETE methods in a similar
manner to HTTP, with the semantics specified in Section 5.8. (Note
that the detailed semantics of CoAP methods are "almost, but not
entirely unlike" those of HTTP methods: Intuition taken from HTTP
experience generally does apply well, but there are enough
differences that make it worthwhile to actually read the present
specification.)"

Sort of , kind of, but not fully equivalent to HTTP?

It is not specifically clear how the methods behavior differs from those 
of HTTP, nor is this apparent from any discussion section 5.8.

Are there issues mapping these methods between HTTP and COAP?

Cheers

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 May 2011 11:05:10 +0200

> Sort of , kind of, but not fully equivalent to HTTP?

Yes.  The point of CoAP is to provide REST functionality without all the complexities of HTTP.
It is impossible to have a trivial one-to-one correspondence of features if you don't have all the features and in particular try to avoid most of the historical baggage.

The text you cite is there to alert readers that they shouldn't just assume that every little detail they know from HTTP simply transfers to CoAP.  I.e., in shorter words, "do read the spec, please".

> It is not specifically clear how the methods behavior differs from those of HTTP, nor is this apparent from any discussion section 5.8.

We seem to be oscillating between "describe CoAP as a protocol" and "describe CoAP as a diff from HTTP".
The latter is easier to access for the small number of people who really know HTTP, but is dangerous as it starts out with all of HTTPs complexities and assumptions many of which aren't there in CoAP.  So section 5 is mostly just describing CoAP and using fewer HTTP analogies than some previous versions of the description.
You have to study both protocols to derive conclusively in what details they differ.  I trust there will be research papers, websites, books, informational RFCs etc. that do this in much more detail than a spec ever could.

> Are there issues mapping these methods between HTTP and COAP?

On what level do you need this question answered?

"Are there issues" as in 
"are there tickets in the tracker that pertain to the mapping"?
Not right now -- all tickets have been closed in creating -06.
(Guido's report from yesterday will lead to a new one that also will need to address mapping.
Some of Cullen's comments might, too.
Please do report any other issues you find.)

"Are there issues" as in 
"do you need to spend more than five minutes to understand how to write a generic mapper"?
Absolutely.  That's why we have a whole section 8.  Also, Angelo and Klaus have written documents that discuss some of the more esoteric points, also about implementation.  There is plenty of interesting work in exploring this entire space.

"Are there issues" as in 
"CoAP has issues.  Don't touch it with a ten-foot pole!"?
Most people in this WG have an opinion on this :-)

Gruesse, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Fri, 06 May 2011 10:18:02 -0400

"On what level do you need this question answered?"

Specifics re: where the COAP methods diverge from HTTP semantics.  The text non specifically suggests there are differences, refers to another section, and does not address the issue.

Ultimately what I'm after are any special details that need to be handled by a COAP/HTTP translation.

Cheers

---

From: "Charles Palmer" <[email-masked]>
Date: Fri, 6 May 2011 15:43:44 +0100

One approach would be to take the GET, PUT, POST and DELETE text from RFC2616, edit this text and place it into CoAP. The edit could be done in such a way that where HTTP and CoAP were the same the text stayed the same; and where there was a difference (and only then) the text would be changed. This would have the advantage of obliging the CoAP authors to think carefully about the similarities and differences. Comparison of the two documents would allow facilitate HTTP/CoAP translation etc.

I would also be more comfortable if the same could be done with the response codes, which again are expressed in terms of their similarity, or otherwise, with RFC2616.

I guess it depends on your philiosphical view as to whether it is better to refer to other documents or to replicate their text.

-----Original Message-----
From: [email-masked] on behalf of Paul Duffy
Sent: Fri 06/05/2011 15:18
To: Carsten Bormann
Cc: core
Subject: Re: [core] draft-ietf-core-coap-06 2.2 Request/ Response model....

Cheers

> Most people in this WG have an opinion on this :-)

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

--------------------------------
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: Carsten Bormann <[email-masked]>
Date: Fri, 6 May 2011 17:37:38 +0200

On May 6, 2011, at 16:43, Charles Palmer wrote:

> One approach would be to take the GET, PUT, POST and DELETE text from RFC2616

But that text is obsolete.
If you think you know what HTTP is, you won't necessarily find it in RFC2616.
That text is being fixed in HTTPBIS, but that is an ongoing process.
We can't wait with CoAP until HTTPBIS is done.
We also don't have to, as CoAP is much simpler.

So the consensus so far was to not import large gobs of text from either RFC2616 or the HTTPBIS drafts.
(see, e.g., http://www.ietf.org/mail-archive/web/core/current/msg01326.html).
We are violating this a bit in the response codes, as it is indeed simpler to just reference them from HTTP (and there are some that haven't changed much since RFC 2616).

> This would have the advantage of obliging the CoAP authors to think carefully about the similarities and differences. 

I can assure you all of them already feel obliged to do that...
We just don't feel obliged to recreate every nook and cranny of HTTP in CoAP.
CoAP is a REST protocol, not an HTTP emulator.

> Comparison of the two documents would allow facilitate HTTP/CoAP translation etc.

Yes.  Please do.
(There seems to be an underlying assumption in the previous messages as if there was going to be a standard way to map the two protocols.  Not so.  How you map depends a lot on what your implementation is trying to do, e.g., whether it has a cache, what it optimizes for, etc.  Specifying all these implementation variants in a protocol spec would be rather elusive and ultimately futile.  What we probably should specify is what we expect a (forward) proxy to do.  That's section 8.  There are also lots of other intermediaries that you can cook up that will do interesting things.  All outside the scope.)

Gruesse, Carsten