Sieve Notification Mechanism: SIP MESSAGE
RFC 6468

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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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...

   URI parameter "method" MUST be included and MUST contain the value

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


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

Comment (2011-09-25)
No email
send info
- 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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection