Subject: [Sip] RFC3515 Refer-To ABNF

From: "Joel Payeur" <[email-masked]>
Date: Thu, 23 Sep 2004 10:42:03 -0400

Hi,

Refer-To's ABNF:

      Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *
      (SEMI generic-param)

as well as being incompatible with previous Refer-To draft ABNF (it adds optional parameters at the header level), does not seem to be consistent on its own.

If I have the header:

Refer-To: sip:user@host;param=value

This is RFC3515 ABNF compliant. However, is "param" part of the header, or part of the URI? If i use the addr-spec form, i guess the param should be part of the URI then. Or is it?

The problem comes from allowing name-addr/addr-spec. This was also present for other headers in RFC3261, these are From,To, Contact and Reply-To, however for each of these a comment was inserted to clarify that the name-addr form (angle quotes) MUST be used if parameters or headers are present in the URI:

RFC3261 Sect 20:

   The Contact, From, and To header fields contain a URI.  If the URI
   contains a comma, question mark or semicolon, the URI MUST be
   enclosed in angle brackets (< and >).  Any URI parameters are
   contained within these brackets.  If the URI is not enclosed in angle
   brackets, any semicolon-delimited parameters are header-parameters,
   not URI parameters.

Sect 20.31 Reply-To
   Even if the "display-name" is empty, the "name-addr" form MUST be
   used if the "addr-spec" contains a comma, question mark, or
   semicolon.  Syntax issues are discussed in Section 7.3.1.

My question is: If RFC3261 mandates that the name-addr form be used if the URI has parameters/headers, why would it not be the same for Refer-To? It is safe to assume that extension headers should also conform to this? Should we add the section 20.31 comment Refer-To's definition? The examples section in 3515 goes this way... 

I'm also wondering why the ABNF allows name-addr/addr-spec, when it could be simpler by allowing only name-addr, as is the case for Route and Record-route? Is this legacy for Pre-Rfc3515 compatibility?

Thanks,

Joel@m5t

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Robert Sparks <[email-masked]>
Date: Thu, 23 Sep 2004 09:59:25 -0500

The use is the same in Refer-To as it was for From/To/Contact.

Any instance of name-addr | addr-spec in SIP headers will follow this 
same rule.
(and we are being more careful as we go forward to be explicit in each 
document)

If you have a URI parameter you must place it inside angle brackets. 
Any semicolon
delimited parameters appearing outside brackets are header parameters, 
not URI
parameters.

RjS

On Sep 23, 2004, at 9:42 AM, Joel Payeur wrote:

> as well as being incompatible with previous Refer-To draft ABNF (it 
> adds optional parameters at the header level), does not seem to be 
> consistent on its own.
>
> If I have the header:
>
> This is RFC3515 ABNF compliant. However, is "param" part of the 
> header, or part of the URI? If i use the addr-spec form, i guess the 
> param should be part of the URI then. Or is it?
>
> The problem comes from allowing name-addr/addr-spec. This was also 
> present for other headers in RFC3261, these are From,To, Contact and 
> Reply-To, however for each of these a comment was inserted to clarify 
> that the name-addr form (angle quotes) MUST be used if parameters or 
> headers are present in the URI:
>
> RFC3261 Sect 20:
>
> My question is: If RFC3261 mandates that the name-addr form be used if 
> the URI has parameters/headers, why would it not be the same for 
> Refer-To? It is safe to assume that extension headers should also 
> conform to this? Should we add the section 20.31 comment Refer-To's 
> definition? The examples section in 3515 goes this way...
>
> I'm also wondering why the ABNF allows name-addr/addr-spec, when it 
> could be simpler by allowing only name-addr, as is the case for Route 
> and Record-route? Is this legacy for Pre-Rfc3515 compatibility?
>
> Thanks,
>
> Joel@m5t