Subject: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00

From: "Niemi Aki (Nokia-M/Helsinki)" <[email-masked]>
Date: Fri, 09 Jan 2004 17:13:03 +0200

All,

I read the draft and here are some comments. Nothing major on the 
requirements themselves (I think they're pretty straightforward anyway) 
but some on the content/formatting of the draft.

Cheers,
Aki

---

- Overall, I think the draft suffers from not having a section that 
clearly lays out the model, and defines the used terms. For example, it 
now uses "filters", "rules", "tests", "settings" pretty much 
interchangeably, which hurts readability. My suggestion is to write a 
short chapter with maybe a diagram that explains the model, the actors, 
and the objects that they exchange - then use that terminology 
throughout the draft.

- The requirements could be labeled, as in "REQ-1:", but it isn't that 
important here.

- In 3.1, 2nd s., possible -> able

- In 3.2, 1st s., this is really awkward language. How about:

	The client MUST be able to indicate the event package
	to which the filter applies.

- In 3.3, 1st s., bu "user" I think should be "resource" or "presentity"?

- In 3.4, 2nd p., does it mean <watcher> elements specifically, or any 
XML elements in winfo?

- In 3.4, 3rd p. and 4th p., this is really hard to parse. I think I 
guessed what it means, but there must be a better way to state this 
requirement...

	It MUST be possible to define a set of conditions
	for the values of certain elements in a winfo document
	that determine which elements to send in notifications.

- In 3.4.1, "have a specific status" instead of "are in a specific status"

- Overall, section 3.4 could be summarized as:

	It MUST be possible to qualify content in a winfo
	notification based on any XML element, and
	specifically:

	* Watcher
	* Watcher status
	* Event causing a change in status
	* Subscription expiration
	* Subscription duration

	In addition, it MUST be possible to construct locigal
	expressions for values of certain elements that when
	evaluated to TRUE, will result in an element qualifying
	to be delivered in a notification.

   In addition, this should probably include XML namespaces, similar to 
presence filtering.

- In 4.1.2, 2nd p., I guess the default here means "no installed filter"?

- Requirement in 4.2 is quite similar to the top level requirement at 
the start of ch 4 -> combine?

- In 6., example 4, I don't think this is a relevant example, how about 
replacing it with:

	A presentity requests information on watchers that
	have their status as "waiting", for authorization
	purposes.

---

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

---

From: Alex Audu <[email-masked]>
Date: Fri, 09 Jan 2004 13:23:19 -0600

Aki,

Hasn't this draft been superseeded by
draft-ietf-simple-pres-filter-reqs-02.txt?

Regards,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Fri, 09 Jan 2004 13:23:19 -0600

Aki,

Regards,
Alex.