Re: Possible bug in REGISTER 200-OK Contact specification

Robert Sparks <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <[email protected]>
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 [email protected] for questions on current sip
> Use [email protected] 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 [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.