Sieve Email Filtering: Extension for Notifications
RFC 5435
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
Lars Eggert (was No Record, No Objection) No Objection
(Lisa Dusseault; former steering group member) Yes
(Chris Newman; former steering group member) (was Yes) No Objection
In response to Cullen's discuss, it is possible to construct parameters from message content using the Sieve variables extension, as the last paragraph in the security considerations points out. That paragraph points out the need for URL encoding of the parameters, but does not discuss the security implications of generating the address from message content. While I suspect most implementers/users would not be foolish enough to do that, particularly because the syntax gets so grotty, it wouldn't hurt to mention how dangerous that is. One simple remedy for the threat would be to simply disallow use of sieve variables in the method parameter of the notify command via script analysis. Note that I would not discuss over this issue, but I do think a brief comment on this issue in the security considerations would improve the document. My previous comments: An issue with nomenclature that I recommend fixing. This document uses the term "importance" with a completely different meaning from the "importance" header in the Header Registry. Indeed, in this document, the term "importance" has the same meaning as the "priority" header in the mail headers registry and the "urgency" header in the XMPP registry. I would prefer this used consistent terminology. I recommend ":urgency" or ":priority" instead of ":importance". I understand the change would be annoying this late in the process given the notify XMPP document has to be updated as well, which is why I'm not making this a discuss issue. But please consider this seriously. One nit. The IANA registration template for notification mechanisms (section 9.2) uses "Standards Track/IESG-approved experimental RFC number:" in the template, but that registry uses the "Specification Required" policy that does not require standards track processing or IESG approval. I suggest the template use "Permanent and readily available reference:" to avoid confusion.
(Cullen Jennings; former steering group member) (was Discuss, No Objection, Discuss) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Ward; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
From Gen-ART Review by Pasi Eronen. The document effectively creates a new "name space" for notification-capability values, and defines a single value "online". Shouldn't this be included in the IANA considerations section, requesting IANA to maintain a registry for notification-capability values?
(Sam Hartman; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
Sean Turner's secdir review raised some Last Call issues that merit further review.