Subject: Re: #148: Reasonable Assurances and H2C

From: Julian Reschke <[email-masked]>
Date: Tue, 1 Mar 2016 12:08:28 +0100

On 2016-02-28 16:41, Julian Reschke wrote:
> ...
>> A registry doesn't feel right because this isn't a protocol element.
>> This isn't an extension in the usual sense; it's a controlled
>> loosening of the spec's (security-sensitive) requirements.
>>
>> However, it doesn't seem like 'updates' is the right way to do this
>> either. Upon reflection, I wonder if we really need either property
>> (at least in such a rigorous form); people will find the mechanisms if
>> they get implemented, and we've been happy to have OppSec as
>> Experimental.
>>
>> Anyone have a problem with dropping this?
>>
>> """
>> Other means of establishing them MUST be documented in an RFC that
>> updates this specification.
>> """
>
> Sounds right to me.
>
> Best regards, Julian

As I heard no pushback I've done this in 
<https://github.com/httpwg/http-extensions/commit/6b1cc1995538fde23241ed4d89725f4e9a62b3ec>.

I plan to submit a new draft later today (which then would go to the IESG).

Best regards, Julian

---

From: Kari Hurtta <[email-masked]>
Date: Sun, 28 Feb 2016 16:54:18 +0000

Mark Nottingham <[email-masked]>: (Sun Feb 28 00:10:46 2016)
>> The way to assure the vetting is to say that they must be Standards
>> Track.  Experimental documents might or might not get sufficient
>> vetting.
>> 
>> The way to ensure that people who read this spec can find all the
>> extensions is to make a registry.  Extensions shouldn't generally be
>> "updating" the original spec.
>> 
>> So...
>> You can decide how you think the vetting will be accomplished, but if
>> you want it to be easy to find the new mechanisms, have this document
>> set up a registry and say that new mechanisms MUST be registered
>> there.  Then there's no concern about any "updates" rules with respect
>> to documents from other than Standards Track sources.
> 
> A registry doesn't feel right because this isn't a protocol element. This isn't an extension in the usual sense; it's a controlled loosening of the spec's (security-sensitive) requirements.

Well, "reasonable assurances" can be protocol
element. 

Alt-Svc: h2=":8443"; ma=60000; trust="/.well-known/alternative-services"

(except that token should be shorter, perhaps trust=wk-alt-svc )

Or

Alt-Svc: h2=":8443"; ma=60000; trust=also-options

( ie. "OPTIONS * HTTP/1.1"   should return sama Alt-Svc: -header field
 from original server. )

> However, it doesn't seem like 'updates' is the right way to do this either. Upon reflection, I wonder if we really need either property (at least in such a rigorous form); people will find the mechanisms if they get implemented, and we've been happy to have OppSec as Experimental.
> 
> Other means of establishing them MUST be documented in an RFC that updates this specification.
> """

Not actually.

( Also just dropping that "updates" works:

| Other means of establishing them MUST be documented in an RFC.

After all that just needs well defined protocol. There is
several possibilities. )

> Cheers,
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 

/ Kari Hurtta