Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01

Dean Willis <dean.willis@softarmor.com> Mon, 03 March 2008 15:43 UTC

Return-Path: <sip-bounces@ietf.org>
X-Original-To: ietfarch-sip-archive@core3.amsl.com
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12EA13A6B04; Mon, 3 Mar 2008 07:43:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.596
X-Spam-Level:
X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 ff0mOa0r1yOm; Mon, 3 Mar 2008 07:43:23 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78803A69DD; Mon, 3 Mar 2008 07:43:23 -0800 (PST)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23EFB3A6952; Mon, 3 Mar 2008 07:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 dKVCBL2ebekm; Mon, 3 Mar 2008 07:43:17 -0800 (PST)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 448083A6927; Mon, 3 Mar 2008 07:43:02 -0800 (PST)
Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m23Fgioo018796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Mar 2008 09:42:45 -0600
Message-Id: <6CBA6241-389B-493E-8B16-AD51704CC104@softarmor.com>
From: Dean Willis <dean.willis@softarmor.com>
To: Aki Niemi <aki.niemi@nokia.com>
In-Reply-To: <1204465324.1597.30.camel@localhost>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Mon, 03 Mar 2008 09:42:39 -0600
References: <5D1A7985295922448D5550C94DE2918001636AF1@DEEXC1U01.de.lucent.com> <200709181506.l8IF6Bmp007748@dragon.ariadne.com> <1203976392.6192.88.camel@localhost> <200802262131.m1QLV7Rm008476@dragon.ariadne.com> <1204099738.16881.21.camel@localhost> <200803010308.m2138gWu024969@dragon.ariadne.com> <1204465324.1597.30.camel@localhost>
X-Mailer: Apple Mail (2.919.2)
Cc: sip@ietf.org, "ext sip-bounces@ietf.org" <sip-bounces@ietf.org>
Subject: Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

On Mar 2, 2008, at 7:42 AM, Aki Niemi wrote:

>
> On pe, 2008-02-29 at 22:08 -0500, ext sip-bounces@ietf.org wrote:
>>   Then that's bad. How does the notifier then know which PIDF to  
>> pick in
>>   presence subscriptions?
>>
>> Especially if it's not a presence subscription.  But seriously, is
>> this proposal confined to presence events?  I see no such text.
>
> Of course it is not. But clearly presence won't work correctly, if the
> notifier doesn't know which URIs route to it, i.e., which resources it
> is responsible for. I assume this to be the case for most applications
> of SIP events. Can you give an example of a currently specified event
> package that doesn't require this?

I have yet to figure out how a multiuser UA  (including an event  
server) is supposed to function if:

1) The To: field does not indicate the user being targeted, which  
happens if a UAC-side proxy retargets, as in the case of a speed-dial  
service, and

2) The request-URI does not indicate the user being targeted, which  
happens in many cases including when the UAS-side proxy does contact- 
routing AND the user-part of the contact isn't differentiated per- 
user. It also occurs with some load-balancers. That's part of why we  
don't specify bulk registration in RFC 3261, but instead recommend  
using routing table entries.

--
Dean
_______________________________________________
Sip mailing list  https://www.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