Hello,

Jeroen van Bemmel wrote:
> Dmitry,
> 
> You probably mean
> 
> Refer-To: sip:[EMAIL PROTECTED]
>    Replaces=090459243588173445%3B
>    to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces
> 
> (so with '?')

Yes, thank you.

> The reason for this rule is to avoid ambiguity, this is perhaps less the 
> case for '?' but for ';' the parameters would be considered part of the 
> header (and not of the URI) unless the form with '<' '>' is used.
> 
> In general, I would say it is recommended to always use the "name-addr" 
> form. However, following the Internet rule that you should be strict in 
> what you send and liberal in what you accept, the above format should be 
> accepted (also for From, To, etc).

That's understood and we are going to fix our parser code to accept URIs 
with parameters even when those are not enclosed in angle brackets.

> We could add a remark to RFC3515, when(ever) that gets updated

It appears that either 3261 or 3515 need updating. Or both?
3261 defines the rules for formatting From, To, Contact and Reply-To 
headers (and URIs in those) - but does not make those rules common for 
all headers. 3515, on the other hand, specifies that either addr-spec or 
name-addr can be used, but without telling us what we have to expect. As 
the result, parser code needs to deal with separate "cases", e.g. 
handling Refer-To and From in a different manner.

Ideally, 3261 should be fixed to make the rules for formatting headers 
to be common for all headers that contain URIs.

Standards are worth anything when they allow us to avoid ambiguity, not 
to add new. :-)

> Regards,
> Jeroen

Thank you very much!

> 
> 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
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to