Subject: AW: [Simple] Multiple 200 Ok

From: Brazier Lachlan <[email-masked]>
Date: Fri, 5 Oct 2001 10:27:18 +0200

Hello,

I believe the To header does show who a request was meant for. So, if a PA
receives a request which it could handle, but which it is not authorized to
handle, because it isn't the PA of the user in the To header, which response
would it send back? I would think about either 403 Forbidden, 404 Not Found
or 480 Temporarily Unavailable.

Could the correct awnser be stated in the presence draft?

Lachlan

> 
> >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.
> 
> 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 
> >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. 
> 
> Wrong.
> 
> >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. 
> 
> 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. 
> 
> >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). 
> 
> This makes no sense whatsoever.
> 
> -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
> 
> 
> -----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' ' 
> Subject: AW: [Simple] Multiple 200 Ok 
> 
> 
>  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 
> 
> 
> 
>  
> > -----Original Message----- 
> > 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, 
> > thank you for your clarification. There is still this one 
> point open: 
> > 
> > > > > 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)? 
> > 
> > 
> > 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. 
> 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 
> > request was handled 
> > by a different user. 
> The entity that finally responds to the SUBSCRIBE will place, in the 
> 2xx, a 
> Contact header that contains their URL. 
> 
> 
> > 
> > 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? 
> No; as it stands, the To/From are flipped in the NOTIFY from the 
> presentity. 
> 
> 
> -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: "Neil Deason" <[email-masked]>
Date: Fri, 5 Oct 2001 10:43:53 +0100

> Could the correct awnser be stated in the presence draft?

Your implementation could respond in this fashion without
adding any complication to the spec. But you should
think about why the PUA is receiving the SUBSCRIBE in the
1st place. If say REGISTER is being used to set up routing
logic for presence subscriptions this means that a third
party must have sent a REGISTER request naming the target
of the subscription in the To header and themselves as a
Contact with a "methods" parameter containing SUBSCRIBE.
In any sensible system this would have to be authenticated
and authorised to prevent identity hijacking for presence,
voice sessions etc. If as the subscriber you want to be 
sure that the responder for presence is the party you were
expecting, and not an authenticated party they have authorised
to act on their behalf, you can look at the Contact headers of 
the NOTIFY request(s) that come in. Of course there has to be
an element of trust here. If you are not satisfied use
the beauty of a converged application to INVITE them to
conference with a voice recognition system ;)

Cheers,
Neil.
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net

<snip>