Re: [Sip] Event Lists: Back-End Credentials

Jonathan Rosenberg <jdrosen@cisco.com> Thu, 11 November 2004 21:17 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29007 for <sip-web-archive@ietf.org>; Thu, 11 Nov 2004 16:17:15 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMKv-0005Nk-Dp for sip-web-archive@ietf.org; Thu, 11 Nov 2004 16:18:34 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMAp-0008KO-Vs; Thu, 11 Nov 2004 16:08:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSM4i-0004kB-IO for sip@megatron.ietf.org; Thu, 11 Nov 2004 16:01:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27459 for <sip@ietf.org>; Thu, 11 Nov 2004 16:01:46 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSM5w-0004wo-7g for sip@ietf.org; Thu, 11 Nov 2004 16:03:05 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2004 13:15:23 -0800
X-BrightmailFiltered: true
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iABL1Aom010501; Thu, 11 Nov 2004 13:01:11 -0800 (PST)
Received: from [130.129.135.140] (sjc-vpn5-601.cisco.com [10.21.90.89]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFR48240; Thu, 11 Nov 2004 13:01:11 -0800 (PST)
Message-ID: <4193D317.5000604@cisco.com>
Date: Thu, 11 Nov 2004 16:01:11 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Sip] Event Lists: Back-End Credentials
References: <5816828233DEFA41807A6CFDFDF2343C3A8BD7@esebe056.ntc.nokia.com> <418101FF.9030506@nostrum.com> <41938CF6.60008@cisco.com>
In-Reply-To: <41938CF6.60008@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, Adam Roach <adam@nostrum.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: 7bit


Jonathan Rosenberg wrote:
> Its worth noting that this issue has come up in the context of 3gpp, 

Oops - s/3gpp/3pcc

> where it is actually even harder of a problem than it is here. I suggest 
>  folks read section 12.1 of RFC 3725.
> 
> Basically, what is says is that delegation is a hard problem, we don't 
> have a solution for it. So, in the interim, the 3pcc controller set the 
>  From in a specific way in order to be usable in applications which 
> (perhaps sadly) don't authenticate. And that's it.
> 
> I'm not sure if precedent of past acceptability of this kind of 
> statement can help us, but at least there is a precedent.
> 
> -Jonathan R.
> 
> 
> 
> Adam Roach wrote:
> 
>> hisham.khartabil@nokia.com wrote:
>>
>>>
>>>> A consequence of this is that, lacking any other mechanism, the 
>>>> resources in a resource list for which the RLS is not authoritative 
>>>> will contain only the information that their notifier is willing to 
>>>> reveal to the RLS -- which is generally the same information they 
>>>> would render to unauthenticated users. In some cases, this might 
>>>> result in no useful information being transferred.
>>>>   
>>>
>>>
>>>
>>> This limitation by itself kills the idea, IMO. Most presence lists 
>>> will rely on the event list, and if its gonna mean that no useful 
>>> information will come to the watcher, then the whole mecahnism is 
>>> useless.
>>>  
>>>
>>
>> That's a bit of a strong characterization, and it seems to ignore the 
>> remainder of the mail that I sent out; specifically:
>>
>>   1. Users have the ability to subscribe to any resources that the RLS
>>      marks itself as non-authoritative, and
>>   2. (More Importantly) Provisions for delegation of authority are
>>      included -- they're just not in-scope for this document.
>>
>> /a
>>
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip