Sieve Notification Mechanism: SIP MESSAGE
Note: This ballot was opened for revision 08 and is now closed.
(Pete Resnick) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
Comment (2011-10-04 for -)
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...
(Stephen Farrell) (was Discuss) No Objection
- 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.)
(David Harrington) No Objection
(Russ Housley) No Objection
(Dan Romascanu) No Objection
Comment (2011-10-05 for -)
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.