Re: SHOULD vs MUST (was Re: Review of draft-ietf-geopriv-http-location-delivery-07)

Eric Rescorla <ekr@networkresonance.com> Sat, 21 June 2008 17:31 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326333A6868; Sat, 21 Jun 2008 10:31:27 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA143A6868 for <ietf@core3.amsl.com>; Sat, 21 Jun 2008 10:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level:
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d-sog-abylE for <ietf@core3.amsl.com>; Sat, 21 Jun 2008 10:31:25 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 0A5663A684F for <ietf@ietf.org>; Sat, 21 Jun 2008 10:31:25 -0700 (PDT)
Received: from kilo.local (unknown [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id B6F933011F5; Sat, 21 Jun 2008 10:31:32 -0700 (PDT)
Date: Sat, 21 Jun 2008 10:31:32 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Lawrence Conroy <lconroy@insensate.co.uk>
Subject: Re: SHOULD vs MUST (was Re: Review of draft-ietf-geopriv-http-location-delivery-07)
In-Reply-To: <9D9CF008-7350-4831-8F21-E08A0A7B255E@insensate.co.uk>
References: <20080525020040.4DE5A5081A@romeo.rtfm.com> <F66D7286825402429571678A16C2F5EE03ADF950@zrc2hxm1.corp.nortel.com> <20080620195947.29D0B5081A@romeo.rtfm.com> <9D9CF008-7350-4831-8F21-E08A0A7B255E@insensate.co.uk>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080621173132.B6F933011F5@kilo.rtfm.com>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At Sat, 21 Jun 2008 14:31:03 +0100,
Lawrence Conroy wrote:
> 
> Hi Eric, folks,
>   [renamed for this specific point, and CC list trimmed]
> 
> I am puzzled by this point in your review.
> I suspect that other potential authors will be too.
> To me, the last sentence is exactly right:
> the SHOULD means "do this unless...",
> and the last phrase covers the "unless".

I'm not arguing about what intensity level this requirement
should be at. I'm pointing out that it changed and asking
why.


> I had read 2119 to mean that a MUST was unconditional
> - do this or be non-complaint.

Here's the relevant text from 2119:

    2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
       definition is an absolute prohibition of the specification.
    
    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
       may exist valid reasons in particular circumstances to ignore a
       particular item, but the full implications must be understood and
       carefully weighed before choosing a different course.

In other words, the difference between MUST and SHOULD is intensity
not conditionality.

So, if the spec read:
"You MUST do X unless Y", then an implementation which did not
do X was nonconformant unless Y obtained.

On the other hand, if the spec read:
"You SHOULD do X unless Y", then an implementation which did
not do X is still conformant even if Y does not obtain, though
the implementor is exhorted to do X unless they have some
other good reason and that Y is explicitly called out as such
a reason.


> Do you believe that MUST can have an "unless" clause?

Of course.


> Doesn't this mean that any SHOULD with an explicit "unless" will
> need to be changed into a MUST - could you expand on this, please?

No, why would it?

-Ekr



> On 20 Jun 2008, at 20:59, Eric Rescorla wrote:
> >>   The LIS MUST implement the server
> >>   authentication method described in [RFC2818]. When TLS is used,
> >>   the Device SHOULD fail a request if server authentication fails,
> >>   except in the event of an emergency.
> >>
> >> Does that address your concerns?
> > Why did this become a SHOULD when it was a MUST?



_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf