Subject: [core] Thoughts on HTTP Mapping

From: Klaus Hartke <[email-masked]>
Date: Sun, 06 Mar 2011 15:23:52 +0100

After spending some time thinking about interfacing CoAP with HTTP
 and vice versa, I'm coming to believe that we might be approaching
 the problem from the wrong angle.

 First some terminology:

 * An HTTP/CoAP proxy is an intermediary that sits between the HTTP
   client and the CoAP origin server. In order to get content from
   the origin server, the client sends an HTTP request to the proxy
   naming the CoAP server as the target. The proxy then requests the
   content from the CoAP server and returns it to the client, doing
   any necessary translations. The client must be specially
   configured to use the proxy.

 * An HTTP/CoAP reverse proxy, by contrast, appears to the client
   just like an ordinary web server. No special configuration on the
   client is necessary. The client makes HTTP requests for content
   in the name-space of the reverse proxy. The reverse proxy then
   decides where to send those requests and returns the content as
   if it was itself the origin, doing any necessary translations.

 * A CoAP/HTTP proxy sits between the CoAP client and the HTTP
   origin server. The client sends a CoAP request to the proxy
   naming the HTTP server as the target. The proxy requests the
   content from the HTTP server and returns it to the client.

 * A CoAP/HTTP reverse proxy appears like an ordinary CoAP server.
   The client makes CoAP requests for content in the name-space of
   the reverse proxy. The reverse proxy decides where to send those
   requests and returns the content as if it was itself the origin.

 Discussions so far have revolved around all four cases, with more
 focus on what such proxies need to do rather than what needs to be
 standardized to ensure interoperability.

 In the reverse proxy cases, I don't think we need to standardize
 anything. The fact that a reverse proxy happens to map some or all
 resources in its name-space to remote locations is transparent to
 the client, and how the mapping is actually performed is up to the
 reverse proxy's implementation.

 In the forward proxy cases, I think we might improve by asking
 a slightly different question. So far, the question we tried to
 answer was:

    Given an HTTP request, how do we translate it to a CoAP request?
    And how do we translate the resulting CoAP response back to an
    HTTP response?

 This led us to think about mapping tables between status codes and
 response codes (see coap-04), complex state machines and ugly hacks
 to map features that have no direct equivalent.

 But do we actually need to standardize all of this?

 What parts of HTTP/CoAP proxying and CoAP/HTTP proxying need to be
 standardized and what parts are implementation details?

 I propose to change the focus a bit and ask the following question:

    When an HTTP/CoAP proxy receives an HTTP request with a CoAP
    URI in the Request-Line, what's the HTTP response that the
    proxy is expected to return to the client?

    How the proxy actually satisfies the request to produce the
    expected response is up to the proxy's implementation.

 This makes it easy to say what needs to be standardized and what's
 an implementation detail. It also answers a lot of questions that
 were somewhat difficult to answer so far.

 Two examples.

 Before:
    How do we translate an HTTP request with a Range header field
    to a CoAP request?

 coap-04 currently doesn't say anything about this. The answer
 probably involves several SHOULDs and MUSTs, a complex state
 machine and many things that need to be considered before we come
 up with a complete answer.

 After:
    What's the expected HTTP response when performing an HTTP
    request with a Range header field on a CoAP URI?

 This question is much easier to answer. In fact, I can give the
 answer right away, and I'm fairly sure that this is the complete
 answer.

 Answer:
    The response contains only the requested range of the represen-
    tation of the CoAP resource representation, as defined by HTTP.
    How the range is obtained is up to the implementation, e.g., if
    the proxy obtains the full representation from the origin server
    and returns just the requested range, or if it uses the Block
    Option to obtain only the required block(s) to satisfy the
    request.

 Before:
    How do we translate a CoAP request with an Observation-Lifetime
    Option to an HTTP request?

 After:
    What are the expected CoAP responses when performing an CoAP
    request with an Observation-Lifetime Option on an HTTP URI?

 Answer:
    If the proxy is able to determine when the target HTTP resource
    changes its state, the proxy should establish an observation
    relationship to the HTTP resource and notify the client whenever
    the state of the resource changes. If the proxy is not able to
    determine when the resource changes, then the request should
    fall back to an ordinary CoAP request. How the proxy determines
    when the target HTTP resource changes, is up to the proxy's
    implementation.

 That said, it would of course be nice if there was some informative
 text on possible proxy and reverse proxy implementations. But I
 don't think this is something that needs to happen in draft-ietf-
 core-coap.

 Klaus

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Sun, 6 Mar 2011 22:07:27 +0100

Klaus,

I agree with you that HTTP/CoAP mapping should be standardized from a
"result" point of view and not from a "process" point of view.

As you know, in a constrained environment implementation issues should
be considered in advance to avoid obtaining a formally correct design
that however could not be implemented in a real world environment.

In my opinion there is still no agreement in the WG about the
acceptable level of complexity that can be left to implement a
CoAP/HTTP proxy.

My opinion is that also HTTP/CoAP proxying should be made as simple
and transparent as possible.

Best,
Angelo

On Sun, Mar 6, 2011 at 15:23, Klaus Hartke <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 8 Mar 2011 18:33:11 +0200

> acceptable level of complexity that can be left to implement a

I do not consider this to be a very constrained device. Considering the amount of networking complexity needed on the HTTP side including security etc. along with typical placement, this would tend to be at minimum a full embedded OS (Embedded Linux, QNX etc.) or a PC. From my experience with deploying CoAP/HTTP proxies so for I have seen three deployment points:

1. Integrated with a 6LoWPAN/IPv6 access point, these tend to be embedded Linux boxes running e.g. an ARM9 with 8-32 MB of RAM and Flash. 
2. Deployed on a PC or IP router in the local M2M network. 
3. Deployed on an intermediate or backend server. 

There is value for keeping the CoAP/HTTP mapping straightforward, but this comes from manageability and human understandability. There are some scalability issues when deploying a high capacity proxy on a backend server.  

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: Tue, 8 Mar 2011 17:45:10 +0100

On Tue, Mar 8, 2011 at 17:33, Zach Shelby <[email-masked]> wrote:
> I do not consider this to be a very constrained device.

I agree with you.

If we assume that the number of CoAP nodes handled by a single proxy
is low, I see no complexity right now in the HTTP mapping.

When the number of CoAP nodes handled by a single proxy grows, I am
not sure that the level of complexity required to deploy a proxy is
acceptable right now.

Best,
Angelo

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 Mar 2011 21:19:51 -0700

<hat type='individual'/>

On 3/6/11 7:23 AM, Klaus Hartke wrote:

> text on possible proxy and reverse proxy implementations. 

Yes, if folks care about this they can write an informational document.
I know some folks who might want to write such a document for an XMPP
mapping, too...

> But I

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/