I have two points to make (one for and one against):
1. Where do we draw the line? Under the liberal guideline, should we let anything pass?
I would say if the parser did not die but rejected the message gracefully, then the rule has been
applied. The difficulty comes in attaching semantics to the parameter values (as somebody
else pointed out).
The goal of interop should be the verification of the standard. If the standard is broken, we then
lobby to fix it. I don't think we should be bending rules motivated by interoperability.
2. If this helps any, should there be a rule that says all parameters will be in the form of
n-v pairs? Might help parsing be more generic and less context sensitive.
Regards,
Ganesh
Jiri Kuthan wrote:
At 08:46 PM 10/6/2003, Samir Srivastava wrote:I agree with Chris. The "popular soft client and Gateway" are _clearly_ violating the Standard.No doubt, they are, they break the "be conservative in what you send" principle. I'm no way happy about such implementations either.It is still no excuse for implementations breaking the "be liberal in what you receive" principle. Remember that "running code" refers to deployed code. To deploy, you need interoperability. Receiver's liberalism is a much better interoperability strategy than strict spell-checking, imho. I'm sure there are lot if historical evidences in the Internet.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 ofOne can, we do so, it works, it works even with lr=foobar, and it increases the number of UAs with which the server interoperates, which is good. We don't operate with the values -- we only operate with presence of the parameter, which is what it is all about. -jiri _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
