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
- [dispatch] New version for the Alert-Info URNs dr… L.Liess
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] [BLISS] New version for the Alert-… Elwell, John
- Re: [dispatch] New version for the Alert-Info URN… L.Liess
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] [BLISS] New version for the Alert-… L.Liess
- Re: [dispatch] [BLISS] New version for the Alert-… Elwell, John
- Re: [dispatch] New version for the Alert-Info URN… L.Liess
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… Dean Willis
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… Dean Willis
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… Alan Johnston
- Re: [dispatch] New version for the Alert-Info URN… Alan Johnston
- Re: [dispatch] New version for the Alert-Info URN… Francois AUDET
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… L.Liess
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… Adam Roach
- Re: [dispatch] New version for the Alert-Info URN… Adam Roach
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… L.Liess
- Re: [dispatch] New version for the Alert-InfoURNs… Spencer Dawkins