[salud] Section 13 (was: Gen-art LC review of draft-ietf-salud-alert-info-urns-12)

worley@ariadne.com (Dale R. Worley) Thu, 08 May 2014 20:13 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 []) by ietfa.amsl.com (Postfix) with ESMTP id D00E71A0095 for <salud@ietfa.amsl.com>; Thu, 8 May 2014 13:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NDuceGhRb9bl for <salud@ietfa.amsl.com>; Thu, 8 May 2014 13:13:07 -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 D13EB1A010D for <salud@ietf.org>; Thu, 8 May 2014 13:13:06 -0700 (PDT)
Received: from omta10.westchester.pa.mail.comcast.net ([]) by qmta12.westchester.pa.mail.comcast.net with comcast id zY4F1n0080cZkys5CYD1W0; Thu, 08 May 2014 20:13:01 +0000
Received: from hobgoblin.ariadne.com ([]) by omta10.westchester.pa.mail.comcast.net with comcast id zYD11n01A1KKtkw3WYD1fp; Thu, 08 May 2014 20:13:01 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com []) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s48KD0sC026018; Thu, 8 May 2014 16:13:00 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s48KD0S8026017; Thu, 8 May 2014 16:13:00 -0400
Date: Thu, 8 May 2014 16:13:00 -0400
Message-Id: <201405082013.s48KD0S8026017@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <201405061853.s46Ire8K007213@hobgoblin.ariadne.com> (worley@ariadne.com)
References: <535E50C1.2060100@isode.com> <201405061853.s46Ire8K007213@hobgoblin.ariadne.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399579981; bh=XhoondbdhIyj4MbuipqDZxay/XaNzP+mvnJSMAO3Iyw=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=g7rCQF4W0x/XBVCs4EsO3hvAl+NuADejHBlzg/4CYuDzdHYO298ETDOmNj2le48+L 6B0MGvMAJ0dwyOBuuNSO2MUPdkHxQqd4dK38FPPqTvKQXEMpj5R+CnfL8M1/Z8TLDZ z9MNPU+8EMmYDNMlZF4guZ9iwCsTQ6ZfOIrheJu09LppGCUrFi76CQ2QD//efBU89+ p5dcm/AyJ3xdjGosImyq0eFJuREIDJURr/Q6X+wFTqA5IQWpE0Njk2U50n7dQdjzAc fDn+24njcHuI3r4/Cti15KNpS90ywP6VuRFL7g0U9TXv4mWzIl/wTwb6xCDaqvIxCC M0f/w3tk4CMXg==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/dmPiunt4AW1hf0sAlTRVehvkSzA
Subject: [salud] Section 13 (was: Gen-art LC review of draft-ietf-salud-alert-info-urns-12)
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: Thu, 08 May 2014 20:13:09 -0000

[as an author]

Acting on Ben Campbell's suggestion that we consider revising the
first sentence of section 13 so that it can support a MUST, I've
written a revision:

[In this message, I've separated the three sentences to make
comparisons easier; it is all one paragraph.  I changed "explicitly
instructed" to "instructed" in sentence 3.]

     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:

     It MUST produce a rendering based on the URIs that it can
     understand and act on (if any), interpreted as prescribed by
     local policy, and ignore the other URIs.

     In particular, unless the containing message is a request and is
     immediately rejected, the UA SHOULD provide some alert unless it
     is instructed not to (for example, by Alert-Info URIs that it
     understands, the presence of a Replaces or Joins header field,
     local policy, or direction of the user).

What do people think?

I think that sentence 2 is really what we intended by sentence 1.  I
left in sentence 1 to give guidance to the overall idea, while
sentence 2 gives the details.

I included "URIs that it can ... act on", because it's possible that a
UA could receive an http: URI but be unable to fetch its contents, or
be unable to decode the fetched contents.

Of course, sentence 2 allows a lot of latitude for implementations,
because it says "interpreted as prescribed by local policy", but I
think it gives the right effect, because, e.g., I don't think anyone
is willing to say "local policy is that if we can't process a URI, we
will just generate white noise".

In sentence 3, I removed "explicitly" because a number of the listed
factors that "instruct" the UA not to alert aren't really "explicit".

And I found another cause not to alert:  re-INVITEs.  But I didn't add
it to the list, because we already list 5 factors.  Presumably the
implementors will understand that.

However, I think that the fact that we've found another factor shows
that we want this requirement to be a SHOULD.  As it says in RFC 2119:

   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.