Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
John C Klensin <john-ietf@jck.com> Wed, 10 August 2016 21:09 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE81412B047 for <ietf@ietfa.amsl.com>; Wed, 10 Aug 2016 14:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76cd06NONnW6 for <ietf@ietfa.amsl.com>; Wed, 10 Aug 2016 14:09:29 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5117D12D7AA for <ietf@ietf.org>; Wed, 10 Aug 2016 14:09:29 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1bXakh-0000wl-2r; Wed, 10 Aug 2016 17:09:27 -0400
Date: Wed, 10 Aug 2016 17:09:22 -0400
From: John C Klensin <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
Message-ID: <A870981938AE4F1E224A7455@JcK-HP8200>
In-Reply-To: <tslinv9k3bq.fsf@mit.edu>
References: <147077254472.30640.13738163813175851232.idtracker@ietfa.amsl.com> <CALaySJLHx7ytgZqZ9zQXA3vVSU-pNggQQs+QiDnzQ4tBEH5VAQ@mail.gmail.c om> <CA+9kkMC_hb_BWM5iEpvaWBQY_QsDBZcJDGC9WdcD_O+KHX=64g@mail.gmail.com> <tslmvklk571.fsf@mit.edu> <defc83cb-72a8-f64f-658e-256d7ed76b27@dcrocker.net> <tslinv9k3bq.fsf@mit.edu>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/HXpOpbjzQ9obDqOkNhCVEoI6WsI>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2016 21:09:32 -0000
--On Tuesday, August 09, 2016 18:03 -0400 Sam Hartman <hartmans-ietf@mit.edu> wrote: >... > The point of lower case keywords shouldn't be to allow people > to be sloppy and to avoid normative text to make a false > consensus easier. This SHOULD be about writing clearer RFCs > and not having to contort language when should and must are > perfectly good non-normative things to say. It seems to me that this is key. I'd even favor some text that discourages the use of the lower-case forms except when the meaning (normative status) is clear from context or the alternatives would be really awkward. For example, something like the following could be added to the second bullet in Section 2: "As a matter of editorial style and to reduce possible confusion, especially with alternate presentation methods, it is generally preferable to avoid the uncapitalized forms in documents where the capitalized ones are used unless the intent is very clear from context", That doesn't say "SHOULD NOT" or 'MUST NOT" use, but provides general guidance and a basis for the RFC Editor doing some negotiating when they deem it appropriate. --On Wednesday, August 10, 2016 10:44 +1200 Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: >> REQUIRED, SHALL, SHALL NOT, RECOMMENDED, NOT RECOMMENDED, >> OPTIONAL > > I will be glad to see the back of SHALL, but I object to > deprecating the adjectives. They are useful - indeed, > sometimes required - for the construction of readable > sentences and, for example, tables of RECOMMENDED and OPTIONAL > values. It seems to me that we have tested the model of using different terms, avoiding the 2119 terms entirely except when they are used in normative form. At least for me, draft-hansen-nonkeywords-non2119 offers fairly conclusive proof that avoiding the 2119 terms entirely just causes the language to be too stressed and convoluted, increasing confusion (especially for people who are not expert in English). YNMD about that, but I think the option of returning SHALL and the adjectives to non-specialized use and forcing more convoluted language to avoid the entire 2119 set are the alternatives and that there is little point discussing one strategy in isolation from the other. Incidentally, as part of what I see as if we are going to do this, let's clean things up, rather than merely clarifying/modifying the case rules, it would be worth taking a look at the five year old draft-saintandre-2119bis-01 for some potential clarifications. I think that means I disagree with draft-leiba-rfc2119-update-00 and its argument that it is best to fix 2119 piecemeal. We are just too dependent on that document to apply a lot of separate patches to it, a situation that will almost certainly lead to confusion about which patches are in effect. Even if authors are very careful about what they reference, readers at not likely to be careful to check those references. On the other hand, I am sympathetic to Barry's argument that we've wasted altogether too much time arguing about what lower-case "must" (etc.,) means and believe that some clarification (almost independent of which one is chosen) would be helpful. If the community wants to do that as a small incremental change, it seem to me that this draft should confine itself to the matter of case distinctions and avoid engaging in the (obviously from the discussion) much more controversial topic of getting rid of the synonyms or even, as an alternative, explicitly discouraging, but not forbidding, their use. --On Wednesday, August 10, 2016 10:03 -0800 Melinda Shore <melinda.shore@gmail.com> wrote: > Not much, I don't think. I certainly cannot think of > an instance where a document has been anything other than > trivially delayed by a discussion about normative language. > And of course there are serious discussions about whether > something should be mandatory or recommended, and this > document really doesn't help those at all. Actually, I can think of several instances, but they were not associated with arguments about case sensitivity (Ted Lemon's note about this, which I'm sure is correct, notwithstanding). Instead, they were about another issue that I thought 2119 was clear about until I encountered the problem. This I-D not only doesn't fix that problem but might make it worse. The issue has to do with whether 2119 language is required in normative standards-track specs or whether an author can choose to use other terminology or the same terminology with other definitions. MUST, SHOULD, etc., became prominent in our vocabulary with RFC 1122/1123, but the terms were used there in the sense of "required to conform to this specification". RFC 2119 defines them in terms of requirements to interoperate, not to conform. The two are often the same, but certainly not always so. RFC 2821 does not reference 2119 and uses the terms in the RFC 1123 sense. When its successor, the I-D preceding RFC 5321, reached the IESG with the same definition (IIR, a bit more explicitly than in 2821), the IESG balked and insisted that there be a reference to 2119 and that usage in the document conform to 2119 usage. Again IIR, since the IESG member(s) involved were adamant and those those who had worked on proto-5321 were running out of energy, the latter was adjusted to 2119 terminology, an effort that took some weeks. The I-D now says (under "=== NEW ===" in Section 2), "This document defines how these words are interpreted in IETF documents when the words are capitalized." That is not "when the words are capitalized and BCP 14 and/or this document is referenced" or any such thing; it applies the definition to all "IETF documents". The next paragraph (first bullet) appears to contradict that ("...can be used as defined here, but it is not required that they be. Specifically, normative text does not require the use of these key words."). The combination is a recipe for continued, possibly increased, confusion. Finally, please either get rid of "capitalized" and/or substitute "written in all capital letters" or equivalent. The term "capitalized" is, itself, ambiguous and is correctly used in the sentence "'Must' is capitalized". best, john
- Re: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… John R Levine
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… John Levine
- Re: New Version Notification for draft-leiba-rfc2… Randall Gellens (IETF)
- Re: New Version Notification for draft-leiba-rfc2… Joe Touch
- Re: New Version Notification for draft-leiba-rfc2… Gmail
- Re: New Version Notification for draft-leiba-rfc2… Brian E Carpenter
- Re: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… Pete Resnick
- Re: New Version Notification for draft-leiba-rfc2… Joe Touch
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… Pete Resnick
- Re: New Version Notification for draft-leiba-rfc2… Julian Reschke
- Re: New Version Notification for draft-leiba-rfc2… Michael Richardson
- Re: New Version Notification for draft-leiba-rfc2… Julian Reschke
- Re: New Version Notification for draft-leiba-rfc2… Ted Lemon
- Re: New Version Notification for draft-leiba-rfc2… Ben Campbell
- Re: New Version Notification for draft-leiba-rfc2… HANSEN, TONY L
- RE: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- RE: New Version Notification for draft-leiba-rfc2… Dearlove, Christopher (UK)
- Re: New Version Notification for draft-leiba-rfc2… Ted Lemon
- Re: New Version Notification for draft-leiba-rfc2… Stewart Bryant
- RE: New Version Notification for draft-leiba-rfc2… Dearlove, Christopher (UK)
- Re: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… John C Klensin
- Re: New Version Notification for draft-leiba-rfc2… Michael Richardson
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- Re: New Version Notification for draft-leiba-rfc2… Doug Ewell
- Re: New Version Notification for draft-leiba-rfc2… Dave Cridland
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- Re: New Version Notification for draft-leiba-rfc2… Time Warner Cable
- Re: New Version Notification for draft-leiba-rfc2… Michael Richardson
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- Re: New Version Notification for draft-leiba-rfc2… Michael Richardson
- Re: New Version Notification for draft-leiba-rfc2… Ted Lemon
- Re: New Version Notification for draft-leiba-rfc2… Ted Lemon
- Re: New Version Notification for draft-leiba-rfc2… John Leslie
- Re: New Version Notification for draft-leiba-rfc2… Ted Lemon
- Re: New Version Notification for draft-leiba-rfc2… Stewart Bryant
- Re: New Version Notification for draft-leiba-rfc2… Stewart Bryant
- Re: New Version Notification for draft-leiba-rfc2… Stewart Bryant
- Re: New Version Notification for draft-leiba-rfc2… Stewart Bryant
- Re: New Version Notification for draft-leiba-rfc2… Randy Bush
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… Michael Richardson
- Re: New Version Notification for draft-leiba-rfc2… Mark Andrews
- Re: New Version Notification for draft-leiba-rfc2… John R Levine
- Re: New Version Notification for draft-leiba-rfc2… Mark Andrews
- Re: New Version Notification for draft-leiba-rfc2… John Levine
- Re: New Version Notification for draft-leiba-rfc2… Scott O. Bradner
- Re: New Version Notification for draft-leiba-rfc2… Joe Touch
- Re: New Version Notification for draft-leiba-rfc2… Sam Hartman
- Re: New Version Notification for draft-leiba-rfc2… Dave Crocker
- Re: New Version Notification for draft-leiba-rfc2… Sam Hartman
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- Re: New Version Notification for draft-leiba-rfc2… Stephan Wenger
- Re: New Version Notification for draft-leiba-rfc2… Barry Leiba
- Re: New Version Notification for draft-leiba-rfc2… Ted Hardie
- Re: New Version Notification for draft-leiba-rfc2… Paul Hoffman