Re: [salud] End of IETF Last Call

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 25 April 2014 21:57 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 889D81A06AD for <salud@ietfa.amsl.com>; Fri, 25 Apr 2014 14:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
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 BVMRyhVSGFsS for <salud@ietfa.amsl.com>; Fri, 25 Apr 2014 14:57:55 -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 951411A050E for <salud@ietf.org>; Fri, 25 Apr 2014 14:57:55 -0700 (PDT)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta07.westchester.pa.mail.comcast.net with comcast id uMFE1n0040Fqzac57MxpTH; Fri, 25 Apr 2014 21:57:49 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id uMxo1n0103ZTu2S3UMxoZG; Fri, 25 Apr 2014 21:57:49 +0000
Message-ID: <535ADA5C.7010209@alum.mit.edu>
Date: Fri, 25 Apr 2014 17:57:48 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: salud@ietf.org
References: <20140425070710.22327.70675.idtracker@ietfa.amsl.com> <201404252131.s3PLVgQC032602@hobgoblin.ariadne.com>
In-Reply-To: <201404252131.s3PLVgQC032602@hobgoblin.ariadne.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398463069; bh=cQ8fFg0kj9yne9Qd+KOMGRKsSt+Ji4luOTgv7/ecI7c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=g41lOxYYCqjCn45qlFfUQBCRTHx+G+3zftK3onoGFxGzvP4KuhH/ek8nCg9Ob+/Ux Gb819uHTieX8gHwcx9Y/rpyMsLdsdhN7IRqA2H2HFJ4MTTkAZtvtgeOADKEd8eJbUy NfYFyDt95kRqjJ4cghE1/kiyiEFx0kd6c5hFM18FNmBGUXxJ1tywovb4WF/p9RVXZb BjorzJpsDWvk6mkVp9vx0cNRNl2GuG9PGqz4AfONtjGvD1ledOmniX0aA/FK1AiNAo jbgl6nGCOFPo20oxKakiIfYgZAA1WVfUC4mwT02iXYxFNVle/zrfGM+izpjilaP5Hy eSrfqlVob0uxQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/JmS1Y2R-QBFjiLgHB-_6BK-daXA
Subject: Re: [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:57:56 -0000

On 4/25/14 5:31 PM, Dale R. Worley wrote:

>> 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).

While contemplating this I got thinking:

What are expectations if you get an INVITE with both Alert-Info and 
Replaces?

Normally one expects that INVITE/Replaces won't alert. I suppose that 
expectation is really local policy. And ISTM that it would be really 
unusual to put an Alert-Info with it.

And how does that relate to Richard's question?

	Thanks,
	Paul