Subject: [Simple] RFC 4661: different notification filters for a same resource?

From: Victoria Beltrán Martínez <[email-masked]>
Date: Tue, 18 Nov 2008 16:03:37 +0100

Hello,

Regarding event notification filtering, I am not sure if I could set 
different triggers to different pieces of presence information 
associated to a same presentity. I think that I need to create two 
different filters with different IDs and the same resource uri (the 
presentity's uri). Following the filter criteria Schema in RFC 4660, 
Could I create a document with two different filters associated to a 
same resource?

RFC 4660 does not states that the value of the "uri" attribute of 
<filter> elements must be unique, but I got confused when I read in RFC 
4661 (section 3.3.3): “Replacing a filter by changing the filter ID and 
keeping the resource URI is considered an error since this causes the 
server to assume that two filters are placed for the same resource”. 
 From this sentence, I conclude that it is not possible to have more 
than one filter per resource… But I find this restriction unnecessary.

Any suggestion is welcome!

Victoria

_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: "Smyth, Colm (Colm)" <[email-masked]>
Date: Tue, 18 Nov 2008 17:26:03 -0000

Hi Victoria, all,

Minor nit: your reference to Section 3.3.3 should be to RFC 4660 rather than 4661.

I agree with you that this is unclear (in part because any protocol description is improved if it enumerates its identifiers, defines their formats and clearly states their uniqueness constraints in combination with any other identifiers).

4660 makes no statements about the possible values and uniqueness of the id attribute, but it is implicitly contrained by http://www.w3.org/TR/xml-id/ .

Since a resource may not be referred to in multiple filters, either directly or via a list URI, the id attribute appears to have no purpose except to prevent a filter being changed or deleted for the same resource by entities that are not aware of each other. Per RFC 4660#3.1, this could happen if the filter XML is "uploaded to the server using means outside the scope of this document.".

Editorial fix to 4660: there are several occurrences of the phrase "list specific list-specific" and "resource specific resource-specific"; while it's undesirable to mix American and International English use of the "possessive hyphen" in a single document, it's simply incorrect to use both in the same place.

All the best,
Colm Smyth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victoria Beltrán Martínez
Sent: 18 November 2008 15:04
To: [email-masked]
Subject: [Simple] RFC 4661: different notification filters for a sameresource?

Hello,

Regarding event notification filtering, I am not sure if I could set different triggers to different pieces of presence information associated to a same presentity. I think that I need to create two different filters with different IDs and the same resource uri (the presentity's uri). Following the filter criteria Schema in RFC 4660, Could I create a document with two different filters associated to a same resource?

RFC 4660 does not states that the value of the "uri" attribute of <filter> elements must be unique, but I got confused when I read in RFC
4661 (section 3.3.3): "Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the server to assume that two filters are placed for the same resource". 
 From this sentence, I conclude that it is not possible to have more than one filter per resource... But I find this restriction unnecessary.

Victoria

---

From: Victoria Beltrán Martínez <[email-masked]>
Date: Tue, 18 Nov 2008 20:39:09 +0100

Hi,

I know that the “id” attribute must be unique, but I have doubts about 
the “uri” attribute that identifies the resource to which the filter 
applies. RFC 4661 states clearly that the value of the "id" attribute 
must be unique within the <filter-set> element, but any statement is 
done for the "uri" attribute. The reason for making id attribute unique 
is that it is certainly used to handle remove and change operations. 
Section 3.4 of this RFC says: “The <filter> MAY have a 'remove' 
attribute that together with the 'id' attribute indicates the existing 
filter to be removed”, and “Filter contents can be changed by changing 
the contents in the <what> and <trigger> elements and maintaining the 
value of the filter 'id' attribute”

It seems that the uniqueness of the id attribute is sufficient to 
guarantee the success of remove and change operations, even though the 
operations are done by different entities which are not aware of each 
other. Then, I think that there is no sense in the statement of 4660: 
"Replacing a filter by changing the filter ID and keeping the resource 
URI is considered an error since this causes the server to assume that 
two filters are placed for the same resource".

What is more, in my opinion the possibility of defining several filters 
per resource is absolutely necessary to allow subscribers to express 
advanced preferences about the content of event notifications. For 
example, let us suppose a watcher that is interested on getting to know 
the SMS service of a presentity whenever this presentity changes its 
activity to “metting”. However, when the presentity changes its activity 
to “travel”, the watcher is interested on the IM service. How could this 
watcher set these preferences into his or her RLS?

Thank you in advance,
Victoria

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 19 Nov 2008 11:22:51 +1100

Hi,

Comments inline...

2008/11/19 Victoria Beltrán Martínez <[email-masked]>

> different triggers to different pieces of presence information associated to
> a same presentity. I think that I need to create two different filters with
> different IDs and the same resource uri (the presentity's uri). Following
> the filter criteria Schema in RFC 4660, Could I create a document with two
> different filters associated to a same resource?

Section 3.3.1 of RFC4660 clearly indicates that multiple filters for the
same resource is possible.

>
>
> RFC 4660 does not states that the value of the "uri" attribute of <filter>
> elements must be unique, but I got confused when I read in RFC 4661 (section
> 3.3.3): "Replacing a filter by changing the filter ID and keeping the
> resource URI is considered an error since this causes the server to assume
> that two filters are placed for the same resource". From this sentence, I
> conclude that it is not possible to have more than one filter per resource…
> But I find this restriction unnecessary.

You are misinterpreting the text. It is not an error that the server can
detects. It is an error in the client behaviour. If the client intended to
replace a filter and did so by changing the filter ID, then the server will
assume that you have created a new filter for that resource (which is legal,
but is not the intention of the client). If you want to remove a filter, you
need to explicitly do so by using the 'remove="true"' attribute.

Hope this helps.

Regards,
Hisham

---

From: "Smyth, Colm (Colm)" <[email-masked]>
Date: Wed, 19 Nov 2008 11:46:49 -0000

Ok, so in summary, you are happy to use ids, but you want to use a single operation to replace a filter with one for a different resource, rather than simply deleting the event and then creating a new one that reuses the same id. According to the current spec, your only option is to remove the original event and create a new one for the same resource with a different id.

In a separate thread, Hisham Khartabil suggests that RFC 4660#3.3.1 permits multiple filters for the same resource. I don't see how when it makes no reference to the same resource but does clearly refer to "different URIs":
   A SUBSCRIBE request destined to a list URI [4] MAY include multiple
   filters specific to individual resources.  This is achieved by
   including multiple <filter> elements with different URIs of resources
   in each of those elements.

To support your activity=travel/meeting and channel=SMS/IM scenario below, I agree that the RFC could be extended to allow multiple filters for a single resource (as you propose), but this introduces ambiguity.

The problem is that there appears to be no way to associate a "what" with a specific "trigger"; you can have multiple triggers, but they all result in sending the what. I suggest the most natural way to resolve this would be to extend the filter element to have zero or more "rule" elements, each of which may contain a trigger and a what element.

All the best,
Colm Smyth

-----Original Message-----
From: Victoria Beltrán Martínez [mailto:[email-masked]] 
Sent: 18 November 2008 19:39
To: Smyth, Colm (Colm); [email-masked]
Subject: Re: [Simple] RFC 4661: different notification filters for a sameresource?

Hi,

I know that the "id" attribute must be unique, but I have doubts about the "uri" attribute that identifies the resource to which the filter applies. RFC 4661 states clearly that the value of the "id" attribute must be unique within the <filter-set> element, but any statement is done for the "uri" attribute. The reason for making id attribute unique is that it is certainly used to handle remove and change operations. 
Section 3.4 of this RFC says: "The <filter> MAY have a 'remove' 
attribute that together with the 'id' attribute indicates the existing filter to be removed", and "Filter contents can be changed by changing the contents in the <what> and <trigger> elements and maintaining the value of the filter 'id' attribute"

It seems that the uniqueness of the id attribute is sufficient to guarantee the success of remove and change operations, even though the operations are done by different entities which are not aware of each other. Then, I think that there is no sense in the statement of 4660: 
"Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the server to assume that two filters are placed for the same resource".

What is more, in my opinion the possibility of defining several filters per resource is absolutely necessary to allow subscribers to express advanced preferences about the content of event notifications. For example, let us suppose a watcher that is interested on getting to know the SMS service of a presentity whenever this presentity changes its activity to "metting". However, when the presentity changes its activity to "travel", the watcher is interested on the IM service. How could this watcher set these preferences into his or her RLS?

Thank you in advance,
Victoria

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 20 Nov 2008 01:10:53 +1100

2008/11/19 Smyth, Colm (Colm) <[email-masked]>

> Ok, so in summary, you are happy to use ids, but you want to use a single
> operation to replace a filter with one for a different resource, rather than
> simply deleting the event and then creating a new one that reuses the same
> id. According to the current spec, your only option is to remove the
> original event and create a new one for the same resource with a different
> id.
>
>
> In a separate thread, Hisham Khartabil suggests that RFC 4660#3.3.1 permits
> multiple filters for the same resource. I don't see how when it makes no
> reference to the same resource but does clearly refer to "different URIs":

The 1st paragraph in that section refers to a single resource

"Multiple filters MAY be included in one SUBSCRIBE.  This is achieved
   by including multiple <filter> elements in the filter [5].  Each
   <filter> element may include a 'uri' attribute."

The whole document talks about a single resource unless it explicitly talks
about a SUBSCRIBE to a URI List.

>
>
>
> To support your activity=travel/meeting and channel=SMS/IM scenario below,
> I agree that the RFC could be extended to allow multiple filters for a
> single resource (as you propose), but this introduces ambiguity.

This is already allowed.

Hisham

>
>
> The problem is that there appears to be no way to associate a "what" with a
> specific "trigger"; you can have multiple triggers, but they all result in
> sending the what. I suggest the most natural way to resolve this would be to
> extend the filter element to have zero or more "rule" elements, each of
> which may contain a trigger and a what element.
>
> All the best,
> Colm Smyth
>
> I know that the "id" attribute must be unique, but I have doubts about the
> "uri" attribute that identifies the resource to which the filter applies.
> RFC 4661 states clearly that the value of the "id" attribute must be unique
> within the <filter-set> element, but any statement is done for the "uri"
> attribute. The reason for making id attribute unique is that it is certainly
> used to handle remove and change operations.
> filter to be removed", and "Filter contents can be changed by changing the
> contents in the <what> and <trigger> elements and maintaining the value of
> the filter 'id' attribute"
>
> It seems that the uniqueness of the id attribute is sufficient to guarantee
> the success of remove and change operations, even though the operations are
> done by different entities which are not aware of each other. Then, I think
> that there is no sense in the statement of 4660:
> "Replacing a filter by changing the filter ID and keeping the resource URI
> is considered an error since this causes the server to assume that two
> filters are placed for the same resource".
>
> What is more, in my opinion the possibility of defining several filters per
> resource is absolutely necessary to allow subscribers to express advanced
> preferences about the content of event notifications. For example, let us
> suppose a watcher that is interested on getting to know the SMS service of a
> presentity whenever this presentity changes its activity to "metting".
> However, when the presentity changes its activity to "travel", the watcher
> is interested on the IM service. How could this watcher set these
> preferences into his or her RLS?
>
>
> Thank you in advance,
> Victoria
>
>
>
>
> > I agree with you that this is unclear (in part because any protocol
> description is improved if it enumerates its identifiers, defines their
> formats and clearly states their uniqueness constraints in combination with
> any other identifiers).
> >
> > 4660 makes no statements about the possible values and uniqueness of the
> id attribute, but it is implicitly contrained by
> http://www.w3.org/TR/xml-id/ .
> >
> > Since a resource may not be referred to in multiple filters, either
> directly or via a list URI, the id attribute appears to have no purpose
> except to prevent a filter being changed or deleted for the same resource by
> entities that are not aware of each other. Per RFC 4660#3.1, this could
> happen if the filter XML is "uploaded to the server using means outside the
> scope of this document.".
> >
> > Editorial fix to 4660: there are several occurrences of the phrase "list
> specific list-specific" and "resource specific resource-specific"; while
> it's undesirable to mix American and International English use of the
> "possessive hyphen" in a single document, it's simply incorrect to use both
> in the same place.
> >
> > All the best,
> > Colm Smyth
> >
> > 4661 (section 3.3.3): "Replacing a filter by changing the filter ID and
> keeping the resource URI is considered an error since this causes the server
> to assume that two filters are placed for the same resource".
> >  From this sentence, I conclude that it is not possible to have more than
> one filter per resource... But I find this restriction unnecessary.
> >

---

From: Victoria Beltrán Martínez <[email-masked]>
Date: Wed, 19 Nov 2008 16:10:04 +0100

Hi all,

I think that it's not clear that the 1st paragraph in section 4660#3.3.1 
refers to a single resource (simply it does not make any assumption 
about it). But, the penultimate paragraph states:

"Regardless of whether the SUBSCRIBE is destined to a list URI, there 
can only be one filter applicable to a single resource or domain within 
a single SUBSCRIBE. That is, each filter within a subscription MUST 
uniquely identify one resource or one domain"

I interpret this text as a one-to-one relation between filters and 
resources, so that a subscription can't maintain more than one filter 
per resource.

regards,
Victoria

En/na Hisham Khartabil ha escrit:
>
>
> 2008/11/19 Smyth, Colm (Colm) <[email-masked] <mailto:[email-masked]>>
>
>     Ok, so in summary, you are happy to use ids, but you want to use a
>     single operation to replace a filter with one for a different
>     resource, rather than simply deleting the event and then creating
>     a new one that reuses the same id. According to the current spec,
>     your only option is to remove the original event and create a new
>     one for the same resource with a different id.
>
>
>     In a separate thread, Hisham Khartabil suggests that RFC
>     4660#3.3.1 permits multiple filters for the same resource. I don't
>     see how when it makes no reference to the same resource but does
>     clearly refer to "different URIs":
> The whole document talks about a single resource unless it explicitly 
> talks about a SUBSCRIBE to a URI List.
>  
>
>
>
>
>     To support your activity=travel/meeting and channel=SMS/IM
>     scenario below, I agree that the RFC could be extended to allow
>     multiple filters for a single resource (as you propose), but this
>     introduces ambiguity.
>
>
> This is already allowed.
>
> Hisham
>  
>
>
>
>     The problem is that there appears to be no way to associate a
>     "what" with a specific "trigger"; you can have multiple triggers,
>     but they all result in sending the what. I suggest the most
>     natural way to resolve this would be to extend the filter element
>     to have zero or more "rule" elements, each of which may contain a
>     trigger and a what element.
>
>     All the best,
>     Colm Smyth
>
>     From: Victoria Beltrán Martínez [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     To: Smyth, Colm (Colm); [email-masked] <mailto:[email-masked]>
>     I know that the "id" attribute must be unique, but I have doubts
>     about the "uri" attribute that identifies the resource to which
>     the filter applies. RFC 4661 states clearly that the value of the
>     "id" attribute must be unique within the <filter-set> element, but
>     any statement is done for the "uri" attribute. The reason for
>     making id attribute unique is that it is certainly used to handle
>     remove and change operations.
>     attribute that together with the 'id' attribute indicates the
>     existing filter to be removed", and "Filter contents can be
>     changed by changing the contents in the <what> and <trigger>
>     elements and maintaining the value of the filter 'id' attribute"
>
>     guarantee the success of remove and change operations, even though
>     the operations are done by different entities which are not aware
>     of each other. Then, I think that there is no sense in the
>     statement of 4660:
>     "Replacing a filter by changing the filter ID and keeping the
>     resource URI is considered an error since this causes the server
>     What is more, in my opinion the possibility of defining several
>     filters per resource is absolutely necessary to allow subscribers
>     to express advanced preferences about the content of event
>     notifications. For example, let us suppose a watcher that is
>     interested on getting to know the SMS service of a presentity
>     whenever this presentity changes its activity to "metting".
>     However, when the presentity changes its activity to "travel", the
>     watcher is interested on the IM service. How could this watcher
>     set these preferences into his or her RLS?
>
>
>     Thank you in advance,
>     Victoria
>
>
>
>
>     > I agree with you that this is unclear (in part because any
>     protocol description is improved if it enumerates its identifiers,
>     defines their formats and clearly states their uniqueness
>     constraints in combination with any other identifiers).
>     >
>     > 4660 makes no statements about the possible values and
>     uniqueness of the id attribute, but it is implicitly contrained by
>     > Since a resource may not be referred to in multiple filters,
>     either directly or via a list URI, the id attribute appears to
>     have no purpose except to prevent a filter being changed or
>     deleted for the same resource by entities that are not aware of
>     each other. Per RFC 4660#3.1, this could happen if the filter XML
>     is "uploaded to the server using means outside the scope of this
>     document.".
>     >
>     > Editorial fix to 4660: there are several occurrences of the
>     phrase "list specific list-specific" and "resource specific
>     resource-specific"; while it's undesirable to mix American and
>     International English use of the "possessive hyphen" in a single
>     document, it's simply incorrect to use both in the same place.
>     >
>     > All the best,
>     > Colm Smyth
>     >
>     > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     > Behalf Of Victoria Beltrán Martínez
>     > To: [email-masked] <mailto:[email-masked]>
>     > Regarding event notification filtering, I am not sure if I could
>     set different triggers to different pieces of presence information
>     different filters with different IDs and the same resource uri
>     (the presentity's uri). Following the filter criteria Schema in
>     RFC 4660, Could I create a document with two different filters
>     associated to a same resource?
>     >
>     > 4661 (section 3.3.3): "Replacing a filter by changing the filter
>     ID and keeping the resource URI is considered an error since this
>     causes the server to assume that two filters are placed for the
>     same resource".
>     >  From this sentence, I conclude that it is not possible to have
>     more than one filter per resource... But I find this restriction
>     unnecessary.
>     >
>     > [email-masked] <mailto:[email-masked]>

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 20 Nov 2008 02:21:35 +1100

Victoria,

I wrote this text. I apologise if its not clear, but the intention is to say
that multiple resources per URI are allowed. The proof is that the "uri"
attribute in the <filter> element is optional and you can have multiple
<filter> elements.

Thanks,
Hisham

2008/11/20 Victoria Beltrán Martínez <[email-masked]>

> refers to a single resource (simply it does not make any assumption about
> it). But, the penultimate paragraph states:
>
> "Regardless of whether the SUBSCRIBE is destined to a list URI, there can
> only be one filter applicable to a single resource or domain within a single
> SUBSCRIBE. That is, each filter within a subscription MUST uniquely identify
> one resource or one domain"
>
> resources, so that a subscription can't maintain more than one filter per
> resource.
>
> regards,
> Victoria
>
>> 2008/11/19 Smyth, Colm (Colm) <[email-masked] <mailto:[email-masked]
>> >>
>>
>>

---

From: Victoria Beltrán Martínez <[email-masked]>
Date: Wed, 19 Nov 2008 16:27:38 +0100

Hisham,

Thanks for your explanation.

regards,
Victoria

En/na Hisham Khartabil ha escrit:
> Victoria,
>
> I wrote this text. I apologise if its not clear, but the intention is 
> to say that multiple resources per URI are allowed. The proof is that 
> the "uri" attribute in the <filter> element is optional and you can 
> have multiple <filter> elements.
>
> Thanks,
> Hisham
>
> 2008/11/20 Victoria Beltrán Martínez <[email-masked] 
> <mailto:[email-masked]>>
>
>     Hi all,
>
>     I think that it's not clear that the 1st paragraph in section
>     4660#3.3.1 refers to a single resource (simply it does not make
>     any assumption about it). But, the penultimate paragraph states:
>
>     "Regardless of whether the SUBSCRIBE is destined to a list URI,
>     there can only be one filter applicable to a single resource or
>     domain within a single SUBSCRIBE. That is, each filter within a
>     subscription MUST uniquely identify one resource or one domain"
>
>     resources, so that a subscription can't maintain more than one
>     filter per resource.
>
>     regards,
>     Victoria
>
>         2008/11/19 Smyth, Colm (Colm) <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>
>         The whole document talks about a single resource unless it
>         explicitly talks about a SUBSCRIBE to a URI List.
>          
>
>
>
>            From: Victoria Beltrán Martínez
>         [mailto:[email-masked] <mailto:[email-masked]>
>            <mailto:[email-masked]
>         <mailto:[email-masked]>>]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>            Subject: Re: [Simple] RFC 4661: different notification
>         filters for
>            a sameresource?
>
>            Hi,
>
>            > Minor nit: your reference to Section 3.3.3 should be to
>         RFC 4660
>            rather than 4661.
>            >
>         <mailto:[email-masked] <mailto:[email-masked]>>
>            [mailto:[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>] On
>         <mailto:[email-masked] <mailto:[email-masked]>>
>            > Subject: [Simple] RFC 4661: different notification
>         filters for a
>            sameresource?
>            >
>            > Hello,
>            >
>            >
>            > <filter> elements must be unique, but I got confused when
>         I read in
>            > RFC
>         <mailto:[email-masked] <mailto:[email-masked]>>
>