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

Adam Roach <adam@nostrum.com> Thu, 28 October 2004 14:31 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 KAA17479 for <sip-web-archive@ietf.org>; Thu, 28 Oct 2004 10:31:02 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBWz-0002VR-VT for sip-web-archive@ietf.org; Thu, 28 Oct 2004 10:45:38 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBHh-0004ty-Oc; Thu, 28 Oct 2004 10:29:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBGH-0004LB-HT for sip@megatron.ietf.org; Thu, 28 Oct 2004 10:28:21 -0400
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 KAA17216 for <sip@ietf.org>; Thu, 28 Oct 2004 10:28:20 -0400 (EDT)
Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBUN-0002Sg-Fm for sip@ietf.org; Thu, 28 Oct 2004 10:42:55 -0400
Received: from [192.168.0.111] (adsl-209-30-28-252.dsl.rcsntx.swbell.net [209.30.28.252]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9SESGbZ022268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2004 09:28:18 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <418101FF.9030506@nostrum.com>
Date: Thu, 28 Oct 2004 09:28:15 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
Subject: Re: [Sip] Event Lists: Back-End Credentials
References: <5816828233DEFA41807A6CFDFDF2343C3A8BD7@esebe056.ntc.nokia.com>
In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C3A8BD7@esebe056.ntc.nokia.com>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 4.6 (++++)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, jdrosen@dynamicsoft.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: 4.6 (++++)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit

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

_______________________________________________
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