Hello,
Paul Kyzivat wrote:
> 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.
That's what we expected. But the RFC document explicitly defines this
rule just for some listed headers. Thus the ambiguity with headers added
by newer RFC documents, like 3515.
> 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.
Yet the 3515 document specifies that both forms (addr-spec and
name-addr) can be used. Looks like we need to modify the parser code to
treat Refer-To in a special way and accept both forms.
Thank you.
> 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?
>>
--
Best regards,
Dmitry Akindinov -- Stalker Labs.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
