W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: #148: Reasonable Assurances and H2C

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Sun, 28 Feb 2016 16:41:20 +0100
To: Mark Nottingham <mnot@mnot.net>, Barry Leiba <barryleiba@computer.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP WG <ietf-http-wg@w3.org>
Message-ID: <56D31520.1080001@greenbytes.de>
On 2016-02-27 23:10, Mark Nottingham wrote:
>> On 28 Feb 2016, at 3:43 AM, Barry Leiba <barryleiba@computer.org> wrote:
>>>> Yeh, why is "that updates this document" there?  Why do readers of
>>>> this document have to know about means that are provided in other
>>>> documents, such that "updates" is needed?
>>> We wanted to assure that any other way to establish reasonable assurances
>>> had sufficient vetting, and that someone reading this spec could find all the
>>> different ways to establish reasonable assurances.
>>> Any additional insights (hopefully in non-question form)?
>> Hm, I'm assume that wasn't meant to be snarky, though it sounds it.  I
>> needed to ask the question in order to answer the original question.
> No, it was not; apologies for giving the impression.
>> 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.
> 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
Received on Sunday, 28 February 2016 15:41:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC