Re: [Sip] Possible bug in REGISTER 200-OK Contact specification

[Robert Sparks <rjsparks at nostrum.com>]

To summarize:

The problem text in how to construct a response to a register request is
"MAY contain a Contact header field with zero or more values"
where the right thing to do if there are no registered bindings is  
return
no Contact header field at all.

I agree that we can clarify this (but will note that I have not seen  
any interoperability problems cause by this to date).

A link to the post below is captured in the bug database at
http://bugs.sipit.net/show_bug.cgi?id=775

RjS

On Sep 11, 2008, at 6:37 AM, Iñaki Baz Castillo wrote:

> Hi, as discussed in sip-es[1] and sip-implementors[2] maillists it  
> seems that
> specification for "Contact" header in a REGISTER 200-OK in RFC 3261  
> has a
> bug:
>
>
> First of all, Contact header cannot be empty due to BNF syntax:
> ------------------
> Contact  =   ( "Contact" / "m" ) HCOLON
>                    ( STAR / (contact-param *(COMMA contact-param)))
> contact-param  =  (name-addr / addr-spec) *( SEMI contact-params)
> -----------------
>
>
> But RFC 3261 says:
> ---------------------
> 10.2 Constructing the REGISTER Request
>
>   Contact: REGISTER requests MAY contain a Contact header field with
>           zero or more values containing address bindings.
> --------------------
>
> (but a "Contact" header with no value is illegal as explained above).
>
>
> Also there is some confusion in sections 10.2.3 and 10.3:
> -----------------------
> 10.2.3 Fetching Bindings
>
>   A success response to any REGISTER request contains the complete  
> list
>   of existing bindings, regardless of whether the request contained a
>   Contact header field.  If no Contact header field is present in a
>   REGISTER request, the list of bindings is left unchanged.
>
> 10.3 Processing REGISTER Requests
>
>  The registrar returns a 200 (OK) response.  The response MUST contain
>  Contact header field values enumerating all current bindings.
> -----------------------
>
> What about if there are not registered bindings for the requested  
> AoR? Should
> the registrar return a 200 OK with no Contact header? or a 200 OK  
> with an
> empty Contact header? The second option is illegal due to BNF syntax  
> as
> explained above.
>
>
> So we see two possible solutions for this:
>
>
> 1) Change Contact BNF syntax and allow empty value:
>
> - Current syntax:
> ------------------
> Contact  =   ( "Contact" / "m" ) HCOLON
>                    ( STAR / (contact-param *(COMMA contact-param)))
> -----------------
>
> - Proposed syntax:
> ------------------
> Contact  =   ( "Contact" / "m" ) HCOLON
>                    [ ( STAR / (contact-param *(COMMA contact- 
> param))) ]
> -----------------
>
>
>
> 2) Modify some text in RFC 3261:
>
> 10.2 Constructing the REGISTER Request:
>
> - Current text:
> ---------------------
>   Contact: REGISTER requests MAY contain a Contact header field with
>           zero or more values containing address bindings.
> --------------------
>
> - Proposed text:
> ---------------------
>   Contact: REGISTER requests MAY contain a Contact header field with
>           one or more values containing address bindings.
> --------------------
>
>
> 10.2.3 Fetching Bindings:
>
> - Current text:
> ---------------------
>   A success response to any REGISTER request contains the complete  
> list
>   of existing bindings, regardless of whether the request contained a
>   Contact header field.  If no Contact header field is present in a
>   REGISTER request, the list of bindings is left unchanged.
> ---------------------
>
> - Proposed text:
> ---------------------
>   A success response to any REGISTER request contains the complete  
> list
>   of existing bindings in a Contact header if there is at least
>   one binding, regardless of whether the request contained a
>   Contact header field.  If no Contact header field is present in a
>   REGISTER request, the list of bindings is left unchanged.
> ---------------------
>
>
> 10.3 Processing REGISTER Requests:
>
> - Current text:
> ---------------------
>  The registrar returns a 200 (OK) response.  The response MUST contain
>  Contact header field values enumerating all current bindings.
> -----------------------
>
> - Proposed text:
> ---------------------
>  The registrar returns a 200 (OK) response.  The response MUST contain
>  Contact header field values enumerating all current bindings in  
> case there
>  is at least one binding. If there is no binding the response MUST NOT
>  contain a Contact header field.
> -----------------------
>
>
> Personally I prefer solution 2 since changing the BNF for Contact  
> will leave
> that header as the only header containing URI(s) allowing no value.
>
>
>
> Opinions? Thanks a lot.
>
>
>
> History-Info:
> [2]
> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-September/020311.html
> [1]
> http://groups.google.com/group/sip-es/browse_thread/thread/751255791e36bc05
>
>
>
> -- 
> Iñaki Baz Castillo
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip