Hi,

Sigrid Thijs wrote:

But now we noticed another problem. When the subscription handling is set to "polite-block", a NOTIFY should be sent containing a presence document that indicates that the presentity is unavailable. But the presence module sends a NOTIFY containing a presence description with the current presence state of the presentity. So there's no difference between setting the subscription handling to "allow" and "polite-block".

did you get any chance to take a look at this issue?

kind regards,

Sigrid

kind regards,

Sigrid

...

As a note, unless you are using more that one presence servers, the fallback to db mode is not really needed and inefficient.

Thanks and regards, Anca Vamanu

Sigrid Thijs wrote:

...

Hi,

we've configured OpenSER 1.3.0 on a FreeBSD server, together with OpenXCAP 0.9.9. When testing presence rules (RFC 5025) with our UA, we noticed the following behavior:

• Subscription Handling is set to "block" in the presence rules:

When a watcher subscribes for presence, it receives a NOTIFY with the Subscription-State set to "terminated;reason=rejected". This is as expected. When the presentity changes it's presence, the watcher doesn't receive any NOTIFY requests with the presence update (also OK). But, when the presentity changes the subscription handling to "allow" in the presence-rules document, the server sends an in-dialog NOTIFY request on the subscription dialog that was previously terminated. This is not ok. See the attached file presence_rules_01.txt.

• Subscription Handling is set to "allow" in the presence rules:

When the presentity changes the subscription handling to "block" in the presence-rules document, the server sends a NOTIFY with the Subscription-State set to "terminated;reason=timeout" to the watchers. When the presentity changes his presence, the presence server will still send NOTIFY requests to the watchers. See the attached file presence_rules_02.txt.

kind regards,

Sigrid

---

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

Hi,

we've installed version 1.3.2 and it works now.

Thanks,

Sigrid

Anca Vamanu wrote:

Hi,

I have fixed it now. Please update, test and reply if it works.

regards, Anca Vamanu

Sigrid Thijs wrote:

...

Hi,

Sigrid Thijs wrote:

...

But now we noticed another problem. When the subscription handling is set to "polite-block", a NOTIFY should be sent containing a presence document that indicates that the presentity is unavailable. But the presence module sends a NOTIFY containing a presence description with the current presence state of the presentity. So there's no difference between setting the subscription handling to "allow" and "polite-block".

did you get any chance to take a look at this issue?

kind regards,

Sigrid

...

kind regards,

Sigrid

...

As a note, unless you are using more that one presence servers, the fallback to db mode is not really needed and inefficient.

Thanks and regards, Anca Vamanu

Sigrid Thijs wrote:

...

Hi,

we've configured OpenSER 1.3.0 on a FreeBSD server, together with OpenXCAP 0.9.9. When testing presence rules (RFC 5025) with our UA, we noticed the following behavior:

• Subscription Handling is set to "block" in the presence rules:

When a watcher subscribes for presence, it receives a NOTIFY with the Subscription-State set to "terminated;reason=rejected". This is as expected. When the presentity changes it's presence, the watcher doesn't receive any NOTIFY requests with the presence update (also OK). But, when the presentity changes the subscription handling to "allow" in the presence-rules document, the server sends an in-dialog NOTIFY request on the subscription dialog that was previously terminated. This is not ok. See the attached file presence_rules_01.txt.

• Subscription Handling is set to "allow" in the presence rules:

When the presentity changes the subscription handling to "block" in the presence-rules document, the server sends a NOTIFY with the Subscription-State set to "terminated;reason=timeout" to the watchers. When the presentity changes his presence, the presence server will still send NOTIFY requests to the watchers. See the attached file presence_rules_02.txt.

kind regards,

Sigrid

---

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

Hi,

I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).

regards, Anca

Sigrid Thijs wrote:

Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).

kind regards,

Sigrid

Sigrid Thijs wrote:

...

Hi,

we've installed version 1.3.2 and it works now.

Thanks,

Sigrid

Anca Vamanu wrote:

...

Hi,

I have fixed it now. Please update, test and reply if it works.

regards, Anca Vamanu

Sigrid Thijs wrote:

...

Hi,

Sigrid Thijs wrote:

...

But now we noticed another problem. When the subscription handling is set to "polite-block", a NOTIFY should be sent containing a presence document that indicates that the presentity is unavailable. But the presence module sends a NOTIFY containing a presence description with the current presence state of the presentity. So there's no difference between setting the subscription handling to "allow" and "polite-block".

did you get any chance to take a look at this issue?

kind regards,

Sigrid

...

kind regards,

Sigrid

...

As a note, unless you are using more that one presence servers, the fallback to db mode is not really needed and inefficient.

Thanks and regards, Anca Vamanu

Sigrid Thijs wrote: > Hi, > > we've configured OpenSER 1.3.0 on a FreeBSD server, together > with OpenXCAP 0.9.9. > When testing presence rules (RFC 5025) with our UA, we noticed > the following behavior: > > - Subscription Handling is set to "block" in the presence rules: > When a watcher subscribes for presence, it receives a NOTIFY > with the Subscription-State set to "terminated;reason=rejected". > This is as expected. > When the presentity changes it's presence, the watcher doesn't > receive any NOTIFY requests with the presence update (also OK). > But, when the presentity changes the subscription handling to > "allow" in the presence-rules document, the server sends an > in-dialog NOTIFY request on the subscription dialog that was > previously terminated. This is not ok. See the attached file > presence_rules_01.txt. > > - Subscription Handling is set to "allow" in the presence rules: > When the presentity changes the subscription handling to "block" > in the presence-rules document, the server sends a NOTIFY with > the Subscription-State set to "terminated;reason=timeout" to the > watchers. > When the presentity changes his presence, the presence server > will still send NOTIFY requests to the watchers. > See the attached file presence_rules_02.txt. > > kind regards, > > Sigrid > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Users mailing list > Users@lists.openser.org > http://lists.openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

Sigrid Thijs wrote:

Anca Vamanu wrote:

...

Hi,

I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).

But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.

kind regards,

Sigrid

I did not understood correctly. You are right. There should be no Notify in this case. I will take a look.

Thanks, Anca

...

regards, Anca

Sigrid Thijs wrote:

...

Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).

kind regards,

Sigrid

Sigrid Thijs wrote:

...

Hi,

we've installed version 1.3.2 and it works now.

Thanks,

Sigrid

Anca Vamanu wrote:

...

Hi,

I have fixed it now. Please update, test and reply if it works.

regards, Anca Vamanu

Sigrid Thijs wrote:

...

Hi,

Sigrid Thijs wrote:

> But now we noticed another problem. When the subscription > handling is set to "polite-block", a NOTIFY should be sent > containing a presence document that indicates that the > presentity is unavailable. But the presence module sends a > NOTIFY containing a presence description with the current > presence state of the presentity. So there's no difference > between setting the subscription handling to "allow" and > "polite-block". > did you get any chance to take a look at this issue?

kind regards,

Sigrid

> kind regards, > > Sigrid > >> As a note, unless you are using more that one presence servers, >> the fallback to db mode is not really needed and inefficient. >> >> Thanks and regards, >> Anca Vamanu >> >> Sigrid Thijs wrote: >>> Hi, >>> >>> we've configured OpenSER 1.3.0 on a FreeBSD server, together >>> with OpenXCAP 0.9.9. >>> When testing presence rules (RFC 5025) with our UA, we noticed >>> the following behavior: >>> >>> - Subscription Handling is set to "block" in the presence rules: >>> When a watcher subscribes for presence, it receives a NOTIFY >>> with the Subscription-State set to >>> "terminated;reason=rejected". This is as expected. >>> When the presentity changes it's presence, the watcher doesn't >>> receive any NOTIFY requests with the presence update (also OK). >>> But, when the presentity changes the subscription handling to >>> "allow" in the presence-rules document, the server sends an >>> in-dialog NOTIFY request on the subscription dialog that was >>> previously terminated. This is not ok. See the attached file >>> presence_rules_01.txt. >>> >>> - Subscription Handling is set to "allow" in the presence rules: >>> When the presentity changes the subscription handling to >>> "block" in the presence-rules document, the server sends a >>> NOTIFY with the Subscription-State set to >>> "terminated;reason=timeout" to the watchers. >>> When the presentity changes his presence, the presence server >>> will still send NOTIFY requests to the watchers. >>> See the attached file presence_rules_02.txt. >>> >>> kind regards, >>> >>> Sigrid >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.openser.org >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users > _______________________________________________ > Users mailing list > Users@lists.openser.org > http://lists.openser.org/cgi-bin/mailman/listinfo/users >

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

Thanks, that fixed it.

kind regards,

Sigrid

Anca Vamanu wrote:

Hi,

I have just committed a fix. Could you please update to the svn version of presence module. Or take the patch from here http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/prese... http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/presence/notify.c?r1=4265&r2=4264&view=patch&pathrev=4265

and apply it manually and reply if it works.

regards, Anca Vamanu

Sigrid Thijs wrote:

...

Anca Vamanu wrote:

...

Hi,

I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).

But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.

kind regards,

Sigrid

...

regards, Anca

Sigrid Thijs wrote:

...

Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).

kind regards,

Sigrid

Sigrid Thijs wrote:

...

Hi,

we've installed version 1.3.2 and it works now.

Thanks,

Sigrid

Anca Vamanu wrote:

...

Hi,

I have fixed it now. Please update, test and reply if it works.

regards, Anca Vamanu

Sigrid Thijs wrote: > Hi, > > Sigrid Thijs wrote: > >> But now we noticed another problem. When the subscription >> handling is set to "polite-block", a NOTIFY should be sent >> containing a presence document that indicates that the >> presentity is unavailable. But the presence module sends a >> NOTIFY containing a presence description with the current >> presence state of the presentity. So there's no difference >> between setting the subscription handling to "allow" and >> "polite-block". >> > did you get any chance to take a look at this issue? > > kind regards, > > Sigrid > >> kind regards, >> >> Sigrid >> >>> As a note, unless you are using more that one presence servers, >>> the fallback to db mode is not really needed and inefficient. >>> >>> Thanks and regards, >>> Anca Vamanu >>> >>> Sigrid Thijs wrote: >>>> Hi, >>>> >>>> we've configured OpenSER 1.3.0 on a FreeBSD server, together >>>> with OpenXCAP 0.9.9. >>>> When testing presence rules (RFC 5025) with our UA, we noticed >>>> the following behavior: >>>> >>>> - Subscription Handling is set to "block" in the presence rules: >>>> When a watcher subscribes for presence, it receives a NOTIFY >>>> with the Subscription-State set to >>>> "terminated;reason=rejected". This is as expected. >>>> When the presentity changes it's presence, the watcher doesn't >>>> receive any NOTIFY requests with the presence update (also OK). >>>> But, when the presentity changes the subscription handling to >>>> "allow" in the presence-rules document, the server sends an >>>> in-dialog NOTIFY request on the subscription dialog that was >>>> previously terminated. This is not ok. See the attached file >>>> presence_rules_01.txt. >>>> >>>> - Subscription Handling is set to "allow" in the presence rules: >>>> When the presentity changes the subscription handling to >>>> "block" in the presence-rules document, the server sends a >>>> NOTIFY with the Subscription-State set to >>>> "terminated;reason=timeout" to the watchers. >>>> When the presentity changes his presence, the presence server >>>> will still send NOTIFY requests to the watchers. >>>> See the attached file presence_rules_02.txt. >>>> >>>> kind regards, >>>> >>>> Sigrid >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users@lists.openser.org >>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >> _______________________________________________ >> Users mailing list >> Users@lists.openser.org >> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

Hi Sigrid,

I tested myself and you were right. Please update again and test.

Thanks and regards, Anca

Sigrid Thijs wrote:

Unfortunately I jumped to conclusions to quickly. The NOTIFY requests are not sent anymore when the watcher is "polite-block"-ed, but now they are also not sent anymore to watchers that are allowed. An allowed watcher only receives the correct presence state of the presentity when he initiates the subscription.

kind regards,

Sigrid

Sigrid Thijs wrote:

...

Thanks, that fixed it.

kind regards,

Sigrid

Anca Vamanu wrote:

...

Hi,

I have just committed a fix. Could you please update to the svn version of presence module. Or take the patch from here http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/prese... http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/presence/notify.c?r1=4265&r2=4264&view=patch&pathrev=4265

and apply it manually and reply if it works.

regards, Anca Vamanu

Sigrid Thijs wrote:

...

Anca Vamanu wrote:

...

Hi,

I know it is useless but this is what the RFC says: a successful Subscribe must be followed by a Notify with the presence state(none in this case).

But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.

kind regards,

Sigrid

...

regards, Anca

Sigrid Thijs wrote:

...

Just a remark: one more thing we noticed is that when a presentity has 'polite-block'ed a watcher, the presence module sends a NOTIFY to the watcher each time the presentity changes his presence, although the content of the NOTIFY stays the same (no body).

kind regards,

Sigrid

Sigrid Thijs wrote: > Hi, > > we've installed version 1.3.2 and it works now. > > Thanks, > > Sigrid > > Anca Vamanu wrote: >> Hi, >> >> I have fixed it now. Please update, test and reply if it works. >> >> regards, >> Anca Vamanu >> >> >> Sigrid Thijs wrote: >>> Hi, >>> >>> Sigrid Thijs wrote: >>> >>>> But now we noticed another problem. When the subscription >>>> handling is set to "polite-block", a NOTIFY should be sent >>>> containing a presence document that indicates that the >>>> presentity is unavailable. But the presence module sends a >>>> NOTIFY containing a presence description with the current >>>> presence state of the presentity. So there's no difference >>>> between setting the subscription handling to "allow" and >>>> "polite-block". >>>> >>> did you get any chance to take a look at this issue? >>> >>> kind regards, >>> >>> Sigrid >>> >>>> kind regards, >>>> >>>> Sigrid >>>> >>>>> As a note, unless you are using more that one presence >>>>> servers, the fallback to db mode is not really needed and >>>>> inefficient. >>>>> >>>>> Thanks and regards, >>>>> Anca Vamanu >>>>> >>>>> Sigrid Thijs wrote: >>>>>> Hi, >>>>>> >>>>>> we've configured OpenSER 1.3.0 on a FreeBSD server, >>>>>> together with OpenXCAP 0.9.9. >>>>>> When testing presence rules (RFC 5025) with our UA, we >>>>>> noticed the following behavior: >>>>>> >>>>>> - Subscription Handling is set to "block" in the presence >>>>>> rules: >>>>>> When a watcher subscribes for presence, it receives a >>>>>> NOTIFY with the Subscription-State set to >>>>>> "terminated;reason=rejected". This is as expected. >>>>>> When the presentity changes it's presence, the watcher >>>>>> doesn't receive any NOTIFY requests with the presence >>>>>> update (also OK). >>>>>> But, when the presentity changes the subscription handling >>>>>> to "allow" in the presence-rules document, the server sends >>>>>> an in-dialog NOTIFY request on the subscription dialog that >>>>>> was previously terminated. This is not ok. See the attached >>>>>> file presence_rules_01.txt. >>>>>> >>>>>> - Subscription Handling is set to "allow" in the presence >>>>>> rules: >>>>>> When the presentity changes the subscription handling to >>>>>> "block" in the presence-rules document, the server sends a >>>>>> NOTIFY with the Subscription-State set to >>>>>> "terminated;reason=timeout" to the watchers. >>>>>> When the presentity changes his presence, the presence >>>>>> server will still send NOTIFY requests to the watchers. >>>>>> See the attached file presence_rules_02.txt. >>>>>> >>>>>> kind regards, >>>>>> >>>>>> Sigrid >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users@lists.openser.org >>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>> _______________________________________________ >>>> Users mailing list >>>> Users@lists.openser.org >>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>> > _______________________________________________ > Users mailing list > Users@lists.openser.org > http://lists.openser.org/cgi-bin/mailman/listinfo/users >

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

Hi,

Sigrid Thijs wrote:

But, when there's an active subscription, and the presentity changes the subscription handling from 'polite-block' to 'allow', the watcher only receives one NOTIFY, containing the current presence description of the presentity, but no further presence updates => not OK.

This also happens when the subscription-handling switches from 'allow' to 'confirm' back to 'allow'. But this is probably not a real world example.

Did you get a chance to look into these two issues?

kind regards,

Sigrid

Anca Vamanu wrote:

...

Hi Sigrid,

I tested myself and you were right. Please update again and test.

Thanks and regards, Anca

Sigrid Thijs wrote:

...

Unfortunately I jumped to conclusions to quickly. The NOTIFY requests are not sent anymore when the watcher is "polite-block"-ed, but now they are also not sent anymore to watchers that are allowed. An allowed watcher only receives the correct presence state of the presentity when he initiates the subscription.

kind regards,

Sigrid

Sigrid Thijs wrote:

...

Thanks, that fixed it.

kind regards,

Sigrid

Anca Vamanu wrote:

...

Hi,

I have just committed a fix. Could you please update to the svn version of presence module. Or take the patch from here http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/prese... http://openser.svn.sourceforge.net/viewvc/openser/branches/1.3/modules/presence/notify.c?r1=4265&r2=4264&view=patch&pathrev=4265

and apply it manually and reply if it works.

regards, Anca Vamanu

Sigrid Thijs wrote:

...

Anca Vamanu wrote: > Hi, > > > I know it is useless but this is what the RFC says: a successful > Subscribe must be followed by a Notify with the presence > state(none in this case). > But in this case, no SUBSCRIBE is sent by the watcher. The presentity changes his presence (which issues a PUBLISH), and the presence module sends notifications on all active watcher dialogs. Also those that are 'polite-block'-ed (who receive always a NOTIFY with the same content). I'm not saying it's wrong, it's just one thing we noticed.

kind regards,

Sigrid

> regards, > Anca > > > Sigrid Thijs wrote: >> Just a remark: one more thing we noticed is that when a >> presentity has 'polite-block'ed a watcher, the presence module >> sends a NOTIFY to the watcher each time the presentity changes >> his presence, although the content of the NOTIFY stays the same >> (no body). >> >> kind regards, >> >> Sigrid >> >> Sigrid Thijs wrote: >>> Hi, >>> >>> we've installed version 1.3.2 and it works now. >>> >>> Thanks, >>> >>> Sigrid >>> >>> Anca Vamanu wrote: >>>> Hi, >>>> >>>> I have fixed it now. Please update, test and reply if it works. >>>> >>>> regards, >>>> Anca Vamanu >>>> >>>> >>>> Sigrid Thijs wrote: >>>>> Hi, >>>>> >>>>> Sigrid Thijs wrote: >>>>> >>>>>> But now we noticed another problem. When the subscription >>>>>> handling is set to "polite-block", a NOTIFY should be sent >>>>>> containing a presence document that indicates that the >>>>>> presentity is unavailable. But the presence module sends a >>>>>> NOTIFY containing a presence description with the current >>>>>> presence state of the presentity. So there's no difference >>>>>> between setting the subscription handling to "allow" and >>>>>> "polite-block". >>>>>> >>>>> did you get any chance to take a look at this issue? >>>>> >>>>> kind regards, >>>>> >>>>> Sigrid >>>>> >>>>>> kind regards, >>>>>> >>>>>> Sigrid >>>>>> >>>>>>> As a note, unless you are using more that one presence >>>>>>> servers, the fallback to db mode is not really needed and >>>>>>> inefficient. >>>>>>> >>>>>>> Thanks and regards, >>>>>>> Anca Vamanu >>>>>>> >>>>>>> Sigrid Thijs wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> we've configured OpenSER 1.3.0 on a FreeBSD server, >>>>>>>> together with OpenXCAP 0.9.9. >>>>>>>> When testing presence rules (RFC 5025) with our UA, we >>>>>>>> noticed the following behavior: >>>>>>>> >>>>>>>> - Subscription Handling is set to "block" in the presence >>>>>>>> rules: >>>>>>>> When a watcher subscribes for presence, it receives a >>>>>>>> NOTIFY with the Subscription-State set to >>>>>>>> "terminated;reason=rejected". This is as expected. >>>>>>>> When the presentity changes it's presence, the watcher >>>>>>>> doesn't receive any NOTIFY requests with the presence >>>>>>>> update (also OK). >>>>>>>> But, when the presentity changes the subscription handling >>>>>>>> to "allow" in the presence-rules document, the server sends >>>>>>>> an in-dialog NOTIFY request on the subscription dialog that >>>>>>>> was previously terminated. This is not ok. See the attached >>>>>>>> file presence_rules_01.txt. >>>>>>>> >>>>>>>> - Subscription Handling is set to "allow" in the presence >>>>>>>> rules: >>>>>>>> When the presentity changes the subscription handling to >>>>>>>> "block" in the presence-rules document, the server sends a >>>>>>>> NOTIFY with the Subscription-State set to >>>>>>>> "terminated;reason=timeout" to the watchers. >>>>>>>> When the presentity changes his presence, the presence >>>>>>>> server will still send NOTIFY requests to the watchers. >>>>>>>> See the attached file presence_rules_02.txt. >>>>>>>> >>>>>>>> kind regards, >>>>>>>> >>>>>>>> Sigrid >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users@lists.openser.org >>>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users@lists.openser.org >>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>>>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.openser.org >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users