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

On 2019-01-08 00:30, Mark Nottingham wrote:
> Thanks, Julian. Responses below.
> 
>> On 7 Jan 2019, at 5:28 am, Julian Reschke <julian.reschke@gmx.de> wrote:
>>
>> 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.
> 
> HTTP *is* a URL scheme, though -- and it's most commonly known for that. Given the audience, to me it doesn't seem prudent to confuse people with technically-correct-but-obtuse terminology.

It is. But:

- the document is not always talking about HTTP URLs when it says "URL", and

- some of the referenced material has "URI" in the title, so just 
avoiding the term here IMHO doesn't make things clearer for readers who 
don't have our experience with these terms.

> How do others feel about this?
> 
>> - 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..
> 
> Yes. I had reservations about mentioning it for the reasons you highlight, but added:
>    https://github.com/httpwg/http-extensions/commit/1ddb98efc2d

+1

> Please say if there's somewhere else that could benefit from a mention.

As a reader of this document, I'd like to find out what the status of 
URI templates is in relation to Link header fields. I understand the 
answer is "we're not there yet", and maybe it would be good to just 
state that.

>> - Some lists use comma/semicolon as separators but then continue upper-case
> 
> Fixed.
> 
>> - "GET is one of the most common and useful HTTP methods" - indeed. Actually it *is* *the* most common and useful method, no?
> 
> Fixed.
> 
>> - "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.
> 
> We don't have a corresponding requirement for safety in HTTP; I tend to think it'd better to make this prose, rather than a requirement. See:
>    https://github.com/httpwg/http-extensions/commit/0d8d25888

Ok.

>> - Several occurrences where the document says "header" when it should say "header field"
> 
> See <https://github.com/httpwg/http-core/issues/111>. Since this document is blocked by the core docs, we can revise that at the RFC Editor if need be.

-1. Revising docs after approval is problematic. (a) We may forget it, 
(b) there is little quality control. I don't think we can send this to 
the RFC Editor before the base docs are done.

>> - "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.
> 
> It is normal; e.g., gateways generate 502-504 all the time; caches generate 304. Servers often generate 4xx range responses without consulting the resource that they're serving.

Yes. But, from a protocol point of view, the distinction between 
"server" and "resource" doesn't matter. It's an implementation detail.

The current text sort of implies that defining new status codes is 
inherently wrong because they might not travel correctly; this is IMHO 
very misleading.

>> 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.
> 
> I think the text is as good as we're going to get it in a reasonable amount of time, but if you have suggestions for improvement, please convey them.
> 
>> - "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.
> 
> What about yet-to-be-defined codes? I think the state you refer to can only happen when the status code space is completely exhausted.

Yes, it's a nit :-).

>> - "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.
> 
> Yes; see <https://github.com/httpwg/http-core/issues/38>.

I'm not happy to have this requirement here until we have understood to 
fulfil it ourselves in the base spec.

>> - "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"?
> 
> Fixed.
> 
> Thanks!

Best regards, Julian

Received on Tuesday, 8 January 2019 05:21:12 UTC