Subject: RE: [Simple] Request URI in NOTIFY

From: "Iliff, Tina" <[email-masked]>
Date: Thu, 26 Jul 2001 14:49:42 +0000

Just my little 2 cents worth....I would assume that the Presentity when
acting as a watcher would use the same address in the Contact header of the
Subscribe as it uses in the REGISTER Contact header with Methods=Notify
parameter.
 
Is this a correct assumption?
 
Tina Iliff

-----Original Message-----
From: Ngo, Dai (c) 
Sent: Thursday, July 26, 2001 9:29 AM
To: [email-masked]
Subject: [Simple] Request URI in NOTIFY
 
Adam et al, 
In section 5.2.2 of the SIP-Specific Event Notification
(draft-ietf-sip-events-00.txt) it states that "The Request URI of a NOTIFY
request contains enough information to route the request to the party which
is subscribed to receive notifications. It is derived from the "Contact"
header present in the corresponding SUBSCRIBE request.". I think this
statement is only true in general, except in the following case:
In the case of the Presentity, who is being subscribed to be watched, has
registered with a contact specified with a Methods=NOTIFY, the address
location specified with a Methods=NOTIFY in the Contact header should be
used as the Request URI instead.
Have I missed something? 
Please clarify. Thanks. 
-- Dai

---

From: "Zane Thomas" <[email-masked]>
Date: Thu, 26 Jul 2001 11:30:18 -0700

Request URI in NOTIFY
Hmm, I'm reticent to raise this issue since I'm sure that it has been beaten to death in the past - I must have missed something in the archives.  However ...

Could someone explain to me why modifying SIP to support Presence etc is being considered?  There have been some instances in the archived discussions where proposed solutions for handling authorization lists, for instance, have become discussions about what's the best SIP-way to handle the problems being discussed.  The net result, for me, has been the impression that SIP has its own simple and reasonably well-defined goals which are distinct *for the most part* from those of Presence, and that trying to merge the two sets of goals will limit and complicate both.

I wonder, for instance, why it's not simply good enough to add something like:

    <pres:[email-masked]>

to the Contact header and then have a seperate and unconstrained discussion of presence subscriptions and related issues.

Zane

---

From: Ben Campbell <[email-masked]>
Date: Thu, 26 Jul 2001 15:14:20 -0500

Zane Thomas wrote:

>  
> 
> Hmm, I'm reticent to raise this issue since I'm sure that it has been 
> beaten to death in the past - I must have missed something in the 
> archives.  However ...
> 
>  
> 
> Could someone explain to me why modifying SIP to support Presence etc is 
> being considered?  There have been some instances in the archived 
> discussions where proposed solutions for handling authorization lists, 
> for instance, have become discussions about what's the best SIP-way to 
> handle the problems being discussed.  The net result, for me, has been 
> the impression that SIP has its own simple and reasonably well-defined 
> goals which are distinct *for the most part* from those of Presence, and 
> that trying to merge the two sets of goals will limit and complicate both.
> 
>  
> 
> to the Contact header and then have a seperate and unconstrained 
> discussion of presence subscriptions and related issues.
> 
>  
> 

Well, the SIMPLE working group charter mandates presence and instant 
messaging over SIP.

---

From: "Zane Thomas" <[email-masked]>
Date: Thu, 26 Jul 2001 14:21:28 -0700

Ben,

> Well, the SIMPLE working group charter mandates presence and instant

I'd like to make it clear that I'm not *arguing* that the charter is
problematic,  however it could be the case that it just doesn't work out in
the long run.  That - correct or not - was the impression I got as I read
the past few months emails.

Well, however it works out, here's one of my favorite all-time sayings:

   "The nice thing about standards is that there are so many of them to
choose from."

Zane