Re: *** GMX Spamverdacht *** RE: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc as a normative reference in http/2

On 2014-03-20 16:46, Gabriel Montenegro wrote:
>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>> On 03/20/2014 02:39 AM, William Chan (陈智昌) wrote:
>>>   If everyone else says they believe that the working group consensus
>>> indeed is to document http:// over TLS in the core HTTP/2 spec,
>>
>> With no hats, I'd like to be on the record as saying that documenting how to
>> do http:// URIs via TLS as part of HTTP/2.0 would be a really good thing to do.
>> Especially in the light of recent reports of cleartext HTTP being used to trigger
>> other attacks. And defining that at the same time as we are defining
>> HTTP/2.0 seems like the perfect time to me. (Adding it later would be far less
>> good IMO.)
>>
>> I don't have a very strong position about which 2119 keywords are used to
>> talk about whether that MAY, SHOULD or MUST be implemented or used,
>> but one could argue that both BCP 61 and the new perpass-attack BCP will be
>> far more clearly satisfied the more that feature is implemented. The main
>> thing for me however is that it be well-defined now so that those who want
>> to use that feature can do so and get interop and be in a position to mitigate
>> attacks such as those referred to above without requiring changes to web
>> content.
>>
>> And yes, I do get that this is not entirely a slam-dunk, but from the discussion
>> I've heard and the evidence that it can be done from Patrick and I think Will,
>> it seems to me that defining how to do it ought not be something that'd add
>> significant (or any) delay.
>
> [Gab] I think there was agreement in London to go ahead and document it. The issue is of a different nature. If the base spec adds a normative reference to the alt-svc spec, it adds a blocker from the point of view of the RFC editing/publication process. We did not discuss informative vs normative reference in London, but we also agreed in London (very clearly, per my recollection) that alt-svc would not be a blocker for HTTP/2.

It's only a blocker if we don't make progress :-)

> Documenting and having an informational reference is non-blocking, and appropriate as well, since one does not need to understand all the alt-svc scenarios in order to implement the ALTSVC frame. This is analogous to how PUSH and flow control also have the low-level mechanisms in the spec, but how to actually use them (PUSH strategies, flow control algorithms) are left out.

Yes, but the definition of the ALTSVC frame relies on the definition of 
the Alt-Svc concept. Either we in-line the definition of the concept, or 
we have a normative dependency on that other spec.

Both will work, and I claim that timing-wise it doesn't make any 
significant difference. It's just the number of documents that varies.

Best regards, Julian

Received on Thursday, 20 March 2014 15:59:26 UTC