Skip to main content

Sieve Email Filtering: Extension for Notifications
RFC 5435

Yes

(Lisa Dusseault)

No Objection

Lars Eggert
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Jon Peterson)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Sam Hartman)

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

Lars Eggert
(was No Record, No Objection) No Objection
Lisa Dusseault Former IESG member
Yes
Yes ()

                            
Chris Newman Former IESG member
(was Yes) No Objection
No Objection (2007-12-20)
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 IESG member
(was Discuss, No Objection, Discuss) No Objection
No Objection ()

                            
Dan Romascanu Former IESG member
No Objection
No Objection ()

                            
David Ward Former IESG member
No Objection
No Objection ()

                            
Jari Arkko Former IESG member
No Objection
No Objection ()

                            
Jon Peterson Former IESG member
No Objection
No Objection ()

                            
Magnus Westerlund Former IESG member
No Objection
No Objection ()

                            
Mark Townsley Former IESG member
No Objection
No Objection ()

                            
Ron Bonica Former IESG member
No Objection
No Objection ()

                            
Ross Callon Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
No Objection
No Objection (2007-12-19)
  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 IESG member
No Objection
No Objection ()

                            
Tim Polk Former IESG member
No Objection
No Objection (2007-12-19)
Sean Turner's secdir review raised some Last Call issues that merit further review.