Subject: AW: [Simple] Multiple 200 Ok

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

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)?

----------------------------------

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?

Greetings
Lachlan

---------------------

> -----Ursprüngliche Nachricht-----
> Von: Neil Deason [mailto:[email-masked]]
> Gesendet am: Freitag, 05. Oktober 2001 11:44
> An: Brazier Lachlan; 'Jonathan Rosenberg'; 'Brian Stucker'; ''SIMPLE
> Mailinglist' '
> Betreff: RE: [Simple] Multiple 200 Ok
> 
> > -----Original Message-----
> > From: Brazier Lachlan [mailto:[email-masked]]
> >
> > 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?
> 
> 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> 
>

---

From: "Neil Deason" <[email-masked]>
Date: Fri, 5 Oct 2001 15:51:51 +0100

> presence draft, errors might happen)?

403 would do.

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