Subject: RE: [Simple] Multiple 200 Ok

From: "Neil Deason" <[email-masked]>
Date: Wed, 24 Oct 2001 11:54:15 +0100

I would agree with this. The usage of a 403 needs to
be clear that it doesn't mean the SUBSCRIBE should
never be repeated as that may not be obvious from
the HTTP inherited meaning.

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

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 24 October 2001 01:45
> To: Brian Stucker; 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.
>
>
>
> ---
> 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: Brian Stucker [mailto:[email-masked]]
> Sent: Friday, October 05, 2001 11:10 AM
> To: Neil Deason; Brazier Lachlan; 'Jonathan Rosenberg'; ''SIMPLE
> Mailinglist' '
> Subject: RE: [Simple] Multiple 200 Ok
>
>
> 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
>
>
> > -----Original Message-----
> > 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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Oct 2001 20:45:28 -0400

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

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 

> Let me reformulate the question. Which response do I send back, when I 
403 would do. 
> If there is another mechanism to do so, which one would it be? Maybe a