Re: [reSIProcate] bug with encoding extensionHeaders on Power_Macintosh
On Wed, 2006-03-08 at 00:05 -0500, Bruce Lowekamp wrote:
> Hmm, I can probably track down why there is a difference between the
> platforms, but I'm not sure I believe it's valid. Given this BNF from
> 3261:
>
> extension-header = header-name HCOLON header-value
>
> and reading the beginning of 7.3:
>
> Specifically, any SIP
> header whose grammar is of the form
>
> header = "header-name" HCOLON header-value *(COMMA header-value)
>
> allows for combining header fields of the same name into a comma-
> separated list.
>
>
> it looks to me like extension-header's can't be COMMA separated.
I think most people take the syntax of "extension-header" as being a
place-holder, a warning to implementors that additional headers must be
parsed, if only to be ignored.
People will interpret 7.3 as applying to any additional header whose
official definition has the comma-delimited form.
Which means that if resip changes its behavior for a header based on
whether 7.3 applies, it needs to know, for every header it sees, whether
to apply 7.3 or not.
> Anyway, if it is legal syntax, then shouldn't resip be parsing them as
> separate headers so I can iterate over them properly? This is
> actually what caused me to start poking around at this. Right now my
> header reading code consists of two loops:
>
> iterate over header(h_Foos) {
> split on commas{
> process each piece
> }
> }
>
> It works fine, but it's a bit ugly.
Do you have to do this for headers defined in 3261 for which 7.3
applies, such as Contact?
Dale