On Mon, 2009-02-16 at 22:28 +0100, Iñaki Baz Castillo wrote:
> Hi, Accept header allows parameters in a confusing way:
>
> -----------------------
> Accept = "Accept" HCOLON
> [ accept-range *(COMMA accept-range) ]
> accept-range = media-range *(SEMI accept-param)
> media-range = ( "*/*"
> / ( m-type SLASH "*" )
> / ( m-type SLASH m-subtype )
> ) *( SEMI m-parameter )
> accept-param = ("q" EQUAL qvalue) / generic-param
> qvalue = ( "0" [ "." 0*3DIGIT ] )
> / ( "1" [ "." 0*3("0") ] )
> generic-param = token [ EQUAL gen-value ]
> gen-value = token / host / quoted-string
>
> m-parameter = m-attribute EQUAL m-value
> m-attribute = token
> m-value = token / quoted-string
> --------------------------
>
> Take the following example:
>
> Accept: application/sdp;q=0.5;paramX=qwe
>
> Accorsing to the BNF syntax it's not possible to know if "q=0.5"
> and "paramX=qwe" are 'accept-param' or 'm-parameter' (they could be both with
> no way to differentiate between them).
This is yet another place in the BNF where what needs to be done is
determined by the parameter name. This case is more complex than usual,
in that the parameter name determines whether it is an accept-param (and
binds to media-range as part of accept-range), or an m-parameter (and
binds to "m-type SLASH m-subtype" as part of media-range.
And as you know, no ordinary parser can solve this. My choice of
implementation would be to eliminate accept-param in the parser, so all
trailing parameters are part of the media-range, and then have a
post-processor move the correct parameters from there to accept-range.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
