Re: Working Group Last Call: draft-ietf-httpbis-bcp56bis-08

On 2018-11-30 20:46, Patrick McManus wrote:
> Hi All - I believe that BCP56bis is ready for Working Group Last Call.
> ...

Here's my mainly editorial feedback:

- Although HTTP URIs are by definition URLs, the document currently 
seems to avoid saying "URI", even when it should. For instance, the 
correct term really is "URI scheme", not "URL scheme". I believe we 
should check all uses of "URL" and make sure it's correct. Yes, I can 
work on a PR if desired.

- The document talks about discovering URIs of related resources, but 
doesn't even mention URI templates. I understand that using URI 
templates in link header fields still needs work, but minimally we 
should mention this instead of leaving readers wondering...

- Some lists use comma/semicolon as separators but then continue upper-case

- "GET is one of the most common and useful HTTP methods" - indeed. 
Actually it *is* *the* most common and useful method, no?

- "Applications SHOULD NOT define GET requests to have side effects, 
since implementations can and do retry HTTP GET requests that fail." - 
that should be a "MUST NOT", I think.

- Several occurrences where the document says "header" when it should 
say "header field"

- "This means that status codes are not a reliable way to carry 
application-specific signals. Specifying that a particular status code 
has a specific meaning in the context of an application can have 
unintended side effects; if that status code is generated by a generic 
HTTP component can lead clients to believe that the application is in a 
state that wasn’t intended." - this makes it sound as if it's to be 
expected and normal that components rewrite status codes; I don't think 
that is true. The text goes on saying that "404" can be relied on, but 
this keeps me wondering on what this is based. I believe this subject 
needs more discussion.

- "Because the set of registered HTTP status codes can expand, 
applications using HTTP should explicitly point out that clients ought 
to be able to handle all applicable status codes gracefully (i.e., 
falling back to the generic n00 semantics of a given status code; e.g., 
499 can be safely handled as 400 by clients that don’t recognise it). 
This is preferable to creating a “laundry list” of potential status 
codes, since such a list is never complete." - Nit: the list *could* be 
complete if it contains all syntactically valid error codes.

- "Applications using HTTP SHOULD specify if any request headers need to 
be modified or removed upon a redirect; however, this behaviour cannot 
be relied upon, since a generic client (like a browser) will be unaware 
of such requirements." - I would feel better about this if the base 
standard actually defined this the existing header fields.

- "Applications are advised avoid allowing the use of mobile code where 
possible; when it cannot be avoided, the resulting system’s security 
properties need be carefully scrutinised." - maybe "are advised *to* 
avoid"? or even "are advised to disallow"?

Best regards, Julian

Received on Sunday, 6 January 2019 18:29:27 UTC