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
