Sieve Notification Using Presence Information
draft-ietf-sieve-notify-presence-04

dnd  - Do Not Disturb; the user should not be disturbed now

s/should not/does not wish to/ ?

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)

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.

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.

I support Tim's discuss.