Skip to main content

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