Subject: [sipcore] Multiple parameter instance in a SIP header (RFC 3261 and 3455)

From: "Ofer Goren" <[email-masked]>
Date: Wed, 18 Nov 2009 17:29:03 +0200

Hi.

I came across an ambiguity between to SIP-related RFC.

In 3261 RFC, section 7.3.1, the following is stated: "Even though an
arbitrary number of parameter pairs may be attached to

   a header field value, any given parameter-name MUST NOT appear more
than once."

However, in RFC 3455, section 4.5.2.3, there is an example saying that
the ccf and ecf parameters can appear twice:

      F2 Invite P1 -> P2

         INVITE sip:[email-masked] SIP/2.0

         Via: SIP/2.0/UDP p1.home1.net:5060;branch=z9hG4bK34ghi7ab04

         Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7

         To: sip:[email-masked]

         From: sip:ua1home1.net;tag=456248

         Call-ID: 843817637684230998sdasdh09

         CSeq: 18 INVITE

         Contact: sip:[email-masked]

         P-Charging-Function-Addresses: ccf=192.1.1.1; ccf=192.1.1.2;
ecf=192.1.1.3; ecf=192.1.1.4

My question is if this example in 3455 is indeed valid, or that the
restriction mentioned in 3261 is still valid.

Thanks,

Ofer.

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Nov 2009 11:21:51 -0600

On Nov 18, 2009, at 9:29 AM, Ofer Goren wrote:

> In 3261 RFC, section 7.3.1, the following is stated: “Even though an  
>    a header field value, any given parameter-name MUST NOT appear  
> more  than once.”
>
> However, in RFC 3455, section 4.5.2.3, there is an example saying  
> that the ccf and ecf parameters can appear twice:
>       F2 Invite P1 -> P2
>          P-Charging-Function-Addresses: ccf=192.1.1.1;  
> ccf=192.1.1.2; ecf=192.1.1.3; ecf=192.1.1.4
>
>

I believe 3455 is inconsistent with 3261. It's what we get for not  
taking those P-headers seriously enough during review.

As I understand it, the reason behind non-recurring parameter names in  
RFC 3261 is that there's no guarantee that parameters will not be  
reordered by intermediaries, so unique naming rather than positional  
indexing is required for most applications. In practice, this  
reordering seldom (never?) happens. Also, I don't believe that RFC  
3455 cares about the parameter ordering, so it wouldn't be affected by  
this. However, strictly 3261-compliant parsers are likely to choke on  
the example in 3455, as they might parse parameter/value pairs into a  
hash map keyed by the parameter name.

Question for the room: Is there any real reason to keep the  
requirement for parameter-name non-recurrence within a header field  
value as specified in RFC 3261 7.3.1, or should we relax this  
requirement and perhaps add an errata statement to RFC 3261 doing so?

Or should we errata-note the error in RFC 3455?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Nov 2009 13:35:49 -0500

Dean Willis wrote:

> Question for the room: Is there any real reason to keep the requirement 
> for parameter-name non-recurrence within a header field value as 
> specified in RFC 3261 7.3.1, or should we relax this requirement and 
> perhaps add an errata statement to RFC 3261 doing so?
> 

I know of at least one implementation that would consider this a major 
incompatible change, difficult to fix, because the parameters are kept 
in a hash table, with no provision for duplicates.

We should errata 3455.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Nov 2009 14:52:04 -0600

On Nov 18, 2009, at 12:35 PM, Paul Kyzivat wrote:

> I know of at least one implementation that would consider this a  
> major incompatible change, difficult to fix, because the parameters  
> are kept in a hash table, with no provision for duplicates.

I'm willing to believe that; if I were writing a stack in Perl or  
Java, that's how I'd build it too.

> We should errata 3455.

If we go that route, we should probably also generate an LS to 3GPP  
informing them of the problem and asking them to suggest a fix, since  
they're the main consumers of 3455 if I understand the situation. I  
suggest that once our chair has determined consensus on this question  
that he might wish to call for a volunteer to do the LS.

--
Dean

---

From: Jeroen van Bemmel <[email-masked]>
Date: Thu, 19 Nov 2009 00:44:35 +0100

Some work on this was already done, see 
http://au.net/ietf/idref/draft-drage-sipping-rfc3455bis/

I remember some discussions on the issue of duplicate parameter names, 
perhaps Keith knows what happened with those

Regards,
Jeroen

Dean Willis wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Ofer Goren" <[email-masked]>
Date: Thu, 19 Nov 2009 13:40:27 +0200

Dean.
My question arise from a section I read in some 3GPP specification, 24229-800, regarding the P-Charging-Vector.
In section 5.3.2.1, it is stated that:
"The I-CSCF shall add a type 3 orig-ioi parameter before the received orig-ioi parameter. The I-CSCF shall set the type 3 orig-ioi parameter to a value that identifies the sending network of the request. The I-CSCF shall not include the type 3 term-ioi parameter".
 
This implies that at least 2 instances of orig-ioi prameter should be part of this header. In another section, the same is implied regarding term-ioi. So, looking for some clarifications in the RFCs, I came across RFC 3455.
So it looks like the 3GPP specifications are less strict regarding the 3261 limitation. Or am I mistaken?
 
Thanks,
Ofer

________________________________

[email-masked] on behalf of Dean Willis
Sent: Wed 11/18/2009 22:52
To: Paul Kyzivat
Cc: Ofer Goren; SIPCORE; [email-masked]
Subject: Re: [sipcore] Multiple parameter instance in a SIP header (RFC 3261and 3455)

---

From: Dean Willis <[email-masked]>
Date: Thu, 19 Nov 2009 22:26:11 -0600

On Nov 19, 2009, at 5:40 AM, Ofer Goren wrote:

> Dean.
> My question arise from a section I read in some 3GPP specification,  
> 24229-800, regarding the P-Charging-Vector.
> “The I-CSCF shall add a type 3 orig-ioi parameter before the  
> received orig-ioi parameter. The I-CSCF shall set the type 3 orig- 
> ioi parameter to a value that identifies the sending network of the  
> request. The I-CSCF shall not include the type 3 term-ioi parameter”.
>
> This implies that at least 2 instances of orig-ioi prameter should  
> be part of this header. In another section, the same is implied  
> regarding term-ioi. So, looking for some clarifications in the RFCs,  
> I came across RFC 3455.

I believe you are correct. On further reflection, I also believe that  
the 3GPP specification would "fail hard" with at least one of the  
commercial SIP stacks with which I have a passing familiarity, due to  
this conflict with MUST level requirements in RFC 3261.

My opinion is that we need to work with 3GPP to get this bug in RFC  
3455/24.229 fixed. Or we need to revise RFC 3261 and throw out all  
those old SIP Stacks. But given that there are several billion euros  
worth of product in circulation built on those stacks, I'm guessing  
we're going to get a lot of push-back on this approach. It's probably  
easier to fix RFC 3455 to have one instance of each parameter type  
with multiple values associated with each parameter (that is, make the  
value according to RFC 3261 sytax into a list of values).

--
Dean

---

From: <[email-masked]>
Date: Mon, 23 Nov 2009 09:01:58 +0100

Hi,

some solution to multiple header issue is indeed needed. 

I think Keith has been working in this area and he is also the rapporteur of 24.229, so his comment would be appreciated, please?

BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724

>-----Original Message-----
>From: ext Dean Willis [mailto:[email-masked]] 
>Sent: 20 November, 2009 06:26
>To: Ofer Goren
>Cc: Paul Kyzivat; SIPCORE; Hietalahti Hannu (Nokia-CIC/Oulu)
>> "The I-CSCF shall add a type 3 orig-ioi parameter before the  
>> request. The I-CSCF shall not include the type 3 term-ioi parameter".
>>