IETF Logo Mail Archive

Re: [salud] Gen-art LC review of draft-ietf-salud-alert-info-urns-12 and also Area Director's review

worley@ariadne.com (Dale R. Worley) Wed, 07 May 2014 15:55 UTC

Return-Path: <worley@ariadne.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7298E1A035B for <salud@ietfa.amsl.com>; Wed, 7 May 2014 08:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
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 hkBiDQT1kU1h for <salud@ietfa.amsl.com>; Wed, 7 May 2014 08:55:16 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id D902F1A0353 for <salud@ietf.org>; Wed, 7 May 2014 08:55:15 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id z3an1n0021c6gX85C3vBWP; Wed, 07 May 2014 15:55:11 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta23.westchester.pa.mail.comcast.net with comcast id z3vA1n00c1KKtkw3j3vANQ; Wed, 07 May 2014 15:55:11 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s47FtAh9010518; Wed, 7 May 2014 11:55:10 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s47Ft9em010517; Wed, 7 May 2014 11:55:09 -0400
Date: Wed, 07 May 2014 11:55:09 -0400
Message-Id: <201405071555.s47Ft9em010517@hobgoblin.ariadne.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
In-reply-to: <949EF20990823C4C85C18D59AA11AD8B1965E3@FR712WXCHMBA11.zeu.alcatel-lucent.com> (keith.drage@alcatel-lucent.com)
References: <535E50C1.2060100@isode.com> <201405061853.s46Ire8K007213@hobgoblin.ariadne.com> <949EF20990823C4C85C18D59AA11AD8B1965E3@FR712WXCHMBA11.zeu.alcatel-lucent.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399478111; bh=URC9f4j+QYsMx/vWkGzIuv+lctE5wCi5vG5/gim7xNo=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=gN80sh4VyK56tIyukYKoDelArGFDXYcY0JyvxbRg7ixnpEujT1tkRGSvyeCWAjAUv PrXg5NyTEHaewKVKFsPlK9M0QMqJqGM2nRXcAa9td3LUXv/u/t9orxDEV4kh9CSSlS fKbBEYbvnBd34F1bnnnedjvtvJyw2/eWrRf35ojGQ3BA2/HOxd+8aWO0fyNqIexZW6 tomYenLDXTatxlu63GShp4Wu2aK5k814pLcpars8eloYEBIHAP2C84ez1Dgo811jCk K4DRcBd3UYw5YEMiMHMe+A3/KjHy5F6yC6gRZnF+FcqZHPUMAgNS9u4tsnIXERXNFD GjOwgolSxVINw==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/beTrpc3uvkZd35vQy3PUyFEq5Zg
Cc: alexey.melnikov@isode.com, gen-art@ietf.org, salud@ietf.org, draft-ietf-salud-alert-info-urns.all@tools.ietf.org
Subject: Re: [salud] Gen-art LC review of draft-ietf-salud-alert-info-urns-12 and also Area Director's review
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 15:55:17 -0000

[as an author]

> From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
> 
> > > 13.  User Agent Behaviour
> > >
> > >    The User Agent (UA) MUST produce a reasonable rendering
> > >    regardless of the combination of URIs (of any schemes) in the
> > >    Alert-Info header field.
> > >
> > > This MUST is not well defined to be implementable. How can
> > > conformance or violation of this requirement can be tested? I
> > > suggest you avoid using RFC 2119 language here.
> > 
> > The authors agree and will change the MUST to "must".
> 
> Can we avoid lower case forms of RFC 2119 language as this just
> leaves the reader with the question as to whether there was an
> editing error.
> 
> I would suggest "The User Agent (UA) is expected to produce..."

It's a tricky matter.  What we really want is MUST, that this is a
constraint on the UA, particularly that it must be prepared to cope
with any sequence of syntactically-correct URIs, and it must do
something that is reasonable in the eyes of the user.  The problem is
that this criterion isn't testable in any absolute way, despite the
fact that there are a large number of actions that "everybody" would
agree are violations.

So the Gen-Art reviewer didn't like "MUST".  Unfortunately, he didn't
suggest an alternative.

As far as I can tell, "must" is fairly common in RFCs.  Over half the
RFCs from 6000 to 6999 use "must" (outside of boilerplate language).
Many of them use it in a more-or-less normative way.

RFC 2119 gives this guidance, for what it's worth:

   6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for

At this time, I prefer "must" over "MUST", but I prefer "MUST" over
"is expected to" or anything that is similarly indirect.

Dale

v2.23.0 | Report a Bug | By Email