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