Subject: [Simple] Clarification/Comments on simple-event-filter-funct-00

From: "George Foti (QC/EMC)" <[email-masked]>
Date: Mon, 16 Feb 2004 18:20:18 -0600

Hi,

I have some clarification on the subject draft:

Section 3.3.1 

Can you explicitly state that there can only be one filter applicable to a single resource within a single SUBSCRIBE.

I know that the intent is there but I prefer an explicit statement to that effect.

 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Section 3.3.2

I assume that the individual resource filter override the domain filter for resources within the domain and for which individual filters are defined.

If you agree, can you explicitly add text to that effect in that section.

Section 3.3.3

I take it that this is a complete filter replacement of the old one with the new one. 

Section 4.1  (first comment)

It seems to me that what you are describing there with respect to the handling of lists & the RLS behavior for propagating the filters further down, belongs to the section 5.2.1 where the server aspects are discussed.

Or at least the later section should refer to section 4.1.

Section  4.1  (Second comment)

You seem to advocate that if the URI indicated by the filter does not match any of the URIs returned from the look up, then that filter should be propagated.

I disagree with that logic.

It seems to me that the list may have changed and that URI existed but was removed later, and as such propagating the filter is not the right thing to do.

Thus I would like an error to be returned to the user in such a case, which indeed reflects what the server is discovering.

Section 5.3.1

There is a statement stating that if the notifier did not examine closely the filter before accepting, it the resulting XML document may not conform to the schema.

What does examine closely mean ?. Can u elaborate on that.?

If the filter in the SUBSCRIBE is aligned with the XML schema, can that situation arises. 

Rgds/gf

Ericsson Canada  <mailto:[email-masked]'> 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: [email-masked]
Date: Wed, 18 Feb 2004 14:07:07 +0200

George,
 
Thanks for the comments. Responses inline...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext George Foti (QC/EMC)
Sent: 17.February.2004 02:20
To: [email-masked]'
Subject: [Simple] Clarification/Comments on simple-event-filter-funct-00

Hi,

Section 3.3.1 

Ok. 

Section 3.3.2

I agree. 

Section 3.3.3

No. The only way to replace a filter is to explicitly remove it and add a new one.

Section 5 describes the notifier behaviour. I chose to put the RLS behaviour in a separate section to distinguish it from notifier. 

Consider this:

List1 ( [email-masked]) on RLS1 has:

     [email-masked]

     [email-masked]

List2 on RLS2 has:

     [email-masked]

I send a SUBSCRIBE to [email-masked] with a filter for [email-masked]. RLS1 does not have alice in the list, nor does it know that she is in list2 (RLS1 doesn't even know that [email-masked] is a list). In this case, it feels that the right thing to do is to propagate the filter.

In your example, it might be an implementation issue that the RLS keeps history of list members, but I doubt that is feasible. The filter might very well just be ignored by all RLSs.

Section 5.3.1

I will remove that sentence completely since it causes ambiguity. The notifier will most likely not know before creating the NOTIFY content that the content will not be valid, unless it has some complicated logic for accepting the subscription.

Thanks,

Hisham

Rgds/gf

---

From: [email-masked]
Date: Wed, 18 Feb 2004 14:07:07 +0200

George,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext George Foti (QC/EMC)
Sent: 17.February.2004 02:20
To: [email-masked]'
Subject: [Simple] Clarification/Comments on simple-event-filter-funct-00

Hi,

Section 3.3.1 

Ok. 

Section 3.3.2

I agree. 

Section 3.3.3

Consider this:

     [email-masked]

     [email-masked]

List2 on RLS2 has:

     [email-masked]

Section 5.3.1

Thanks,

Hisham

Rgds/gf

---

From: [email-masked]
Date: Thu, 19 Feb 2004 13:29:00 +0200

Consider this:

     [email-masked]

     [email-masked]

List2 on RLS2 has:

     [email-masked]

In your example it is okay to propagate the filter that since the URI belongs to a different domain. 

Hence you really have 2 cases for the mismatch :

1) The case where the URI is local to your domain, in which case you can ignore the filter 

2)The case where the URI belongs to another domain, in which case you progagate the filter 

If you agree than can we add text to clarify  along those lines.

I was thinking the same thing. I'll addd some text.

Thanks again,

Hisham

---

From: [email-masked]
Date: Thu, 19 Feb 2004 13:29:00 +0200

Consider this:

     [email-masked]

     [email-masked]

List2 on RLS2 has:

     [email-masked]

Thanks again,

Hisham

---

From: [email-masked]
Date: Tue, 24 Feb 2004 10:13:01 +0200

Well, strictly speaking, removing a filter involves the filter ID only. I'll add some text in the format draft indicating that when the "remove" attribute is used in a filter, everything else in that filter is ignored and must not appear.
 
Thanks,
Hisham

-----Original Message-----
From: ext George Foti (QA/EMC) [mailto:[email-masked]]
Sent: 23.February.2004 19:41
To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked]
Subject: RE: [Simple] Clarification/Comments on simple-event-filter-funct-00

Hisham, one more comment related to removing filters and replacing then with new filters

>No. The only way to replace a filter is to explicitly remove it and add a new one

Based on the above,  I assume that one should be able to remove a filter and add a new one for the same R-URI within the same SUBSCRIBE.

If thats OK, then this would be the *only* case where more then one filter for a R-URI can appear in the same filter.

Thanks/gf

---

From: [email-masked]
Date: Tue, 24 Feb 2004 10:13:01 +0200

Thanks,
Hisham

-----Original Message-----
From: ext George Foti (QA/EMC) [mailto:[email-masked]]
Sent: 23.February.2004 19:41
To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked]
Subject: RE: [Simple] Clarification/Comments on simple-event-filter-funct-00

Thanks/gf