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
