On October 07, 2003 6:57 AM, Jan Janak wrote:
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.
I don't get the apologists here who seemingly want to ignore the BNF when it suits
their needs. What's next? I guess we'll just allow anything for any header, or
parameter, or whatever, just because some designer for a big SIP router/phone/whatever
manufacturer can't pay attention to the spec. This is the road to chaos: "As long as
you can somehow glean the intent, it's OK".
I find nowhere in the RFC where the lr-param is defined as anything other than "lr".
The ABNF specifies "lr". Every example in the RFC uses "lr". And nowhere in the spec
does it say, well, "lr=something" is close enough. Where is "the text that specifies
it further"?
The other-param rule here is not meant to in any way "influence" the lr-param rule.
They are separate rules. It's not a hint. The other-param rule is to allow
extensibility with *new* parameters, not to generically define in some way the
existing rules. If you want the lr-param, you should be defining it as "lr" and
nothing else. If you say "lr=anything", you're now using the other-param rule, not
the lr-param rule.
Let me give you an example outside of the SIP world that I think is relevant here.
Suppose I have a piece of "C" code (something I think most of you can follow) that
looks like this:
if (a = b)
...
Now, I can read this as, the user intended this to mean "if a equals b, then do
something". Wouldn't that follow the "be liberal in what you receive" mantra? But
the specification, and thus any C parser, *will not see it that way*. It will, as any
first year C programming student knows, define a as b, and then if the value of a is
non-zero, it will do something. Because despite intent, "=" in C does not mean the
same thing as "==".
Parsers should not have to judge intent. They should be limited by *grammar*. If you
want to change the specification for the lr-param to be:
lr-param = "lr" [ "=" pvalue]
then fine, *change the specification*. But until then, you shouldn't expect to
interop with other equipment.
- rob
--
Rob Phillips, Sr. Software Engineer Netrake Corporation
mailto: [EMAIL PROTECTED] 3000 Technology Drive
voice: (214) 291-1096 Suite 100
fax: (214) 291-1010 http://www.netrake.com Plano, Texas 75074
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
