Subject: [core] NEW WEBEX for todays call (right now)

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 Jan 2011 08:13:18 -0700

Click on this link to join

https://ciscosales.webex.com/ciscosales/e.php?AT=WMI&EventID=158221677&PW=849c094c1b1d100b&RT=MiM2

---

From: tianlinyi 00175029 <[email-masked]>
Date: Wed, 26 Jan 2011 23:47:41 +0800

Hi, CoAP Folks

Peter raised a review comment as follows:
  Be clear about how different HTTP and COAP methods are. 

I think it would be good to address this issue in HTTP-COAP mapping draft. By doing this we can clarify the difference between HTTP and CoAP not only for those methods but also other features. This can also avoid the complexity of CoAP draft. The CoAP draft itself will mainly focus on how CoAP protocol works. 

Cheers,
Linyi

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 26 Jan 2011 18:39:17 +0100

> I think it would be good to address this issue in HTTP-COAP mapping draft. By doing this we can clarify the difference between HTTP and CoAP not only for those methods but also other features. This…

my idea is that there should be some text, within the CoAP draft,
that clarify the differences between the HTTP methods and the CoAP methods
so to not mislead people (implementers I should say) expert in HTTP but 
new to CoAP.

We have also be sure that what we have in CoAP draft is easily mappable 
in HTTP
through a stateless HTTP mapping as stated in the second bullet of 
Section 1.1 of coap-04

    o  A stateless HTTP mapping, allowing proxies to be built providing
       access to CoAP resources via HTTP in a uniform way or for HTTP
       simple interfaces to be realized alternatively over CoAP.

(e.g. I think there are some issues in mapping CoAP deferred response to 
HTTP)

then I don't mind if we detail how different HTTP and CoAP method are within
the CoAP draft or we bring the issue out of the CoAP draft and put in a 
new one.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jan 2011 19:26:58 +0100

On Jan 26, 2011, at 18:39, Salvatore Loreto wrote (about stateless proxies):

> I think there are some issues in mapping CoAP deferred response to HTTP

There is no difference here between immediate and deferred -- in both cases, an HTTP-to-CoAP proxy has to keep state until the response comes in.

That state is just a little less in the deferred case (there is no message layer state to keep track of most of the time we are waiting for the response).

"Stateless" here refers to the lack of need to keep hard state *between* exchanges.
(You might still want to keep a [more or less limited] cache, which is almost always going to be a good idea for this kind of intermediary.)

Gruesse, Carsten

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 27 Jan 2011 18:46:40 +0100

> That state is just a little less in the deferred case (there is no message layer state to keep track of most of the time we are waiting for the response).
the issues are in the HTTP behavior,
assume the HTTP GET is translate to a CoAP GET, and the CoAP answer is 
deferred
if the CoAP message defer time is quite large once it arrives
the probability that some timeout expired in some HTTP proxies or other 
intermediary boxes (NAT, Firewall) is quite high
so the Proxy won't be able to deliver the answer to the HTTP client

most likely the HTTP client will, after some time, issue a new GET to 
retrieve the value,
so what will be the correct proxy behavior in this scenario?

maybe for GET a [more or less limited] cache could help, as you suggest...
alternative could be sent a Retry-After header in the HTTP response 
within a safe interval time (e.g. an interval time before the timeout 
expires)

things can became more complicate if the request is not idempotent and 
the HTTP client retransmit
> (You might still want to keep a [more or less limited] cache, which is almost always going to be a good idea for this kind of intermediary.)
can you expand on what you mean to be an hard state *between* exchanges.

I think a better explanation is also necessary in the coap draft.

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 28 Jan 2011 16:49:22 +0100

Given the current design of CoAP and its differences from HTTP,
mapping is not straightforward.

If we want to keep the current CoAP design, in my opinion, the HTTP
mapping should be discussed extensively in a different document
focused on the topic.

The mapping document should be kept updated with the CoAP
specification, to highlight any possible HTTP mapping issue.

A more detailed version of my opinion follows:
################################
Section 8 of CoAP-04 addresses the basic assumptions required for HTTP mapping.

The draft says: "CoAP supports a limited subset of HTTP functionality,
and thus a mapping to HTTP is straightforward."

In my opinion, the mapping would have been straightforward only if
HTTP compatibility and mapping has been kept as primary requirement in
the CoAP design. The WG itself has always told that this should be the
approach.

However, in Section 8.1 and 8.2, the notes describe several
differences that are leading the mapping to be quite harder than
straightforward.

Example: In CoAP-04 was widely introduced the concept that each method
can receive a subset of response codes, see Sections 5.8 and 5.9. HTTP
agents (servers & clients) does not comply to this specs.

This simple difference between CoAP and HTTP will require the proxy to
keep track of the request method to identify the more suitable HTTP
status code "matching" the received CoAP response code and vice versa,
thus adding more complexity and state to the proxy itself.

In my opinion CoAP draft has mainly focus on the basic definition of a
RESTful protocol suitable for contrained devices, believing that HTTP
mapping will always be achieved through a more powerful device
(proxy/gateway).

This assumption has now lead to a protocol quite different from HTTP,
and its mapping is quite hard as
draft-castellani-core-http-coap-mapping-00 has started discussing.

For this reason I think that right now we have two different options:

A) CoAP design can be reverted to be more similar to HTTP, thus
requiring less effort in defining the HTTP mapping.

B) CoAP design can continue to identify the best REST protocol for a
contrained environment, leaving the mapping specification to an
extended document specifically focused on HTTP (and maybe other
protocols as briefly discussed on the list, e.g. XMPP).

Given the work devoted to the current CoAP definition, I prefer option
B and probably our draft (draft-castellani-core-http-coap-mapping-00)
can be extended by the working group to address all the mapping issues
between HTTP and CoAP.

If we believe in this path, I hope that the parallel definition of the
mapping will outline possible troubles, and drive the current CoAP
protocol specification to be surely lightweight but also hopefully
mappable to the traditional HTTP-based Internet through a transparent
proxy, easy to deploy and that does not require any knowledge about
the constrained WPAN.

Best,
Angelo

2011/1/26 tianlinyi 00175029 <[email-masked]>:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 31 Jan 2011 20:06:27 +0100

> protocols as briefly discussed on the list, e.g. XMPP).

+1

Klaus