Subject: RE: [Simple] question about winfo-package (resend with revision marks)

From: [email-masked]
Date: Tue, 9 Apr 2002 10:36:59 +0300

Hi,

Thanks for the answer. I have one more question about draft-ietf-simple-winfo-package-01.
Chapter 4.7.1 The Subscription State Machine (after figure 1) says:

"If, when a subscription arrives, there is no authorization policy in
existence, the subscription moves into the pending state. In this
state, the server is awaiting an authorization decision. No
notifications are generated, but the subscription FSM is maintained."

Is this to say that the package on which winfo is applied to should not generate
any NOTIFY messages to subscriber? This sound a bit weird because SIP events says that NOTIFY
should be send immediately after 200-class response. (I am here assuming SUB-202 request/response
if there is no authorization policy is set)

So in short how should the quoted sentence be interpreted?

regards
- Mikko

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 01 April, 2002 09:13
> To: Lonnfors Mikko (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] question about winfo-package (resend 
> with revision
> marks)
> 
> 
> 
> 
> [email-masked] wrote:
> > 
> > My opinion about your question is as follows:
> > 
> > The motivating application for winfo package is presence 
> authorization.
> > If
> > User B is authorized to subscribe A's presence, as you 
> said, generally
> > speaking the PS doesn't need to notify A of the B's 
> subscription status
> > for
> > authorization.
> > 
> > <ML>
> > I would still say that winfo is designed to enable presentity to get
> > lists of watchers interested in their presence status.
> > This should happen regardless of the watcher's authorization status.
> > Presence authorization may be the main motivation
> > to enable this functionality but not the only one.
> > </ML>
> 
> Yes. However, the decision about when to send NOTIFY for winfo is a
> server decision; it can decide to not send two notifications 
> in the case
> of a fetch.
> 
> 
> > 
> > If the PS needs to notify A of this FETCH subscription, you 
> may use the
> > 'expiration' attribute of winfo foramt. Like this:
> >   <watcherinfo>
> >      <resource uri="sip:[email-masked]" package="presence">
> >        <watcher uri="sip:[email-masked]" status="active"
> >                    event="subscribe" expiration="0"/>
> >      </resource>
> >    </watcherinfo>
> > In this case, A should understanding that a FETCH subscription is
> > requested.
> > How about this way to solute your problem?
> > 
> > <ML>
> > I think there are some problems with this approach. I think 
> that winfo
> > is designed to
> > signal changes in watchers subscription status i.e. signal 
> the state to
> > which a watcher has moved from previous state.
> > In this case, as you said,  A should be able to understand that
> > 
> >     <resource uri="sip:[email-masked]" package="presence">
> >        <watcher uri="sip:[email-masked]" status="active"
> >                    event="subscribe" expiration="0"/>
> > 
> > means FETCH. This would mean special casing expiration="0".
> 
> It only needs to be special cased if you are trying to explicitly
> identify fetch requests. I see no reason to do that. The above
> notification stands, by itself, as something reasonable. 
> However, if you
> want to send a single notification, you are probably better 
> off sending
> the one on the transition to terminated due to timeout.
> 
> 
> 
> > We could take an other example. Let's say that B performs 
> FETCH but has
> > no authorization. Should A now get
> > 
> >    <resource uri="sip:[email-masked]" package="presence">
> >        <watcher uri="sip:[email-masked]" status="pending"
> >                    event="subscribe" expiration="0"/>
> > 
> > I would say that sending
> > 
> >    <resource uri="sip:[email-masked]" package="presence">
> >        <watcher uri="sip:[email-masked]" status="waiting"
> >                    event="subscribe"/>
> > 
> > would make more sense.
> 
> I agree that the second one makes more sense. The first is valid, of
> course, but if you want to send just one notification, the latter is
> more useful. Again, the decision about which state change 
> notifications
> to send is a matter of local policy.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
>