In -line.
-----Original Message-----
From: Jiri Kuthan [mailto:[EMAIL PROTECTED]
Sent: Monday, October 06, 2003 12:12 PM
To: Samir Srivastava; Chris Boulton; Salman Abdul Baset; Jan Janak
Cc: [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] Is "lr=on" a correct syntax for the
lr-param?
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.
SS>> Agreed.
>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
One 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.
SS>> If lr=foobar, is interpreted as loose router is working with
current
popular vendor. If another popular vendor while implementing
"loose
routing" adds "lr = on" and "lr =off" to indicate loose routing
presence. Then your current implementation will break for
"lr=off".
The liberalism you have added is gone with other. If nobody is
going
to add / having anything of this sort, then only I think it is
okay
to add the presence of lr parameter checking.
-jiri
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors