[Sip] FW: [Simple] Questions on the current presence draft.

"Brian Stucker" <bstucker@nortelnetworks.com> Wed, 12 September 2001 21:21 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03312 for <sip-archive@odin.ietf.org>; Wed, 12 Sep 2001 17:21:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09735; Wed, 12 Sep 2001 17:05:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09704 for <sip@optimus.ietf.org>; Wed, 12 Sep 2001 17:05:30 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02990 for <sip@ietf.org>; Wed, 12 Sep 2001 17:05:00 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA05016 for <sip@ietf.org>; Wed, 12 Sep 2001 16:04:25 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 12 Sep 2001 15:57:57 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <SK3LKPV5>; Wed, 12 Sep 2001 16:04:15 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E43035ED169@crchy271.us.nortel.com>
From: Brian Stucker <bstucker@nortelnetworks.com>
To: SIP mailing list <sip@ietf.org>
Date: Wed, 12 Sep 2001 16:04:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13BCE.74C824E0"
X-Orig: <bstucker@americasm01.nt.com>
Subject: [Sip] FW: [Simple] Questions on the current presence draft.
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Normally wouldn't cross-post, but the SIMPLE list seems to not be working.
 
Brian
 
-----Original Message-----
From: Stucker, Brian [NGB:B651:EXCH] 
Sent: Tuesday, September 11, 2001 2:30 PM
To: 'simple@mailman.dynamicsoft.com'
Subject: [Simple] Questions on the current presence draft.



I was reading through the current draft, and noticed a few things that I 
was looking for clairification on. 

In the section on presence migration, the last sentence of the description 
for the second phase of presence migration states: "...This informs the
subscribers that their 
subscription was destroyed, and should be re-established with a new
SUBSCRIBE (with a new Call-ID)." 

I was wondering, if a watcher was offline when the NOTIFY containing the
"Subscription-Expires" header 
to destroy the current subscription, what are the implications with the call
id? I would imagine when the 
watcher comes back online, and tries to refresh the subscription, it would
use the old call-id (since it doesn't 
know that it needs to reselect), which gets proxied to the new PA (after the
migration occurred). This seems like a gap to me.

Also, what happens if the watchers (previous to the migration) never receive
the NOTIFY to update their 
subscriptions to cause a refresh. Unless they do a fetch, the new PA doesn't
know that they exist, so their 
subscriptions will be effectively moot, but they won't be aware of this
fact. They won't get any notifications, and 
won't know that their subscriptions are being ignored. 

In section 8, there are mixed uses of the presence URL and SIP URL's. Is
this done intentionally? 

Finally, can someone point a link to the draft listed as [4] in the
bibliography? It doesn't seem to be available 
at the IETF webpage. 

Thanks, 

Brian