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

On 2019-01-08 07:21, Mark Nottingham wrote:
> 
> 
>> On 8 Jan 2019, at 5:08 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
>>>> 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.
>>> Anyone can mint a header that carries a uri template; we just don't have a generic way to carry one around. Also, I'm wary of saying something like the above, since it would trigger an unnecessary document update as soon as one were defined.
>>
>> As long as it says "at the time of this writing", not necessarily.
>>
>> I'm raising this because I feel this actually is something that readers of this spec will be looking for.
> 
> I feel like the same criticism could have been made of the URI Templates spec itself, and yet it's silent on the matter.

Right.

> P.S. <https://mnot.github.io/I-D/link-template/>

Yes. I think it would be good to point people to this, even when it's 
not ready yet.

>>> ... >>>> - 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.
>>> I'll leave that for the chair to decide. In the meantime: <https://github.com/httpwg/http-extensions/issues/748>
>>
>> Procedural feedback: this IMHO is something the WG needs to form consensus on, not a chair decision.
> 
> Your point was about how the working group's decision gets incorporated into the document, pre- vs post- LC. That's a matter for the chair(s), the IESG and the RFC Editor (it's not uncommon for the document that gets published as an RFC to be different from that which exists WGLC, based upon input). *Making* the decision requires WG consensus.

Right.

> Having said that, if it's clearer to hold this document for core, I don't have a problem with that.

I believe this document is to dependant on the base specs to go to the 
RFC Editor before we're done with those. Consider the cross-linkking. 
We've been burn with this approach before. See the errata for RFC 7240 
(<https://www.rfc-editor.org/errata_search.php?rfc=7240>).

>>>>>> - "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.
>>> I really don't see how you get that. The text is talking about using existing status codes, not minting new ones.
>>
>> It talks about status codes in general; that includes new ones, no?
> 
> Potentially, but new status codes are required to be generic, not application-specific, so it ends up in the same place. Status codes are *not* a guaranteed end-to-end signal; they can (and often are) superseded by HTTP components in the middle.

Under certain well-understood circumstances, by design, or when there is 
a bug. My point is that they usually are reliable when the actual origin 
servers gets to respond.

I'm concerned that the current text will cause people to stuff all 
information into header fields or the payload, and just send 400.

>>> ...
>>>>>> - "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.
>>> <https://httpwg.org/specs/rfc7231.html#considerations.for.new.header.fields> already says "Whether the header field ought to be preserved across redirects." The text you question in BCP56bis is about *new* headers; Core issue #38 is about defining that behaviour for headers that core defines. Why does this block?
>>
>> Unless I'm missing something, the text is about all header fields: "Applications using HTTP SHOULD specify if any request headers need to be modified or removed upon a redirect;..."
> 
> Would "...request headers that it defines..." work?

Yes.

Best regards, Julian

Received on Tuesday, 8 January 2019 08:52:32 UTC