Re: #148: Reasonable Assurances and H2C

Mark Nottingham <mnot@mnot.net>: (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.
> 
> Anyone have a problem with dropping this?
> 
> """
> 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

Received on Tuesday, 1 March 2016 14:09:49 UTC