Sieve Notification Using Presence Information
draft-ietf-sieve-notify-presence-04
Yes
(Alexey Melnikov)
(Peter Saint-Andre)
No Objection
(Jari Arkko)
(Lars Eggert)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Tim Polk)
Note: This ballot was opened for revision 04 and is now closed.
Alexey Melnikov Former IESG member
Yes
Yes
()
Unknown
Peter Saint-Andre Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2010-12-13)
Unknown
dnd - Do Not Disturb; the user should not be disturbed now s/should not/does not wish to/ ?
Dan Romascanu Former IESG member
No Objection
No Objection
(2010-12-14)
Unknown
1.The language in the Security Considerations section is inconsistent in the way it deals with the actions needed to be considered by implementations to mitigate the security threats described in this section. While the first paragraph ends with: > In addition, implementations MUST ensure that users can not create scripts that access the presence information of others without the proper access controls. the third one says: > Implementations might consider providing options for rate limiting, or for caching presence tests for periods of time, even across Sieve script instances. For consitency purposes it would be better to use 2119 language in both places or none. My preference would be for a MAY or SHOULD to be used in the later case. 2. The OPS-DIR review by Peter Koch questioned the free format of the status information for: > Description: A human-readable description of the user's availability status. This is similar to the presence element with the same name that's defined in Section 2.2.2.2 of RFC 3921. Syntax: There is no formal definition for the values this item may take. It is free-form and may be in any language, and is meant for human consumption. I think that it would be better to clarify that as per RFC 3921 this is a natural language description (which is more clear than 'any language') and that Sieve already specifies that strings are in UTF-8 (RFC 5228, section 2.1)
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(2010-12-16)
Unknown
In Section 2, the first time XMPP is mentioned there is no reference to the XMPP spec. The reference only appears later. Adding a reference the first time XMPP appears in the text would be useful.
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(2010-12-14)
Unknown
As far as I can tell so far, nothing in this document would make it hard to later extend its ideas to cover other types of presence information, up to and including queries against current location (PIDF-LO) enabling rules like "only send me an SMS notification if I'm in the country" - so, I'm entering this as a comment instead of a discuss. Please consider further reinforcing that these notification capability parameter values are going to be derived from potentially several inputs, including calendars as well as presence servers. It would help to informatively reference PIDF (RFC3863), especially in the registration of the "status" element, pointing to PIDF's "note" element in section 4.1.6. Also please consider calling out considering RPID and PDIF-LO when choosing new capability parameter names in the discussion of adding new presence items.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2010-12-16)
Unknown
I support Tim's discuss.
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown