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

[Klaus Hartke <[e-mail]>]

Here's my review of draft-ietf-core-http-mapping-07:

Overall -- the document is 'Informational', but it makes a lot of use
of requirement keywords (SHOULD, MUST, etc.). Do these keywords
indicate conformance requirements? What happens if a proxy
implementation ignores any of the requirements? Where do
interoperability problems occur in this case? Please review all
occurrences of a requirement keywords in the document and verify that
is really necessary for interoperability. Explain what happens when a
proxy implementation fails to implement a requirement keyword. IMHO
the only requirement is really that the proxy MUST keep up the
illusion that it is an HTTP origin server; everything else seems to be
OPTIONAL to me.

1. "is to reduce variation between proxy implementations, thereby
increasing interoperability" -- where do these interoperability
problems occur? A HTTP-CoAP cross-protocol reverse proxy appears as an
origin server to the HTTP client, so for the HTTP client any such
proxy looks the same.

5. "base URI" -- the term "base URI" has a well-defined meaning in the
context of URI reference resolution (RFC 3986, Section 5). You're
using it here for something else, which is confusing. Please use a
different term.

5.2 "The default URI mapping function is RECOMMENDED to be
implemented" -- why? What happens when this requirement is ignored?

5.3 -- I don't understand this section. What is this? Why do we need
this? How is this different from the default mapping in Section 5.2?
Who uses these templates, the client or the proxy?

5.3 -- Section 5.2 defines a default mapping, 5.3.1 seems to define
three additional mappings, 5.3.2 seems to define yet another mapping.
Section 1 says that one goal of the spec "is to reduce variation
between proxy implementations, thereby increasing interoperability".
How does this multitude of mappings reduce variability?

5.4 -- "to discover the proxy function, the HC proxy SHOULD publish
information related to the location and syntax of the HC proxy
function" -- the proxy is a reverse proxy. It appears as an origin
server to any client. Why does the proxy function need to be
discovered? Who are the "third parties"?

5.4.1 -- Section 5.4 is about discovering the proxy function, 5.4.1 is
about discovering resources, 5.4.2 is about discovering the proxy
function again. This is confusing.

5.4.2 "The first example exercises the CoAP interface" -- why does a
CoAP client need to discover a HTTP-CoAP proxy?

6.5.2. -- to keep the illusion up that the proxy is an origin server,
the proxy MUST rewrite _all_ URIs in _all_ representation formats, not
just Link Formats. This includes _all_ URIs generated on-the-fly by
JavaScript code! Unless the proxy has a very deep understanding of the
application, this is generally not possible. But a reverse proxy with
a very deep understanding of the application is unlikely to use any of
the URI mapping schemes defined in the document. So basically the
whole Section 5 is useless.

6.5.3. "the CoAP diagnostic payload must be used as the HTTP
reason-phrase of the HTTP status line" -- a diagnostic payload is
similar to the HTTP reason phrase, but it can be much more verbose
and, e.g., can include CR-LF line breaks. It's probably best to stick
the diagnostic payload into the payload and use the default reason
phrase for the status code.

7. "4.02 Bad Option | 400 Bad Request" -- can the HTTP client make a
change to its request so that the proxy does not include the bad
option in its CoAP request? If not, the bad option is the proxy's
fault (5xx status code) and not the HTTP client's fault (4xx status
code).

7. "The proxy receiving 2.03 updates the freshness of its cached
representation and returns the entire representation to the HTTP
client." -- If the proxy receives a response indicating that the etag
supplied by the HTTP client is valid, why does the proxy need to send
the representation to the client?

7. "If the HC proxy does not implement a proper authentication method
that can be used to gain access to the target CoAP resource, it can
include a 'dummy' challenge for example "WWW-Authenticate: None"." --
if the proxy cannot gain access to the CoAP resource, it should
probably return a 403 (Forbidden) status code to the HTTP client.

7. "In this case the HC Proxy SHOULD also return a HTTP reason-phrase
in the HTTP status line that starts with the string "405" in order to
facilitate troubleshooting." -- this leads to a status line like
"HTTP/1.1 400 405 Method Not Allowed" which looks wrong and may
confuse implementers.

7. "The value of the HTTP "Retry-After" response-header field is taken
from the value of the CoAP Max-Age Option, if present." -- if the
Max-Age Option is not present, it means that the Max-Age is 60
seconds, not that the representation doesn't have a Max-Age.

8.1 "An HC proxy SHOULD limit the number of requests to CoAP servers
by responding, where applicable, with a cached representation of the
resource." -- The proxy actually MUST perform congestion control as
specified in RFC 7252. Caching is not about congestion control, it is
about efficiency. So, as a matter of quality of implementation, it is
a good idea for a proxy to implement caching. But responding with a
cached representation of the resource is not a tool to enforce
congestion control.

8.1 "Duplicate idempotent pending requests by an HC proxy to the same
CoAP resource SHOULD in general be avoided, by using the same response
for multiple requesting HTTP clients without duplicating the CoAP
request." -- this is not how caching in CoAP works. Please read RFC
7252.

8.1 "According to [RFC7252], a proxy MUST limit the number of
outstanding interactions to a given CoAP server to NSTART." -- this
has already been specified in RFC 7252. There is no need to repeat
that here.

9.2 -- have you submitted the registration to the [e-mail]
mailing list for review? It's probably a good idea to do this before
sending the document to the IESG.

Are there any implementations of this document?

Klaus