Alex Balashov <abalas...@evaristesys.com> writes:
> As far as I can tell from the RFC 3261 ABNF, it is permitted to put SEMI
> and EQUAL in the username of a URI, but it has no semantic validity.
> That is to say, this is permitted:
>
> <sip:myval=abc;user@domain:5060>
True, though you probably meant
<sip:user;myval=abc@domain:5060>
> but doesn't mean anything. 'myval=abc;user' is just one big long username:
That is true. But since the proxies in a domain are permitted to
interpret the username part however they wish, what that statement means
is that redirection services are not required by 3261 to ignore
"username parameters" that they do not understand. Perhaps there is
another, less universally implemented standard that specifies this
behavior.
But most telephone carrier networks are closed systems, and whoever is
creating a URI within that domain probably knows whether the domain's
redirection services apply this rule to "username parameters" or not.
Beware that there is a *URI* parameter whose name is "user", and the
text in RFC 3261 section 19.1 refers to it as the "user parameter", so
you have to be careful not to confuse "username parameter" with "user
parameter".
> And yet, there are some specs out there which put tokens which are
> semantically key=value parameters in the user part of a URI, and expect
> equipment to extract their values. One spec in particular that comes to
> mind is RFC 4694 ("Number Portability Parameters for the "tel" URI"),
> which explicitly contemplates outcomes like this:
>
> Contact: <sip:14045551212;npdi;rn=14045550000@domain>
Certainly the process described in section RFC 3261 19.1.6 suggests that
equipment will interpret username parameters as you have described. But
it doesn't require any particular interpretation.
> The ultimate reason for asking is that I am looking to embed a parameter
> like this in a Diversion URI. I am dealing with a gateway that will try
> a redirect destination
As far as I know, this depends on the gateway. What are its
specifications? Though RFC 3966 defines that the set of tel parameters
is extensible, suggesting that equipment ignores parameters that it does
not understand. Given the mapping in 19.1.6, that suggests that the
unknown username-parameters in user-parts of derived SIP URIs should be
ignored.
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
