Subject: RE: [Simple] Multiple 200 Ok

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 2 Oct 2001 10:08:02 -0400

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2001 7:36 AM
> To: Brazier Lachlan; 'SIMPLE Mailinglist'
> Subject: RE: [Simple] Multiple 200 Ok
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Brazier
> > Lachlan
> > Sent: 02 October 2001 10:42
> > To: 'SIMPLE Mailinglist'
> > Subject: [Simple] Multiple 200 Ok
> > 
> > 
> > Hello,
> > I refer to "5.10 Handling of Forked Requests" in
> > "draft-ietf-simple-presence-03.txt".
> > .....
> > ....Some of these may respond with a 2xx response to the 
> > SUBSCRIBE. Based on
> > the forking rules in SIP, only one of these
> >    responses is passed to the subscriber. ...
> > .....
> > 
> > As far as I remember, a proxy always passes a 2xx response 
> > upstream. Even if
> > a forking proxy cancels other branches on receiving a 2xx, 
> > the CANCEL can
> > still cross on the line with a 2xx response. A scenario would 
> > be, that one
> > branch returns a 202 response first, and then another branch 
> > returns a 200
> > Ok response.
> 
> For non-INVITEs a proxy must forward only a single response 
> upstream, 2xx or otherwise. INVITEs are a special case
> where all 2xxs must be forwarded. This is because of the
> different reliability mechanisms at play. Non-INVITEs 
> requests are retransmitted until a response is received.
> Therefore only a single response can ever be transmitted
> reliably. 2xxs for INVITEs have end to end reliability 
> so all of them must be sent back so they can be ACK'd
> by the UAC. See section 14 of bis for the full details.

Right.

> > So, if the proxy passes all 2xx message upstream, does the 
> > subscriber have
> > finally subscribed to more than one user? How can a 
> > subscriber realize, that
> > a forking proxy forked to a different user (this can happen 
> > when I am on
> > holiday, and I register my working collegue with my working 
> > SIP Url - and
> > then somebody wants to subscribe for me)?

Even without multiple 200 OK being forwarded to the subscriber, a single
SUBSCRIBE can still fork, and result in the creation of multiple
subscriptions. The subscriber will find out about these from the NOTIFY that
get sent, and will respond with a 481 to all but one, cancelling them. This
is all described in Section 5.12 of the presence spec.

-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

---

From: Brazier Lachlan <[email-masked]>
Date: Tue, 2 Oct 2001 18:02:53 +0200

Hello,
thank you for your clarification. There is still this one point open:

> > > How can a 

I believe, the problem can occur, when a proxy changes the request-URI. This
would mean, that the proxy sends a SUBSCRIBE to another presentity. I still
can't see, how the subscriber knows, that his SUBSCRIBE request was handled
by a different user.

I could imagine, that in the first NOTIFY after receiving the SUBSCRIBE
request, the FROM header is different than the To header from the SUBSCRIBE
request. Is this valid with the draft?

thanks again 
Lachlan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 2 Oct 2001 22:38:08 -0400

> From: Brazier Lachlan [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2001 12:03 PM
> To: 'Jonathan Rosenberg'; 'Neil Deason'; 'SIMPLE Mailinglist'
> Subject: AW: [Simple] Multiple 200 Ok
> 
> 
> Hello,
> would mean, that the proxy sends a SUBSCRIBE to another 
> presentity. 

Changing the request URI does not imply chaging the presentity. Changing it
may occur in order to address the request to the presentity at a different
location.

I still
> can't see, how the subscriber knows, that his SUBSCRIBE 

The entity that finally responds to the SUBSCRIBE will place, in the 2xx, a
Contact header that contains their URL.

> request. Is this valid with the draft?

No; as it stands, the To/From are flipped in the NOTIFY from the presentity.

-Jonathan R.
---

---

From: Brazier Lachlan <[email-masked]>
Date: Wed, 3 Oct 2001 08:51:02 +0200

Hello,
as far as I see, the problem lays in the registration. Is there a way to
tell a registrar, that the registered address belongs to a different user?

I really believe a subscriber should know if he is subscribed to the right
person. As example imagine a subscriber, who subscribes for you, and when
you are online, sends you private documents automaticly. You probably don't
want this to happen.

I think the same might be true for INVITE. Imagine a video service, where a
video provider starts a video session, without knowing that you are not the
right customer, and not knowing that you are on holiday. (An example would
be a timed wakeup call or something like this) 

A solution I might think of, is to add a new parameter to the Contact
header, indicating if I am really the user addressed to, or in a REGISTER
request, to tell the registrar if the registered address "belongs" to me or
a different user at all.

Is this nonsense I am talking? 

Lachlan

-----Originalnachricht-----
Von: Jonathan Rosenberg
An: 'Brazier Lachlan'; Jonathan Rosenberg; 'Neil Deason'; 'SIMPLE
Mailinglist'
Gesendet: 03.10.01 04:38
Betreff: RE: [Simple] Multiple 200 Ok

> would mean, that the proxy sends a SUBSCRIBE to another 

Changing the request URI does not imply chaging the presentity. Changing
it
may occur in order to address the request to the presentity at a
different
location.

I still
> can't see, how the subscriber knows, that his SUBSCRIBE 

The entity that finally responds to the SUBSCRIBE will place, in the
2xx, a
Contact header that contains their URL.

> request. Is this valid with the draft?

No; as it stands, the To/From are flipped in the NOTIFY from the
presentity.

-Jonathan R.
---

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 4 Oct 2001 18:23:23 -0500

I don't think it's non-sense...

Ugh.. The requestURI bit does cause some serious problems. If you run a
SUBSCRIBE
through a BBUA, that can change the requestURI as well. Yuck. Why don't we
consider
the TO party the presentity instead, and change the wording in the first
paragraph
of section 5.3 to reflect that? Then it becomes a lot nicer. In that case,
if 
the user in the TO of the SUBSCRIBE is not a user served 
by the presence agent that the subscribe was forked to, that presence agent 
should 603 the SUBSCRIBE. In essence, don't use the requestURI for
establishing
the identity of the presentity on the actual presence agent. It could go
through
a BBUA or fork to another user (as you suggest) and get munged along the
way, so
use it just for routing purposes.

I think that'll fix it. Presence agents shouldn't accept subscriptions just
because
they understand how to process a SUBSCRIBE and the requestURI matches them. 
They need to also take into account who they are authorized to represent the

presence for when deciding to accept a SUBSCRIBE or not. 

The other reason that I can think of, and this ties in somewhat with
migration problems,
is if we consider the presence agent for the presentity to be the presence
server. If
a presence server is in the network, clients can't always be expected to
know the
requestURI of the presence server that's serving the presentity they're
interested in
watching. The requestURI would start out (I would think, in general) equal
to the TO
header URI, which would be the user@domain address of the presentity. A
proxy along
the way would have to notice that this is a presence subscription, and
change the
requestURI to be the presence server before forwarding it, or the presence
server
would always have to be included in the list of registered contacts for the
user (which
may require the presence server to make a third party registration to the
presentity).

An exception would have to be made on the requestURI for a presence server
to ever be
able to process the subscription, which again goes back to the idea that the
requestURI
is only for routing, and the TO field identifies the actual presentity we're
interested in.

If this requirement comes from the events framework draft, then the events
framework draft
needs to be changed in order to accomodate BBUA's and things like presence
servers in the mix.

Regards,

Brian Stucker
Nortel Networks

-----Original Message-----
From: Brazier Lachlan [mailto:[email-masked]]
Sent: Wednesday, October 03, 2001 1:51 AM
To: 'Jonathan Rosenberg '; Brazier Lachlan; ''Neil Deason' '; ''SIMPLE
Mailinglist' '

 Hello,

Lachlan

-----Originalnachricht-----
Von: Jonathan Rosenberg

I still

-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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 4 Oct 2001 22:18:26 -0400

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Thursday, October 04, 2001 7:23 PM
To: Brazier Lachlan; 'Jonathan Rosenberg '; ''Neil Deason' '; ''SIMPLE
Mailinglist' '

SUBSCRIBE 
consider 
paragraph 
if 

>should 603 the SUBSCRIBE.

Absolutely, positively NOT.

It is fundamental to the entire SIP model that a request can traverse many
hops (proxies), each hop modifying the request URI based on local policy,
ultimately reaching a recipient. Any particular hop can only make routing
and processing decisions if the target of the request is within the
namespace managed by that hop. What you are proposing would violate that,
and break the protocol, both SIP and SIMPLE, totally. 

Yes, it is helpful to know who that recipient ultimately is. The COntact
header in the 2xx, as I have already stated, provides some form of identity.
Even better is the Remote-Party-ID header from the privacy extension. 

>In essence, don't use the requestURI for establishing 
through 
way, so 
>use it just for routing purposes. 

Wrong.

because 

>presence for when deciding to accept a SUBSCRIBE or not. 

Generally, if a server receives a request, its because some chain of
processing decisions along the way decided that this server is indeed
ideally suited for doing that. The server can decide not to, and the purpose
of the To field is to provide information to allow it to make that decision
if it chooses. The same holds for INVITE. 

migration problems, 
server. If 
know the 
interested in 
to the TO 
proxy along 
change the 
server 
user (which 
presentity). 

This makes no sense whatsoever.

-Jonathan R.
---

-----Original Message----- 
From: Brazier Lachlan [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2001 1:51 AM 
To: 'Jonathan Rosenberg '; Brazier Lachlan; ''Neil Deason' '; ''SIMPLE 
Mailinglist' ' 

 Hello, 
-----Originalnachricht----- 
Von: Jonathan Rosenberg 

I still 

-Jonathan R. 
---

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 5 Oct 2001 10:01:55 -0500

Ok, I think this one got off on the wrong footing... Let me try again.

What I'm suggesting is that when a PA receives a SUBSCRIBE, even if it is
the entity listed in the requestURI (which would need to happen for SIP
routing), it should look at the TO header to make sure that the party listed
in the TO is one that the PA serves. No changes in requestURI processing, or
routing rules along the way. 

That's all. I think it's just a word-smithing item from section 5.3 that 
needs to be added. If the PA that the SUBSCRIBE gets routed to, doesn't 
serve the TO party, it's sends back a 404 (not a 603, I was mistaken there, 
that would imply that it was the correct PA).

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.

Regards,

Brian

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

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Thursday, October 04, 2001 7:23 PM
To: Brazier Lachlan; 'Jonathan Rosenberg '; ''Neil Deason' '; ''SIMPLE
Mailinglist' '

SUBSCRIBE 
consider 
paragraph 
if 

through 
way, so 

Wrong.

because 

migration problems, 
server. If 
know the 
interested in 
to the TO 
proxy along 
change the 
server 
user (which 
presentity). 

-Jonathan R.
---

-----Original Message----- 
From: Brazier Lachlan [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2001 1:51 AM 
To: 'Jonathan Rosenberg '; Brazier Lachlan; ''Neil Deason' '; ''SIMPLE 
Mailinglist' ' 

 Hello, 
-----Originalnachricht----- 
Von: Jonathan Rosenberg 

I still 

-Jonathan R. 
---

---

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

determining 
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.

---

---

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 

> 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'

determining 
returned 

-Jonathan R.

---