Sieve Notification Mechanism: SIP MESSAGE
draft-ietf-sieve-notify-sip-message-08
Yes
(Pete Resnick)
No Objection
(David Harrington)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 08 and is now closed.
Pete Resnick Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2011-10-04)
Unknown
I have a bunch of Comments on this document. I don't think any is serious enough to merit a Discuss, but I do hope the authors will have a look at addressing them before the document is advanced for publication. --- Section 2.1 Passive voice is to be avoided... The URI parameter "method" MUST be included and MUST contain the value "MESSAGE". Must be included where and by whom? --- Section 2.1 Is the "note" present twice? --- Section 2.2 You have a couple of instances of :from without quote marks. --- Section 2.5 The default message body SHOULD contain the values of the "From" and "Subject" header fields of the triggering email message One is bound to ask: under what circumstances can the From and Subject header fields be left out, and what would the result be? --- Section 2.6 Implementations SHOULD NOT use the hname "body" parameter value as the message-body of the SIP MESSAGE request. Since this is "SHOULD NOT" they presumably can do so if they have good reasons. Can you state that reason or change this to "MUST NOT"? --- Section 2.6 If the notification request fails, there will be a SIP error code describing the failure. Elegant prose, but unsure exactly what it means. It could mean that there is no failure other than one for which a SIP error code has been defined. Or it could mean that an error code will be found in a majick place. --- Section 2.7 Because, absent use of SIP extensions such as [RFC3856], it is impossible to tell in advance whether the notification recipient is online and able to receive a SIP MESSAGE, the notify_method_capability test for "online" will always return "maybe" for this notification method. But surely, if RFC 3856 extensions are in use, the test for "online" could return more details. Maybe you intend to say that the test needs to have uniform behavior regardless of whether 3856 extensions are in use, and so...
Dan Romascanu Former IESG member
No Objection
No Objection
(2011-10-05)
Unknown
I have a similar comment as Stephen (in his first comment). The use case is not clear, and some text or reference about why and where notifications are sent over SIP would be useful.
David Harrington Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2011-09-25)
Unknown
- I don't get the use-case for this - why would I want a SIP MESSAGE for each of the emails I get? I think a motivating use-case (or reference thereto) would be useful. - (Related to discuss point 1) How can a program "take care" to "ensure that confidential information is not sent" when any inbound mail might be forwarded? If you mean that deployments SHOULD use sips URIs then just saying that seems better. - If someone set this up and that could be detected from the Internet, and if each SIP MESSAGE cost someone some money, then a botnet could easily ramp up a whole lot of charges. Is that something that warrants a mention? (I'm not sure.)
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown