Dmitry,
Regardless of how it is worded, the language you reference in 3261 needs
to apply to any header that allows name-addr or addr-spec followed by
semicolon separated header parameters or comma separated fields.
The reason is that without this restriction there is an ambiguity as to
whether a semicolon separated parameters - they could be URI parameters
or header parameters. This statement breaks the ambiguity - it says if
the parse is done as addr-spec then the parameters are header parameters.
So this rule applies anywhere the ambiguity exists, including the
Refer-To header.
Paul
Dmitry Akindinov wrote:
> Hello,
>
> RFC 3261 imposes the following restriction on URIs presented in the
> Contact, From, To, Reply-To header fields:
>
> Even if the "display-name" is empty, the "name-addr" form MUST be
> used if the "addr-spec" contains a comma, semicolon, or question
> mark. There may or may not be LWS between the display-name and the
> "<".
>
> On the other hand, RFC 3515 does not set such restriction:
>
> 2.1 The Refer-To Header Field
>
> Refer-To is a request header field (request-header) as defined by
> [1]. It only appears in a REFER request. It provides a URL to
> reference.
>
> Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *
> (SEMI generic-param)
>
> This makes the following field legal:
>
> Refer-To: sip:[EMAIL PROTECTED];
> Replaces=090459243588173445%3B
> to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces
>
> and some implementations do try to format Refer-To: fields this way.
> Should we accept this format, or should the RFC 3515 be corrected?
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
