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

From: [email-masked]
Date: Wed, 10 Apr 2002 09:59:38 +0300

The first NOTIFY is sent of course, but there will be no NOTIFYs sent when a change to winfo occurs.

Regards,
Hisham

> -----Original Message-----
> From: Lonnfors Mikko (NRC/Helsinki) 
> Sent: Tuesday, April 09, 2002 10:37 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Simple] question about winfo-package (resend 
> with revision
> marks)
> 
> 
> 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
> > 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 15 Apr 2002 16:28:23 -0400

> when a change to winfo occurs.

Right. I'll clarify that.

Thanks,
Jonathan R.