Re: [core] Miscellaneous HTTP mapping related questions

[Carsten Bormann <[e-mail]>]

(Individual response.)

On Mar 2, 2011, at 12:15, Angelo P. Castellani wrote:

> 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?

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.

> 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. )

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.

> ( See https://datatracker.ietf.org/doc/draft-castellani-core-http-coap-mapping/
> 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.

> 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. )

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