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

From: [email-masked]
Date: Wed, 27 Mar 2002 13:19:15 +0200

Sorry for resending this. Original main didn't have any revision marks.

Some comments inline inside <ML></ML>.

-----Original Message-----
From: ext Li Hua Tang [mailto:[email-masked]]
Sent: 27 March, 2002 03:29
To: Lonnfors Mikko (NRC/Helsinki)
Cc: [email-masked]; [email-masked]
Subject: Re: [Simple] question about winfo-package

Mikko,

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>

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". Otherwise, continuing this we could send

    <resource uri="sip:[email-masked]" package="presence">
       <watcher uri="sip:[email-masked]" status="active"
                   event="subscribe" expiration="200"/>

Now, should A be able to understand that B's subscription expires in 200 and after that time automatically do something
(for example delete B's entry from GUI)? But now if B refreshes his subscription A needs to get new winfo NOTIFY with new 
expiration timer despite that there has been no change in B's subscription status. 

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.

Any comments?
</ML>

Will you attend the coming 10th SIPIT? I think We can discuss about this
question and more about SIMPLE face-to-face at that time.

<ML>
I will probably not be able attend this one.

regards
- Mikko
</ML>

Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.
Phone: (8610)62986677-542 Tie line: 905-542
Email:  [email-masked]

                    [email-masked]                                                              
                    Sent by:                         To:     <[email-masked]>             
                    [email-masked]       cc:                                                  
                    icsoft.com                       Subject:     [Simple] question about winfo-package   

                    2002-03-26 21:56                                                                      
                    Please respond to                                                                     
                    mikko.lonnfors                                                                        

Hi,

One question about winfo-package. Lets say that winfo is applied to
presence event-package
and that user A has subscribed his winfo. Now user B performs FETCH
(SUBSCRIBE with expires: 0)
on user A's presence information.

User B is authorized to subscribe A's presence:

First server send winfo NOTIFY to user A

  <watcherinfo>
     <resource uri="sip:[email-masked]" package="presence">
       <watcher uri="sip:[email-masked]" status="active"
                   event="subscribe"/>
     </resource>
   </watcherinfo>

then PS sends presence document to user B and immediately after that an
other NOTIFY to user A with

  <watcherinfo>
     <resource uri="sip:[email-masked]" package="presence">
       <watcher uri="sip:[email-masked]" status="terminated"
                   event="timeout"/>
     </resource>
   </watcherinfo>

Should user A receive these two NOTIFY message or can FETCH request be
considered expired when it arrives
so that only the second winfo NOTIFY would be needed?

regards
- Mikko
_______________________________________________
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, 01 Apr 2002 01:12:31 -0500

[email-masked] wrote:
> 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

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.

> signal changes in watchers subscription status i.e. signal the state to
> which a watcher has moved from previous state.
> 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.

>        <watcher uri="sip:[email-masked]" status="waiting"

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