Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt

Paul Kyzivat <pkyzivat@cisco.com> Thu, 29 October 2009 13:05 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6979D3A696B for <dispatch@core3.amsl.com>; Thu, 29 Oct 2009 06:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.575
X-Spam-Level:
X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3RYpkc5XTiP for <dispatch@core3.amsl.com>; Thu, 29 Oct 2009 06:05:00 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 53EB73A68D8 for <dispatch@ietf.org>; Thu, 29 Oct 2009 06:05:00 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAGQv6UpAZnwM/2dsb2JhbADEXZgXhD0E
X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="65518651"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2009 13:05:16 +0000
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TD5FCb018577; Thu, 29 Oct 2009 13:05:15 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:05:15 -0400
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:05:15 -0400
Message-ID: <4AE9930A.3040204@cisco.com>
Date: Thu, 29 Oct 2009 09:05:14 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de> <4AE850B9.80607@cisco.com> <4AE872F1.90108@softarmor.com> <4AE880A4.3060702@cisco.com> <FE639E83-0D65-462D-9394-02632199470E@softarmor.com>
In-Reply-To: <FE639E83-0D65-462D-9394-02632199470E@softarmor.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Oct 2009 13:05:15.0293 (UTC) FILETIME=[74E52CD0:01CA5898]
Cc: anwars@avaya.com, dispatch@ietf.org, L.Liess@telekom.de
Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Oct 2009 13:05:01 -0000

Dean Willis wrote:
> 
> On Oct 28, 2009, at 12:34 PM, Paul Kyzivat wrote:
> 
>>
>>
>> Dean Willis wrote:
>>> Paul Kyzivat wrote:
>>>> But that works more easily if the Alert-Info URNs are mutually
>>>> exclusive, so the recipient just chooses one it understands and renders
>>>> that.
>>>>
>>>> But I guess it can still work in the multi-dimensional approach. Each
>>>> URN that is understood must imply the values of one or more of those
>>>> dimensions.
>>> this is starting to sound like multipart/related and 
>>> multipart/alternative.
>>> Perhaps we are barking up the wrong tree, and alerts should be body
>>> parts selected by a new content-disposition?
>>
>> Did you imply a smiley on this message?
>>
>> On the off chance that you did not, its important that it be possible 
>> for intermediaries to add the Alert-Info, which pretty much excludes 
>> using body parts.
> 
> Not if the intermediaries are B2BUAs.  I'm wondering about alert-info 
> and authentication. Perhaps anything that can change the alerting model 
> really OUGHT to be a B2BUA and capable of re-authenticating the request.

My philosophy has always been that a UA must be very careful about 
trusting Alert-Info unless it is in an environment where something it 
trusts is doing screening for it.

The URN approach helps with this, because then the UA is only using the 
URN as a key into a database of of alerts that the UA is willing to 
render. But even so, some care is required. For instance, the "internal" 
vs. "external" ring choice would not be very effective if an arbitrary 
caller could decide whether it was internal or external. If that 
decision isn't made by the UA itself, then it needs to be made by 
something it trusts.

That doesn't *necessarily* mean that the screening server must be a 
B2BUA. It could be a proxy if used in a controlled topology. The "sip 
pbx" implementations I'm familiar with *are* B2BUAs, but I think some 
are not.

Also, even without trust, some info inserted by intermediaries might be 
acceptable to a UA. For instance, a proxy in front of the callee might 
insert an Alert-Info in the 180 indicating that the call was coming from 
France, proposing a French ringback tone. The caller, if it is capable 
of understanding that, may be willing to render it that way even though 
it doesn't know the callee or have any particular trust in it.

	Thanks,
	Paul