Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

[Klaus Hartke <[e-mail]>]

Hi!

I've reviewed the new -08 revision of the draft and am quite happy
with the outcome. There is just one thing that I think is quite
critical:

Akbar Rahman wrote:
> We will clarify that the whole section 5 is only for the special
> (optional) case where a CoAP URI is embedded within the HTTP URI by
> the HTTP client.  The other case is when only a "pure" HTTP URI is
> sent by the HTTP client to the HC proxy, and the HC proxy itself
> generates the CoAP URI.  In this second case the whole section 5 is
> not required.
>
> Specifically, the case where the HTTP client embeds the CoAP URI info
> into the HTTP URI as we describe in Section 5 will map implicitly to
> our 1st use case in section 4.  On the other hand, our 2nd use case in
> section 4 implies that the legacy application probably does not embed
> the CoAP URI info into the HTTP URI as it is legacy and was written
> without CoAP support.  So in this case, section 5 does not imply but
> sections 6 and 7 do apply.  We definitely need to clarify these
> different possible scenarios of "pure reverse proxy" vs the other case
> of embedded CoAP URI info in the HTTP request.

This is a great clarification of the scope and purpose of the
document, and the bit I was missing all the time. Add it to the
introduction? It's currently only mentioned in section 4, quite far
into the document.

The only problem is: the case where the HTTP client actively embeds a
CoAP URI within a HTTP URI is *not* a reverse proxy.

Don't get me wrong. I think this is a valid use case and I'm not
against its inclusion in the document. But you can't call it a reverse
proxy. It doesn't even match your own definition of reverse proxy in
the document ("This mechanism is transparent to the client, which may
assume that it is communicating with the intended target HTTP server.
In other words, the client accesses the proxy as an origin server
[...]"). Only what you describe as a "pure reverse proxy" with a
"legacy HTTP client without CoAP support" is really a reverse proxy.

Can you find a better term for this kind of service? Maybe something
like "HTTP Access Interface to CoAP"?

Klaus