Re: [sipcore] draft-barnes-sipcore-rfc4244bis

["Dale Worley" <[e-mail]>]

On Thu, 2009-07-02 at 14:39 -0400, Paul Kyzivat wrote:
> OTOH, this is a revision to an existing RFC which had that ordering 
> requirement. Its possible that relaxing it might lead to interop problems.

Actually, I don't think that RFC 4244 has an ordering requirement.  Look
at the BNF in section 4.1:

          History-Info = "History-Info" HCOLON
                            hi-entry *(COMMA hi-entry)

          hi-entry = hi-targeted-to-uri *( SEMI hi-param )

          hi-targeted-to-uri= name-addr

          hi-param = hi-index / hi-extension

          hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)

          hi-extension = generic-param

> Regarding indicating that the index is required: it can be done in text, 
> but it can also be done in the BNF, as follows:
> 
>     History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
> 
>     hi-entry = hi-targeted-to-uri hi-param-list
> 
>     hi-targeted-to-uri = name-addr
> 
>     hi-param-list = *(SEMI hi-option) SEMI hi-index *(hi-option)
> 
>     hi-option = hi-target / hi-aor / hi-extension
> 
>     hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT)
> 
>     hi-target = "rc" / "cc" / "mp" / "rt"
> 
>     hi-aor = "aor"
> 
>     hi-extension = generic-param

IMHO, though that is possible, it is not a good idea.  In general,
implementations do not enforce such restrictions in the parser even when
it is possible to do so, so such BNF doesn't correspond closely to the
implementation.  And BNF like this is more complex, making it easier to
make errors in both the BNF and its implementation.  (E.g., the above
rule for "hi-param-list" is missing an instance of "SEMI".)

Dale