Skip to main content

Sieve Notification Mechanism: SIP MESSAGE
RFC 6468

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 steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (2011-10-04)
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 steering group member) No Objection

No Objection (2011-10-05)
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 steering group member) No Objection

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

(Peter Saint-Andre; former steering group member) No Objection

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) No Objection

No Objection ()

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2011-09-25)
- 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 steering group member) No Objection

No Objection ()

                            

(Wesley Eddy; former steering group member) No Objection

No Objection ()