RE: [Sip] Multiplicity of SIP headers

"Attila Sipos" <Attila.Sipos@vegastream.com> Thu, 23 November 2006 12:05 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnDKb-0006tE-Tx; Thu, 23 Nov 2006 07:05:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnDKa-0006sm-Ta for sip@ietf.org; Thu, 23 Nov 2006 07:05:28 -0500
Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnDKZ-0004nj-Kk for sip@ietf.org; Thu, 23 Nov 2006 07:05:28 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] Multiplicity of SIP headers
Date: Thu, 23 Nov 2006 12:05:26 -0000
Message-ID: <8F1F2062CA7D754A838F0E66097D23A0012A3665@veg-brk-svr-pri.vegastream>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Multiplicity of SIP headers
thread-index: AccO8/K6tmCI6NY1QH61UsLroxuH0QAATt/w
From: "Attila Sipos" <Attila.Sipos@vegastream.com>
To: "Frank Derks" <frank.derks@nec-philips.com>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1373953169=="
Errors-To: sip-bounces@ietf.org

 
Hi Frank,
 
I feel section "7.3.1 Header Field Format" is quite clear
(with the example of Route headers) about equivalence.
 
   defined in Section 7.3).  It MUST be possible to combine the multiple
   header field rows into one "field-name: field-value" pair, without
   changing the semantics of the message, by appending each subsequent
   field-value to the first, each separated by a comma.  The exceptions
   to this rule are the WWW-Authenticate, Authorization, Proxy-
   Authenticate, and Proxy-Authorization header fields.  Multiple header
   field rows with these names MAY be present in a message, but since
   their grammar does not follow the general form listed in Section 7.3,
   they MUST NOT be combined into a single header field row.
 
....   Implementations MUST be able to process multiple header field rows
....   with the same name in any combination of the single-value-per-line or
....   comma-separated value forms.

So it has to handle all of the above. 
And the dotted part (....)  is the most important.
 
>>unspecified and therefore completely dependent on twoe implementations 
>>that happen to have taken the same approach. Although there's nothing 

I feel it only requires that two implementations comply with section 7.3.1.
 
All implementations need the flexibility to be able to handle the
multiple header-values in combination with multiple sip headers
(of the same type).  If they don't, they don't comply.
 
Regards,
Attila
 
 

-----Original Message-----
From: Frank Derks [mailto:frank.derks@nec-philips.com]
Sent: 23 November 2006 11:39
To: Attila Sipos
Cc: IETF SIP List
Subject: RE: [Sip] Multiplicity of SIP headers



Hi Atilla. 

I agree that common sense should prevail when implementing this sort of thing, 
but it would also be useful to specify things in an exact manner to prevent 
problems. 

As an example, you mention the Contact header as being one of those headers 
that could be present more than once. The specified way provide multiple 
Contact addresses is through a comma-separated list of addresses in one 
Contact header. The theoretical alternative could indeed be to provide 
multiple Contact headers, each with one Contact address, but this is 
unspecified and therefore completely dependent on twoe implementations 
that happen to have taken the same approach. Although there's nothing 
fundamentally wrong with multiple ways in which the same can be achieved, 
this should be specified and if possible avoided. 

Cheers, 

Frank 












"Attila Sipos" <Attila.Sipos@vegastream.com> 


2006-11-23 12:22 PM 


To
"Frank Derks" <frank.derks@nec-philips.com>
"IETF SIP List" <sip@ietf.org> 

cc

Subject
RE: [Sip] Multiplicity of SIP headers 

Classification

	




  
In terms of pure grammar, headers can appear any number of times. 
  
In practice, it only makes sense for some headers to appear 
multiple times (e.g. Route, Record-Route, Contact). 
And for some headers, an appearance of more than once 
has no use (well, not at the moment) (e.g. To and From). 
  
Regards, 
  
Attila 
  
  
-----Original Message-----
From: Frank Derks [mailto:frank.derks@nec-philips.com]
Sent: 23 November 2006 10:38
To: IETF SIP List
Subject: [Sip] Multiplicity of SIP headers
Importance: High


All, 

It seems that RFC 3261 does not say anything about the number of times that a 
header is allowed to apear in a request or response. The ABNF states: 

Request        =  Request-Line 
                 *( message-header ) 
                 CRLF 
                 [ message-body ] 

message-header  =  (Accept 
               /  Accept-Encoding 
                       : 
                       : 
               /  Accept-Language 
               /  extension-header) CRLF 

Which means that any header can appear any number of times. The text of the RFC 
does not seem to modify this in any way. So what does this mean? Is it indeed 
the case that a header may appear any number of times? 

Cheers, 

Frank 


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