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: [email-masked]
Date: Mon, 12 Jan 2004 15:25:14 +0200

No, both drafts still exist and present different requirements for filtering different event packages.

Regards,
Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Alex Audu
> Sent: 09.January.2004 21:23
> To: Niemi Aki (Nokia-M/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] Comments on 
> draft-ietf-simple-winfo-filter-reqs-00
> 
> 
> Aki,
> 
> Hasn't this draft been superseeded by
> draft-ietf-simple-pres-filter-reqs-02.txt?
> 
> Regards,
> Alex.
> 
> 
> "Niemi Aki (Nokia-M/Helsinki)" wrote:
> 
> > All,
> >

---

From: [email-masked]
Date: Mon, 12 Jan 2004 15:25:14 +0200

Regards,
Hisham

---

From: [email-masked]
Date: Mon, 19 Jan 2004 14:16:09 +0200

Aki,

Thanks for the comments. All suggestions were taken into consideration. Some answers to your questions below..

> ext Niemi Aki (Nokia-M/Helsinki)
> Sent: 09.January.2004 17:13
> To: [email-masked]
> Subject: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00
> 
>
> 

Any. I'll clarify.

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

I changed status to state and clarified the requirement.

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

In winfo, it could mean first NOTIFY after a subscription carries full state, and subsequent notfications carrying partial state. (but you are right, it means no filter set by subscriber).

> the start of ch 4 -> combine?

4.2 talks about the server not understanding the format of the filter (the MIME type). The req at the start of section 4 talks about the server understanding the filter but rejecting it.

Regards,
Hisham

---

From: [email-masked]
Date: Mon, 19 Jan 2004 14:16:09 +0200

Aki,

Any. I'll clarify.

Regards,
Hisham