Subject: RE: [Simple] Multiple 200 Ok

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Oct 2001 20:45:29 -0400

Another old thread. The issue was how a subscriber knows the identity of the
actual PA which answered the SUBSCRIBE, since it may have been forwarded.

Response inline.

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Friday, October 05, 2001 11:02 AM
To: Jonathan Rosenberg; Brazier Lachlan; Jonathan Rosenberg; ''Neil Deason'
'; ''SIMPLE Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok

>I'm a bit worried about using the contact header in the 2xx as a means of 
>identifying the user that processed the SUBSCRIBE. The watcher has no
method 
>of determining the user's contact list to check the contact received 
>against. So I don't see a reliable method of taking a contact and
determining 
>the user that contact is for unless you're the registrar (and even then it 
>can be ambiguous). If you have a proxy that straddles a firewall, it will 
>probably modify the contact address in the 2xx response, so the contact
returned 
>may be one that only the proxy knows who it maps to, and nobody else. 

I agree that Contact is far from ideal.

Remote-Party-ID is really much better, since it provides a logical identity,
and thats exactly what you want.

I don't want to mandate the usage of R-PID for this, as it introduces a
dependency. So, I will simply indicate that the privacy spec can be used if
you want to provide the identity of the PA which actually answered. This
makes the reference non-normative and therefore there is no dependency.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 24 Oct 2001 09:28:58 -0500

That'll work.

Thanks.

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, October 23, 2001 7:45 PM
To: Stucker, Brian [NGB:B621:EXCH]; Neil Deason; Brazier Lachlan;
'Jonathan Rosenberg'; ''SIMPLE Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok

Another old issue that I want to make sure is closed.

Let me summarize the discussion. The question was this: if a PA gets a
request, and the request-uri matches that of a user that the PA represents,
but the To field doesn't, what do you do? The conclusion of this thread is
that it is up to the policy of the PA as to whether it accepts subscriptions
that were originally targeted at a different UA (which is what it means when
the r-uri and to field don't identify the same user). This is not presence
specific at all, as this happens with sip in general when requests are
forwarded. The only question was this: what response code to use in this
case?

I believe 403 is correct; it does not imply that the subscription can never
be retried, just that right now, retrying it against this PA won't help any
more.

Furthermore, this is not presence specific, and belongs in SIP itself.
bis-05 actually has a subsection on UAS processing which describes how a uas
determines if it should process a request. The section provides response
codes to use in specific cases, and this case, and the 403, will be
described there. I will also mention this case in the presence spec.

-Jonathan R.

---
  
-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Friday, October 05, 2001 11:10 AM
To: Neil Deason; Brazier Lachlan; 'Jonathan Rosenberg'; ''SIMPLE
Mailinglist' '

Would it be a 403 forbidden? If a 403 were sent back because the 
only routable PA wasn't willing to process the subscription, wouldn't 
this cause the would-be watcher to not try again later when other 
PA's may be available (via forking) that could process the request? 
I would think a 404 or a 488 response would be a better fit. 
... 
When is that new events draft going to appear? Until that comes out 
the NOTIFY with expires = 0 is the way you force-expire a subscription. 
Regards, 
Brian 
-----Original Message----- 
From: Neil Deason [mailto:[email-masked]] 
Sent: Friday, October 05, 2001 9:52 AM 
To: Brazier Lachlan; 'Jonathan Rosenberg'; Stucker, Brian 
[NGB:B621:EXCH]; ''SIMPLE Mailinglist' ' 
Subject: RE: [Simple] Multiple 200 Ok 

> From: Brazier Lachlan [mailto:[email-masked]] 
> 
> Hi, 
> 
> generally I agree with you about Authorisation and Authentication. 
> 
> Let me reformulate the question. Which response do I send back, when I 
> received a SUBSCRIBE, and I'm not allowed or not willing to be the 
> presentity (This can happen if someone defines me as 
> presentity without 
> letting me know - as the way of authorization is not in the 
> scope of the 
> presence draft, errors might happen)? 
403 would do. 
> I have a question concerning the Call flows in the draft. 
> When a PA receives a SUBSCRIBE with an Expires header, the 
> response contains 
> an Expires header as well. What would an Expires header in a 
> NOTIFY request 
> sent from the PA to the Watcher mean? Would this update the 
> subscription 
> expiration time? 
> 
> An example: 
> userA subscribes for user userB. As userB is a friend of 
> userA, he accepts 
> the subscription and the call flows just get on. 
> After some time userB doesn't want to be the presentity of 
> userA anymore, or 
> maybe userB changes the contact information for the SUBSCRIBE 
> request at 
> it's registrar. 
> Now, can userB (better said the PA of userB) send a NOTIFY 
> with an Expires 
> header with value 0 to tell userA, that it's subscription 
> expiration time is 
> over? 
> 
> I think it should be possible to do so, because if not, userB 
> would need to 
> wait for the next SUBSCRIBE request from userA, before he can 
> tell him, that 
> the subscription time is over. This could be a time value 
> from seconds to 
> days, month, years, etc. 
> 
> 
> If there is another mechanism to do so, which one would it be? Maybe a 
> NOTIFY with an empty body? 
There current proposal is to use a new header, 
Subscription-Expires in NOTIFY instead of overloading 
Expires to indicate when a subscription will end. 
draft-ietf-simple-presence-03.txt refers to this in 
describing how PA functionality migrates (5.12). This 
header still needs to be detailed in a revised 'SIP 
specific event notification' draft. 
Cheers, 
Neil. 
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

---

From: "Sriram Parameswar" <[email-masked]>
Date: Wed, 24 Oct 2001 10:45:26 -0500

Even the RPI may be blocked by Proxies that do not trust the preceding
proxy. So we may not have solved the issue fully.

Regards,

Sriram
__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: [email-masked]

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, October 23, 2001 7:45 PM
To: Stucker, Brian [NGB:B621:EXCH]; Jonathan Rosenberg; Brazier Lachlan;
Jonathan Rosenberg; ''Neil Deason' '; ''SIMPLE Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok

Response inline.

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Friday, October 05, 2001 11:02 AM
To: Jonathan Rosenberg; Brazier Lachlan; Jonathan Rosenberg; ''Neil Deason'

method 
determining 
returned 

-Jonathan R.

---