Skip to main content

Sieve Notification Using Presence Information
RFC 6132

Yes

(Alexey Melnikov)
(Peter Saint-Andre)

No Objection

Lars Eggert
(Jari Arkko)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Tim Polk)

Note: This ballot was opened for revision 04 and is now closed.

Lars Eggert No Objection

(Alexey Melnikov; former steering group member) Yes

Yes ()

                            

(Peter Saint-Andre; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (2010-12-13)
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

No Objection (2010-12-14)
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

No Objection (2010-12-16)
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

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection (2010-12-14)
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

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) No Objection

No Objection (2010-12-16)
I support Tim's discuss.

(Stewart Bryant; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection ()