- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 28 Feb 2016 09:10:46 +1100
- To: Barry Leiba <barryleiba@computer.org>
- 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>
> 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. """ Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Saturday, 27 February 2016 22:11:23 UTC