Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24

Barry Leiba <> Wed, 30 October 2013 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E2C811E8267 for <>; Wed, 30 Oct 2013 08:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.953
X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XmtKJnVUxULl for <>; Wed, 30 Oct 2013 08:04:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c00::22d]) by (Postfix) with ESMTP id 3784D21F9D15 for <>; Wed, 30 Oct 2013 08:04:06 -0700 (PDT)
Received: by with SMTP id ii20so3776569qab.18 for <>; Wed, 30 Oct 2013 08:04:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2Mp7ePHlaMQUXjGhW/l8RtqTgoU4lMWEPjeV8mkoCKQ=; b=bp38qjw7ALo7lXcR5OLC5hop43t/yzEAfmEzvf1orQMilb03EaZxMKG6/2Q9A+2k9F nHeZRMEuJat/tFMY0GpZ6/RVw/ADbBgVwOJA017ayV1zCAMVtOA+HP+CR8iyJfyPEvWl 9zV1/ZCacPQXi0DQp/m23/1ekHCTJ9ocXZbj7JWIl26RKwc1uSV2Bd8U1FTt377ee3eV u+yoH8DlmjkgaikOu2ob/XM2q99eIc1Xh5ZbAdmU7V2nK5X+HCNHPE8gciQ1M6jfxZL4 KEl2Ch3hnnIdx23iVtc3IOVHH7tX+BSMtZq66S5baSsmmiS3qsQnKc25Wgi5NDaX6Y+O 5gYg==
MIME-Version: 1.0
X-Received: by with SMTP id da8mr7086364qeb.67.1383145445691; Wed, 30 Oct 2013 08:04:05 -0700 (PDT)
Received: by with HTTP; Wed, 30 Oct 2013 08:04:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 30 Oct 2013 11:04:05 -0400
X-Google-Sender-Auth: EGS89iv12Cn1o2oUfThjkPZwHAc
Message-ID: <>
From: Barry Leiba <>
To: Richard Barnes <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Pete Resnick <>, secdir <>, Julian Reschke <>, "" <>, "Mankin, Allison" <>, HTTP Working Group <>, "" <>
Subject: Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR review of draft-ietf-httpbis-p7-auth-24
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Oct 2013 15:04:23 -0000

>>> Why do you feel the need to avoid SHOULD and MAY here?  They don't place
>>> any more burden on implementors than "ought" and "might".
>>> --Richard
>> I believe in following the guidance in RFC 2119:
> The key word there, though, is "imperatives".  Nothing we're talking about
> here is an imperative, just a recommendation (or RECOMMENDATION).  Skimming
> through the instances of "ought to" in the document, it seems like they all
> meet the definition of "SHOULD" in 2119, i.e., things that implementations
> should only diverge from if they have a good reason.  (In fact, there are
> some that seem like they should be "MUST", but that's a different topic.)

First: I think it's a good idea, in a document that defines protocol,
to separate the requirements for the protocol from the recommendations
for implementation aspects that speak to quality of implementation and
user experience, but that don't affect protocol operation (and

Second, because the use of "should", "must", "may", and "recommended"
in lower case is controversial (for reasons that I don't agree with,
but never-you-mind that), I think using alternatives (as, for example,
proposed here, which was not intended for 1 April publication: ) is a
fine thing.

Third, these situations in the httpbis documents *are* things that
don't affect the protocol.  How should a browser treat [whatever]?
Well, a browser that makes bad choices could be considered a crummy
browser, so giving advice is good and useful.  But the server won't
know nor care, so this isn't a protocol issue.  I don't think,
therefore, that in a protocol document we should use 2119 language for
that.  Save the 2119 language for the protocol.

Fourth, this is starting to get into nitty wordsmithing (the part
about whether "ought" is a good word... not the part about whether
it's normative or not), which I don't think is really appropriate at
this stage of document development.  That is, it's fine to bring it up
editorial things for the editors to consider, but pushing on them at
the expense of time spent on substantive issues doesn't seem wise at
this stage.