[salud] End of IETF Last Call

worley@ariadne.com (Dale R. Worley) Fri, 25 April 2014 21:31 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 D54CF1A0670 for <salud@ietfa.amsl.com>; Fri, 25 Apr 2014 14:31:52 -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 pURdCN6LzTv0 for <salud@ietfa.amsl.com>; Fri, 25 Apr 2014 14:31:51 -0700 (PDT)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 082831A0345 for <salud@ietf.org>; Fri, 25 Apr 2014 14:31:50 -0700 (PDT)
Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id uKbA1n0021ZXKqc57MXku0; Fri, 25 Apr 2014 21:31:44 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta21.westchester.pa.mail.comcast.net with comcast id uMXj1n00x1KKtkw3hMXjN7; Fri, 25 Apr 2014 21:31:44 +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 s3PLVhgS032604; Fri, 25 Apr 2014 17:31:43 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3PLVgQC032602; Fri, 25 Apr 2014 17:31:42 -0400
Date: Fri, 25 Apr 2014 17:31:42 -0400
Message-Id: <201404252131.s3PLVgQC032602@hobgoblin.ariadne.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: salud@ietf.org
In-reply-to: <20140425070710.22327.70675.idtracker@ietfa.amsl.com> (iesg-secretary@ietf.org)
References: <20140425070710.22327.70675.idtracker@ietfa.amsl.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398461504; bh=54o8qzj0Bh0dbSKwYTHN5kluQw2UYphwe73VMxj2vnY=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=QRZIAYJetNmOIfXsZjYZ9pOWMIOaK0TtEObL3jDDLqaWg4s1LUOWCAlw0YPu3wAB8 F4YJJfuALt5DA2oytZg6izlr05JtEoP1bkwckCOTHgvNYKYm4TeNE0PKh1kI8KfzP3 X9bRY9pRE5UlLM9b0hQzgr8Rxo/qUSkaT+++VlA/Ik8QqJmeCcUu6u8K95qjtZRxCP o9PCZxYHOTttxswclOLDgpdaYlGwkKwEN3SZI71g1dunVXj7t4VZiT62+8ttSYtV+b L0o+rI4nRPCyPosu1CxIf5I6j8s4qOtMYDclGSz4qzXHEQxQniI0pGkuZToBdOfPoD 82jP9aBFNM9XQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/hx2PmMHF6uydiNlI4eK-Wl9KE44
Subject: [salud] End of IETF Last Call
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: Fri, 25 Apr 2014 21:31:53 -0000

[as chair]

The IETF Last Call for the draft has ended.  The next step is to
ensure that all the Last Call comments are handled, and then Richard
can provide a write-up that officially defines the standards action
requested of the IESG.
(https://datatracker.ietf.org/doc/help/state/draft-iesg/)  Then the
draft can be placed before the IESG for approval.

There were no Last Call comments.

However, Richard raised a number of issues for the authors to
consider, and I think it is approporiate to handle them at this time.

[as an author]

Richard has raised a number of issues in his AD Review
(http://www.ietf.org/mail-archive/web/salud/current/msg00496.html).  I
think that we have satisfied Richard that the issues require no change
in the draft, with the possible exception of the following issue, for
which I think it might be useful to add a sentence to section 13.
Personally, I'm not sure that it's strictly necessary, but it might
ensure that implmentations avoid a certain class of error that would
be easy to make:

http://www.ietf.org/mail-archive/web/salud/current/msg00503.html

> > Section 13 says that the UA MUST provide a "reasonable rendering".   How do
> > I tell if a UA meets that criterion?  Might be better to add in Section 11
> > a requirement of the form, "if a UA cannot process the set of Alert URNs in
> > a message, then it MUST still provide some alert (chosen by local policy).
> >  Failure to parse Alert URNs MUST NOT cause a UA not to alert at a
> > all."
> 
> I was thinking that it might be desirable to add some text to cover
> Richard's issue.  On one hand, it seems that "reasonable rendering"
> should automatically include "the user can perceive it", but it might
> be useful to be explicit in regard to this particular feature of
> signals.
> 
> One way to do this would be to extend the last paragraph of section
> 13, which reads
> 
>    The User Agent (UA) MUST produce a reasonable rendering regardless of
>    the combination of URIs (of any schemes) in the Alert-Info header
>    field.
> 
> by adding
> 
>    In particular, under any circumstances a UA MUST provide some alert
>    unless it is explicitly instructed not to (by Alert-Info URIs that
>    it understands, local policy, or direction of the user).

Dale