Subject: [Simple] Comments on draft-ietf-simple-pres-filter-reqs-02

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

All,

Here are some comments to the filtering requirements. As with the winfo 
reqs, I don't think there's anything major, just a bit of tweaking the 
format and language.

Cheers,
Aki

---

- Overall, the draft suffers from the same thing as the winfo-reqs - it 
needs a chapter that explains the model and defines terms that then are 
used throughout the rest of the document.

- Overall nit, requirement labels lack numbers

- In 3.2, 1st and 2nd req, if we replace "presentity" with "resource" in 
the 1sr req, then the second one becomes obsolete, no?

- In 3.2, 3rd req, what is a sub-list? If it means a presence list that 
is nested insiode another list, then the above bullet should cover that 
as well.

- In 3.2, 4th req is really hard to understand.

- In 3.3, 1st sentence, this goes to my overall comment about model and 
terms, "triggering conditions" is not self-explanatory enough for me to 
understand immediately what were talking about here.

- In 3.3, 2nd req, if not on the presence information, what would the 
triggering be based on?

- In 3.3, 3rd req is hard to parse, suggest rewording similar to one I 
suggested for winfo filtering reqs.

- In 4.1.2, 2nd req, the server default here being "no filter"?

- In 4.2, 4th req, how about:

	It MUST be possible for the server to terminate a
	subscription if a filter is no longer acceptable,
	e.g., due to policy change or server load.

- In 5.1, last req is confusing. Is this needed at all?

- Move 5.3 to Security requirements.

- In 6, 1st req contradicts earlier requirement on client receiving 
ack/nack from installing a filter.

- In 6, 2nd requirement has no CAPS, what is the strength of this 
requirement?

- In 6, last req is hard to understand. Suggest rewording, and using 
"SHOULD NOT convey information..."

---

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

---

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

Aki,

Thanks for the comments. Some replies inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Niemi Aki (Nokia-M/Helsinki)
> Sent: 09.January.2004 17:30
> To: [email-masked]
> Subject: [Simple] Comments on draft-ietf-simple-pres-filter-reqs-02
> 
> 
> All,
> 

Done.

> - Overall nit, requirement labels lack numbers

Now requirements include numbers.

> the 1sr req, then the second one becomes obsolete, no?

I don't know. Is a resource the same as a resource list?

> is nested insiode another list, then the above bullet should 

I would like to keep requirements from event list and individual presentities separate in order to make sure the solution works for both.

> - In 3.2, 4th req is really hard to understand.

Reworded.

> - In 3.3, 2nd req, if not on the presence information, what would the 

Some external triggers. I can make a filter that triggers notifications to be sent using time of day. This is outside the scope of this work.

> suggested for winfo filtering reqs.

Reworded.

> - In 4.1.2, 2nd req, the server default here being "no filter"?

means full state notification in presence case. In winfo, it could mean first NOTIFY after a subscription carries full state, and subsequent notfications carrying partial state.

> 	e.g., due to policy change or server load.

That works.

> - In 5.1, last req is confusing. Is this needed at all?

Reworded. I think it is needed just to make sure that the solution works with nested event lists.

> - Move 5.3 to Security requirements.

Moved. 

> ack/nack from installing a filter.

Added "if the server policy allows" to the earlier requirement (section 4).

> - In 6, 2nd requirement has no CAPS, what is the strength of this 

Fixed.

> "SHOULD NOT convey information..."

Reworded.

Thanks again.

Hisham

---

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

Aki,

Done.

Reworded.

Reworded.

That works.

Moved. 

Fixed.

Reworded.

Thanks again.

Hisham