On 06-10 11:46, Samir Srivastava wrote:
> I agree with Chris. The "popular soft client and Gateway" are _clearly_
> violating the
> Standard. They need to fix at their side. Instead others to make it
> interoperate with
> allowing it.
>
> Today somebody is having "lr=on|off" tommorrow somebody may
> have "lr=yes|no"
> etc... we cannot generalize on presence of "lr". One cannot expect the
> stated url-param,
> to be treated as the other-param and interoperate with their stated
> values. This kind of
> openness in accepting the params doesn't make a sense. It needs to be
> stopped at some
> place.
Frankly, I would say that you are focusing too much on the grammar
itself and don't see the text that specifies it further.
It doesn't matter if you use lr-param or other-param rule to "parse"
the parameter, the other-param rule is there to allow any parameters
with or without values. Because of that lr-param rule is nothing more
or less than a "hint" because whether or not it will be used is
implementation specific.
It is there to point out that ;lr is the preffered way, but it doesn't
prohibit using ;lr=whatever since simply another rule will be used.
If I got your last sentences right then you are saying that
other-param can't be used to "parse" lr (without value), but that's
wrong, whether or not it will be used is implementation specific.
Therefore, lr parameter is parameter that has "lr" as it's name
regardless of what non-terminal has been used.
You should do what the specification says--check for presence of lr
parameter, you shouldn't check whether lr-param or other-param
non-terminal has been used.
Openess in accepting the parameters is always good.
Jan.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
