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

Re: #148: Reasonable Assurances and H2C

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 28 Feb 2016 09:10:46 +1100
Cc: "Julian F. Reschke" <julian.reschke@greenbytes.de>, Martin Thomson <martin.thomson@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP WG <ietf-http-wg@w3.org>
Message-Id: <6CDFF367-D510-4F02-8C23-B9AF504F7A84@mnot.net>
To: Barry Leiba <barryleiba@computer.org>

> 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.


Mark Nottingham   https://www.mnot.net/
Received on Saturday, 27 February 2016 22:11:23 UTC

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