Brett,
Thanks for this. I should have checked 2543. (Its been a long time since
I looked at it!!!) It explains a lot.
Thanks,
Paul
On 4/4/12 10:27 AM, Brett Tate wrote:
> For those unaware of the #rule which is used by RFC 5806...
>
> Draft-levy-sip-diversion was originally based upon RFC 2543 (or
> draft-ietf-sip-rfc2543bis-00). The BNF was unintentionally never correctly
> updated to comply with RFC 4485 and RFC 3261.
>
> The following are RFC 2543 snippets concerning #rule and comma-separated
> lists.
>
> Section 6.6:
>
> "Multiple header fields with the same field-name may be present in a message
> if and only if the entire field-value for that header field is defined as a
> comma-separated list (i.e., #(values)). It MUST be possible to combine the
> multiple header fields 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."
>
>
> Section C:
>
> #rule
>
>
> A construct "#" is defined, similar to "*", for defining lists of
> elements. The full form is "<n>#<m> element" indicating at least<n>
> and at most<m> elements, each separated by one or more commas (",")
> and OPTIONAL linear white space (LWS). This makes the usual form of
> lists very easy; a rule such as
>
>
>
> ( *LWS element *( *LWS "," *LWS element ))
>
>
> can be shown as 1# element. Wherever this construct is used, null
> elements are allowed, but do not contribute to the count of elements
> present. That is, "(element), , (element)" is permitted, but counts
> as only two elements. Therefore, where at least one element is
> required, at least one non-null element MUST be present. Default
> values are 0 and infinity so that "#element" allows any number,
> including zero; "1#element" requires at least one; and "1#2element"
> allows one or two.
>
>
>
> This email is intended solely for the person or entity to which it is
> addressed and may contain confidential and/or privileged information. If you
> are not the intended recipient and have received this email in error, please
> notify BroadSoft, Inc. immediately by replying to this message, or by sending
> an email to [email protected], and destroy all copies of this message,
> along with any attachment, prior to reading, distributing or copying it.
>
> _______________________________________________
> 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
