Subject: [core] Miscellaneous HTTP mapping related questions

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 2 Mar 2011 12:15:50 +0100

Hi all,

after the last interim meeting, I have various open questions about
the current coap/observe design:

a) In coap-04 there is no reference to intercepting (transparent)
proxies. Is compatibility with intecepting proxies important and
required for CoRE?

b) In observe-01 examples a direct mapping of HTTP bidirectional is
missing. Do we believe that it is a required and important feature?

( See https://datatracker.ietf.org/doc/draft-loreto-http-bidirectional/
for an extensive discussion about these techniques. )
( See https://datatracker.ietf.org/doc/draft-castellani-core-http-coap-mapping/
for a possible mapping of these to observe. )

c) In coap-04 multicast is supported. Is important to evaluate a
standard mapping of a single HTTP request/response to a multicast CoAP
request and related responses?

( https://datatracker.ietf.org/doc/draft-castellani-core-http-coap-mapping/
contains a brief discussion about this, and in my opinion this mapping
should be realized using a single TCP connection mapped to multicast
UDP by the HTTP/CoAP proxy. )

My answer is yes for all the above questions. What is the WG position
about this questions?

Best,
Angelo

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Mar 2011 13:22:46 +0100

(Individual response.)

> proxies. Is compatibility with intecepting proxies important and

Actually, coap-04 says:

   Reverse Proxy
      A "reverse proxy" is an end-point that acts as a layer above some
      other server(s) and satisfies requests on behalf of these, doing
      any necessary translations.  Unlike a proxy, a reverse proxy
      receives requests as if it was the origin server for the target
      resource; the requesting client will not be aware that it is
      communicating with a reverse proxy.

Is that covering your idea of an intercepting proxy?
Or is the latter something else?

In any case, the text tries to separate the concept of proxying (proxy configured by client) from the more general concept of a CoAP intermediary, which includes both proxies and reverse proxies.  Maybe that wasn't too sucessful yet.

> for an extensive discussion about these techniques. )

These hacks are not part of HTTP.

They are useful because HTTP can't evolve quickly enough, because of the installed base.
CoAP, however, can.  So the question would be:
Which of the CoAP features do we want to cover by a "standard" mapping to the hacks covered in the draft?
(Since the latter aren't even standardized, that is not a trivial question.)
I certainly would not be happy with inventing non-REST features in CoAP just to create a questionable equivalence to these hacks, but I think that's not what you are suggesting.

> for a possible mapping of these to observe. )

We need to clear up the terminology here:
These are not HTTP features, so we can't "map" them.
But we could install these hacks in an intermediary to cover CoAP features that cannot be mapped to HTTP.
(But then I wouldn't be happy about the CoRE WG surging ahead and standardizing these HTTP hacks.)

It is easy to use HTTP REST features to map CoAP observe to HTTP in a caching intermediary.
The only question is whether there is a need for "intention signaling"/hinting from the client to the intermediary so the intermediary can decide whether it should establish an observation relationship even before it has a view of the traffic patterns.

> UDP by the HTTP/CoAP proxy. )

I continue to believe that we need to define a media type for forwarding GET responses collected from a multicast request.
(If the multicast really is an anycast, there may be a shortcut if it is not important who sent the response.)

For PUT, we'd at least need to collect response codes, maybe with a similar shortcut.

Gruesse, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 3 Mar 2011 10:14:52 +0100

(Partial response.)

> Or is the latter something else?

In my opinion the main difference between reverse proxies and
intercepting proxies is that reverse proxies usually know all the
servers they are serving, the intercepting proxies operate without
this knowledge.

TERMINOLOGY (in my opinion, please comment if there are errors):

Forward proxy: Server zero-configuration (Servers are not required to
be aware of them).

Reverse proxy: Client zero-configuration (Servers are not required to
be aware of them).

Intercepting (or transparent) proxy: Client zero-configuration
(Clients are not required to be aware of them) AND Server
zero-configuration (Servers are not required to be aware of them).

Same-protocol proxy: No protocol translation (CoAP<->CoAP, HTTP<->HTTP).

Cross-protocol proxy: Translates between one protocol to another.

One-way cross-procotol proxy: Translates only in one direction
(CoAP->HTTP or HTTP->CoAP)

Bidirectional cross-protocol proxy: Translates in both directions (HTTP<->CoAP).

> In any case, the text tries to separate the concept of proxying (proxy configured by client) from the more general concept of a CoAP intermediary, which includes both proxies and reverse proxies.…

Yes it is successful, but only to use CoAP as a client in my opinion.

Deploying a CoAP server and successfully accessing it using HTTP
requires discussion and is still not clearly written on coap-04.

Right now, I am wondering if CoAP servers interoperability with
HTTP-based Internet is simple enought. This scenario should be very
important in the CoAP design, do we agree on this?

STATEMENT USING MY TERMINOLOGY:

In my opinion CoAP server deployment and Internet interoperability
will be simpler if CoAP explicitly supports the deployment of
intercepting bidirectional cross-protocol proxies.

This will probably be an important use-case discussed in
http-coap-mapping-01 (in progress).

Any comment about this?

Best,
Angelo

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 4 Mar 2011 17:25:56 +0100

(Another partial response.)

> I continue to believe that we need to define a media type for forwarding GET responses collected from a multicast request.

Probably we don't even need to define a new media type.

Assume that an HTTP/IPv4 client sends a request to the CoAP/HTTP proxy
directed to a multicast group in the constrained CoAP/IPv6 network.

The proxy can stream multiple responses in a single HTTP response
(single TCP connection) as soon as they arrive using a conjunction of
"Transfer-Encoding: chunked" and of "Content-Type: multipart/mixed".

Without many words, I attach to this message an example that I think
is clear enought.

Assume to have the following DNS records:
a) temperature-nodes.coap.something.net AAAA record points to the IPv6
multicast group of temperature sensors.
b) temperature-nodes.coap.something.net A record points to the IPv4 of
the CoAP/HTTP proxy.

Please to understand better this solution refer also to my previous
message titled "HTTP/IPv4 clients accessing CoAP/IPv6 resources".

Best,
Angelo

p.s.: XX, xx, YY, yy, ZZ, zz and KK should be set to values adequate
to the actual content.

p.p.s.: Multicast request example:

GET /temperature HTTP/1.1
Host: temperature-nodes.coap.something.net

200 OK
Content-Type: multipart/mixed; boundary=SingleNodeResponse
Transfer-Encoding: chunked

XX
--SingleNodeResponse
Content-Type: message/http

HTTP/1.1 200 OK
Link: <http://node31.coap.something.net/temperature>; rel=via
Content-Lenght: xx

22.1 C

YY
--SingleNodeResponse
Content-Type: message/http

HTTP/1.1 200 OK
Link: <http://node63.coap.something.net/temperature>; rel=via
Content-Lenght: yy

20.3 C

ZZ
--SingleNodeResponse
Content-Type: message/http

HTTP/1.1 200 OK
Link: <http://node18.coap.something.net/temperature>; rel=via
Content-Lenght: zz

24.5 C

KK
--SingleNodeResponse--

0