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

["Dijk, Esko" <[e-mail]>]

Thanks Klaus for your review comments! I hope to go through these in the coming days and then discuss with my co-authors how to address the open issues.

Regards
Esko

-----Original Message-----
From: core [mailto:[e-mail]] On Behalf Of Klaus Hartke
Sent: Monday, September 28, 2015 16:09
To: [e-mail] WG <[e-mail]>
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

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

_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.