Jeroen, Paul Thanks for the replies. You are right, my stack (though I wrote it) also depended on this behavior :-) Question is, if there is a situation where a certain header is required to carry some tuples of information then how should it be done?
P-Charging-Function-Addresses is a good example, I have a similar requirement. If one were to also be semantically correct then how would the BNF look like for P-Charging-Function-Address? Now I cannot have multi-valued headers because the header value is an anchor and the params hold tuples related to the anchor eg. (the header name is just a crude example) P-My-Header: Value;p=v1,v2;p=w1,w2 Here v1,v2 and w1,w2 are all related to "Value" (the anchor) and are an ordered pair amongst themselves. In fact there will be multiple headers of P-My-Header (just an example) with different "Value" I also do not need the named parameter "p" and could have had - "P-My-Header" HCOLON my-value *(SEMI tuple) my-value = Method tuple = value1 COMMA value2 value1 = token value2 = token Appreciate your help in this. Thanks On 3/20/07, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > > Jeroen van Bemmel wrote: > > see RFC3455 http://www.ietf.org/rfc/rfc3455.txt section 4.5.2.3 Examples of > > Usage message F2 (P-Charging-Function-Addresses) > > > > Not recommended though - it violates RFC3261 > > Right. There is semantic, not syntactic (its not in ABNF) requirement in > 3261 that parameters be unique. And I know of stack implementations that > depend on this. > > Paul > > > Regards, > > Jeroen > > > > > > Nap wrote: > >> Is there a precedence somewhere of a SIP header with a multivalued > >> parameter (not header). > >> > >> An example could be - > >> > >> Some-Header: Value;p1=pvalue1;p1=pvalue2;p1=pvalue3 etc [Note name of > >> param is p1 only] > >> > >> Alternatively I could think of - > >> > >> Some-Header: Value;p1=pvalue1|pvalue2|pvlaue3 with a special > >> separator like a PIPE. > >> > >> If someone has seen this kind of BNF in any draft or RFC then it will > >> immensely help. > >> > >> Thanks > >> _______________________________________________ > >> Sip-implementors mailing list > >> [email protected] > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
