Subject: [Simple] Review of draft-ietf-simple-pres-filter-reqs-02

From: "Chris Boulton" <[email-masked]>
Date: Thu, 8 Jan 2004 12:36:23 -0000

Hisham,
 
            Had a review of the following draft:
draft-ietf-simple-pres-filter-reqs-02.  Looks pretty good to me ;-) Got
a couple of observations that I wouldn't mind some clarification on.
Not sure how much of it is useful.

1) NIT - In the introduction the end of the fourth paragraph reads:-
 
However, the definition of filtering was considered out of scope was
left as future work.
 
And could read:-
 
However, the definition of filtering was considered out of scope and was
left as work to be completed in the future.
 
2) Section 3.2 
Are the following 2 requirements really necessary:-
 
REQ xx: It MUST be possible for the watcher to indicate, in the
   filter criteria, the target presentity list whose presence
   information a certain filter is applied to.
 
   REQ xx: It MUST be possible for the watcher to indicate, in the
   filter criteria, the target presentity sub-list whose presence
   information a certain filter is applied to.
 
Should the requirement just be that it can indicate a presentity.  If
that happens to be a list resource then so be it.
 
3) NIT - Section 3.3
The first paragraph reads:-
 
This chapter presents requirements for specifying the triggering
conditions that result in notifications to be sent to the client.
 
Could read:-
 
This chapter presents requirements for specifying the triggering
conditions that result in notifications to be sent to a watcher.
 
4) Section 3.3
Is the following requirement needed:-
 
REQ xx: The triggering conditions MUST be based on the presence
   information. For example, the change of value of the <status>
   element.
 
Would it be better for a more generic approach for all event packages
and just leave only the next requirement in to cover all triggers:-
 
REQ xx: It MUST be possible to specify logical expressions based on
   the value of elements defined in the package for the purpose of
   triggering. This covers expressions (tests) related to the change of
   an element's value, and reaching a certain value of an element.
 
5) Section 3.4 - Should the following requirements be made generic
rather than being tied to presence:-
 
 REQ xx: It MUST be possible for the watcher to specify the presence
   information elements (XML elements and/or attributes) in [2] to be
   delivered in the notification.
 
   REQ xx: It MUST be possible for the watcher to specify presence
   information in any extension to PIDF to be delivered in the
   notifications, based on  XML elements and/or attributes. See for
   example [3].
 
   REQ xx: It MUST be possible for the watcher to specify presence
   information in any extension to be delivered in the notifications,
   based on  namespaces.
 
6) Section 4.2 - Do we need to specify a requirement for when a
subscription containing a filter expires (invalid)?  Does the filter
remain or is it removed also?
 
7) Section 5.1 - The requirement reads:-
 
REQ xx: It MUST be possible for a watcher to specify different filter
   for any individual member of a resource list in a resource list
   subscription.
 
If a user does specify a different filter to that of a resource list -
does this override - I would say 'yes' so perhaps this needs to be
mentioned.
 
Hope some of this is useful,
 
Best Regards,
 
Chris.

------------------------------------------------
Chris Boulton
Ubiquity Software
 
Tel : +44 (0) 1633765600
Fax : +44 (0) 1633765601 
------------------------------------------------

This message has been scanned for viruses by MailControl - www.mailcontrol.com

---

From: [email-masked]
Date: Thu, 15 Jan 2004 16:56:02 +0200

Chris,
 
Thanks for the comments. Some comments inline...
-----Original Message-----
From: ext Chris Boulton [mailto:[email-masked]]
Sent: 08.January.2004 14:36
To: Khartabil Hisham (Nokia-TP/Helsinki)
Cc: [email-masked]
Subject: Review of draft-ietf-simple-pres-filter-reqs-02

2) Section 3.2 

 
Should the requirement just be that it can indicate a presentity.  If that happens to be a list resource then so be it. 
 
I think it is necessary to make sure that filtering also works with event lists. Different parts of the network handle filters depending on the nature of the subscription. For example a Resource List Server would most likely handle filters to an event list and therefore requiring the filtering to work for event lists is needed. 

4) Section 3.3

I think it is needed. There may be other external triggers for a notification to be sent. The filtering solution must not define those, but concentrate on triggers in changes to the presence information document only. 
 
Would it be better for a more generic approach for all event packages and just leave only the next requirement in to cover all triggers:- 
 
Remember these are presence filtering requirements. We originally had a general filtering requirements document, but it was decided a couple of IETF meeting ago to write separate filtering requirements for each event package.

5) Section 3.4 - Should the following requirements be made generic rather than being tied to presence:- 
 
Please see above. 

6) Section 4.2 - Do we need to specify a requirement for when a subscription containing a filter expires (invalid)?  Does the filter remain or is it removed also? 
 
Added: It MUST NOT be required for a watcher to explicitly remove a filter f the subscription was terminated or has expired.  I.e. The filter is automatically removed with the subscription.

 
If a user does specify a different filter to that of a resource list - does this override - I would say 'yes' so perhaps this needs to be mentioned. 
 
It is most likely that the event list filter is handled by the RLS while the individual resource filter is handled at that resource's presence server. Therefore no need to mention which one overrides. I added this requirement though:
 
 It MUST be possible to specify a filter for an event list and a filters for resources within that list in the same subscription request. 
 
Thanks again for the comments.
/Hisham

Best Regards,
 
Chris.

Tel : +44 (0) 1633765600
Fax : +44 (0) 1633765601 

This message has been scanned for viruses by  <http://www.mailcontrol.com/> MailControl, a service from  <http://www.blackspider.com/> BlackSpider Technologies.

---

From: [email-masked]
Date: Thu, 15 Jan 2004 16:56:02 +0200

Chris,
 
-----Original Message-----
From: ext Chris Boulton [mailto:[email-masked]]
Sent: 08.January.2004 14:36
To: Khartabil Hisham (Nokia-TP/Helsinki)
Cc: [email-masked]
Subject: Review of draft-ietf-simple-pres-filter-reqs-02

2) Section 3.2 

 

4) Section 3.3

 

 
 
Please see above. 

 

 

 
 
Best Regards,
 
Chris.

Tel : +44 (0) 1633765600
Fax : +44 (0) 1633765601