Re: [salud] End of IETF Last Call

Paul Kyzivat <> Fri, 25 April 2014 21:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 889D81A06AD for <>; Fri, 25 Apr 2014 14:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BVMRyhVSGFsS for <>; Fri, 25 Apr 2014 14:57:55 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:64]) by (Postfix) with ESMTP id 951411A050E for <>; Fri, 25 Apr 2014 14:57:55 -0700 (PDT)
Received: from ([]) by with comcast id uMFE1n0040Fqzac57MxpTH; Fri, 25 Apr 2014 21:57:49 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id uMxo1n0103ZTu2S3UMxoZG; Fri, 25 Apr 2014 21:57:49 +0000
Message-ID: <>
Date: Fri, 25 Apr 2014 17:57:48 -0400
From: Paul Kyzivat <>
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
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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==
Subject: Re: [salud] End of IETF Last Call
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

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?