RE: [Sip] Multiplicity of SIP headers

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 