Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)
RFC 4458
Yes
(Allison Mankin)
No Objection
(David Kessens)
(Margaret Cullen)
(Sam Hartman)
(Ted Hardie)
No Record
Note: This ballot was opened for revision 06 and is now closed.
Allison Mankin Former IESG member
Yes
Yes
()
Brian Carpenter Former IESG member
No Objection
No Objection
(2006-01-03)
Points from a Gen-ART review by Scott Brim, to be considered as possible clarifications. -------- First, Section 4 says there is an assumption that the sender knows what target syntax is valid on the receiving system. Target syntax is apparently known with certainty when it is provided by the intended recipient e.g. in a "Moved" message. Other than that, target syntax is a local matter, right? One of the draft goals is to match expectations of ETSI and TDM systems. Do they already have some syntax defined for targets, at least for common situations? If so, and since the point of the draft is to promote common usage, shouldn't they be reproduced or referenced here? As another possibility, have you considered having a default universal target syntax, which would be converted to the local syntax by interworking functions? That would put the problem where it belongs, at the receiver (or interworker), not the sender. If you don't need this, because target syntax is always known in all reasonable deployment cases, then maybe you could redo the first paragraph of Section 4? Next ... Section 8.1 says: "Any redirection of a call to an attacker's mailbox is serious. It is trivial for an attacker to make its mailbox seem very much like the real mailbox and forward the messages to the real mailbox so that the fact that the messages have been intercepted or even tampered with escapes detection." There seems to be a general sense that the caller A must depend on the security behavior of the callee B, and that the caller has no way to authenticate the party it finally connects to (C). I don't like security dependencies. I don't know enough about SIP to make a specific suggestion, but can't A authenticate C the same way it would authenticate B in the first place? Finally, something smaller. The cause codes (aka redirecting reasons) are referred to as SIP "error" codes in 2.0. Is this just a slip, or are informational codes generally referred to as "error" codes in SIP drafts? In case you decide to do another revision, there is a typo: "This was only done for formatting and is not a valid SIP messages."
David Kessens Former IESG member
No Objection
No Objection
()
Margaret Cullen Former IESG member
No Objection
No Objection
()
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2006-01-01)
I suggest swapping section 5 and section 6. Section 8.1: s/man in the middle/man-in-the-middle/ Section 8.1: s/hop by hop/hop-by-hop/ (2 places)
Sam Hartman Former IESG member
No Objection
No Objection
()
Ted Hardie Former IESG member
(was Discuss)
No Objection
No Objection
()
Bert Wijnen Former IESG member
No Record
No Record
(2006-01-05)
I see (a couple of times) Contact: <sip:alice@92.168.0.1> I suspect that the 92.168.0.1 better be changed into an IP address that complies with RFC3330.