Grammatically, RECOMMENDED is sometimes useful, as using SHOULD instead can
produce less clear sentences. In principal the same applies to OPTIONAL, but
I've never had cause to use it.
I wouldn't miss SHALL. Except that SHALL is often the word used outside the
IETF rather than must, and there may be many RFCs using it, so do need to keep
the explanation, even if deprecated to use it in new documents.
--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________
T: +44 (0)1245 242194 | E: chris(_dot_)dearlove(_at_)baesystems(_dot_)com
BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,
Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
-----Original Message-----
From: ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Barry Leiba
Sent: 09 August 2016 21:09
To: IETF discussion list
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
----------------------! WARNING ! ---------------------- This message
originates from outside our organisation, either from an external partner or
from the internet.
Consider carefully whether you should click on any links, open any attachments
or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on
reporting suspicious email messages.
--------------------------------------------------------
This draft should be self-explanatory -- and please be sure to look at Section
1.1 for some explanations that may short-cut some of the discussion.
The bottom line is to update BCP 14 (RFC 2119) to
(1) make it clear that the key words MUST(/NOT), SHOULD(/NOT), and MAY are only
key words when they're in ALL CAPS, and
(2) deprecate the use of the variants (SHALL, RECOMMENDED, OPTIONAL) so as to
avoid reserving an unnecessarily number of key words.
Discussion here, please, before Ben, who has kindly agreed to AD-sponsor this,
sends it out for last call. And we do expect there to be some significant
discussion on this one.
Barry
On Tue, Aug 9, 2016 at 2:55 PM, <internet-drafts(_at_)ietf(_dot_)org> wrote:
A new version of I-D, draft-leiba-rfc2119-update-00.txt has been
successfully submitted by Barry Leiba and posted to the IETF
repository.
Name: draft-leiba-rfc2119-update
Revision: 00
Title: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
Document date: 2016-08-09
Group: Individual Submission
Pages: 4
URL:
https://www.ietf.org/internet-drafts/draft-leiba-rfc2119-update-00.txt
Status: https://datatracker.ietf.org/doc/draft-leiba-rfc2119-update/
Htmlized: https://tools.ietf.org/html/draft-leiba-rfc2119-update-00
Abstract:
RFC 2119 specifies common key words that may be used in protocol
specifications. This document aims to reduce the ambiguity by
clarifying that only UPPERCASE usage of the key words have the
defined special meanings, and by deprecating some versions of the key
words.
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************