Sieve Notification Using Presence Information
RFC 6132
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Lars Eggert No Objection
(Alexey Melnikov; former steering group member) Yes
(Peter Saint-Andre; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
dnd - Do Not Disturb; the user should not be disturbed now s/should not/does not wish to/ ?
(Dan Romascanu; former steering group member) No Objection
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 steering group member) No Objection
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 steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
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 steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
I support Tim's discuss.
(Stewart Bryant; former steering group member) No Objection
(Tim Polk; former steering group member) (was Discuss) No Objection