Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)
RFC 4458

[Ballot comment]
I see (a couple of times)
      Contact:

I suspect that the 92.168.0.1 better be changed into an IP address
that complies with RFC3330.

[Ballot discuss]
This document modifies a section of the 3261 ABNF.  The original ABNF is as follows:

uri-parameter    =  transport-param / user-param / method-param
                    / ttl-param / maddr-param / lr-param / other-param
transport-param  =  "transport="
                    ( "udp" / "tcp" / "sctp" / "tls"
                    / other-transport)
other-transport  =  token
user-param        =  "user=" ( "phone" / "ip" / other-user)
other-user        =  token
method-param      =  "method=" Method
ttl-param        =  "ttl=" ttl
maddr-param      =  "maddr=" host
lr-param          =  "lr"
other-param      =  pname [ "=" pvalue ]
pname            =  1*paramchar
pvalue            =  1*paramchar
paramchar        =  param-unreserved / unreserved / escaped
param-unreserved  =  "[" / "]" / "/" / ":" / "&" / "+" / "$"

This document modifies it by adding the following:

This specification updates the ABNF in Section 25 of RFC 3261 [1] to
  add the target-param to the uri-parameter as shown below.

    uri-parameter    =  transport-param / user-param /
                          method-param / ttl-param / maddr-param /
                          lr-param / other-param /
                          target-param / cause-param

    target-param      =  "target"  EQUAL pvalue

    cause-param      =  "cause" EQUAL Status-Code

So, I understand the 3968 allows the registration of new parameter values without a standards-track RFC, but can the ABNF be updated in an informational?  I'm also wondering whether it actually needs to be updated, or whether this can actually be understood using the other-param value already in 3261.

IANA Comments:
Upon approval of this document the IANA will register 2 new values for target and cause to the SIP/SIPS URI Parameters sub-registry found at the following:
http://www.iana.org/assignments/sip-parameters as defined in [3].

(The text in the document says value singular but it appears there are 2 registrations.)

[Ballot comment]
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."

[Ballot discuss]
Section 8.2 says:
  >
  > The scenario in which B wants to make sure that C does not see that
  > the call was to B is easier to deal with but a bit weird.
  >
  Isn't this the service needed to allow anonymous calls to a voice
  mailbox on a "whistle blower hotline?"

[Ballot discuss]
Section 8.2 says:
  >
  > The scenario in which B wants to make sure that C does not see that
  > the call was to B is easier to deal with but a bit weird.
  >
  Isn't this the service needed to allow anonymous calls to a voice
  mailbox on a "whistle blower hotline?"

Mail from Cullen last week that he is ready for progress -
has had significant expert review by
SIPPING and discussion with ETSI because it turns out to
meet up with and support an important time-sensitive requirement.