Subject: [Simple] question about winfo-package

From: [email-masked]
Date: Tue, 26 Mar 2002 15:56:16 +0200

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

---

From: "Li Hua Tang" <[email-masked]>
Date: Wed, 27 Mar 2002 09:29:02 +0800

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.

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?

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.

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.

  <watcherinfo>

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

  <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

---

From: [email-masked]
Date: Wed, 27 Mar 2002 09:34:39 +0200

Hi,

Some comments inline

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

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.

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

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?

I will probably not be able attend this one.

regards
- Mikko

Best regards,

Tang Lihua

                    [email-masked]                                                              

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

Hi,

  <watcherinfo>

  <watcherinfo>

regards
- Mikko