RE: [Sip-implementors] Is "lr=on" a correct syntax for the lr-pa ram?

[Attila Sipos]

It seems to me that the "lr" problems came in because parsers were written which expected all uri parameters to be in the form "something=something_else". Then when "lr" was added, the easiest thing was to just use lr=something.   People talk about old and new implementations but the fact is that in any SIP RFC or draft "lr" always has been just "lr", even in RFC2543bis-07 where lr was first introduced.   As some people have said, the implementations that use "lr=something" should really be fixed because this use is not defined in the SIP RFC.   Anyway, here's an e-mail sent by Robert Sparks (one of the SIP RFC authors) on this subject.  It shows how "lr" should be handled to aid interoperability but it also says that we should start "weeding it out":   > -----Original Message----- > From: Robert Sparks [mailto:[EMAIL PROTECTED] > Sent: 19 November 2002 19:41 > To: Jasson Casey > Cc: [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] lr parsing and handling > > > I have seen _many_ correct implementations of route handling > using the ;lr parameter at the last two SIPits. The vast majority of > proxies and endpoints participating in the multiparty tests > were getting > this right. > > Values for ;lr currently have _no standard meaning_ and should > simply be ignored. > > The following are equivalent and mean that the element providing the > URI supports loose routing: > ;lr > ;lr=true > ;lr=false > ;lr=arbitrarybits > > It is the presence of the parameter that makes the difference. Its > value is irrelevant. Yes, the ;lr=false case is counter-intuitive. > > ;lr=true will not be added to the specification. Those who introduced > it into our milieu are fixing the errors that generated it. I will be > working hard (and I hope the rest of you will be working with me) to > make it go away as soon as we can. > > I plan to publish a draft soon documenting how to best deal with > encountering ;lr=true and the issues that led to it in hopes of > making weeding it out easier. > > RjS >     -----Original Message----- From: Nataraju A.B. [mailto:[EMAIL PROTECTED] Sent: 07 October 2003 04:52 To: Jiri Kuthan; Ganesh Jayadevan Cc: Chris Boulton; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Is "lr=on" a correct syntax for the lr-param? ----- Original Message ----- From: Jiri Kuthan To: Ganesh Jayadevan Cc: Chris Boulton ; [EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 1:56 AM Subject: Re: [Sip-implementors] Is "lr=on" a correct syntax for the lr-param? At 09:31 PM 10/6/2003, Ganesh Jayadevan wrote: >Jiri, > >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). I didn't ask for value processing. With RR, I suggested parameter-presence test for lr. >   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. If we rebuilt SIP, I would advocate less syntactical choices for a single thing -- no doubt they make parser more complex -> more error-prone and slower. However, with amount of SIP deployed today, reformulating the syntax would quite likely cause more headache than benefits. [ABN] At some point of time the earlier implementations did some mistake ( unknowingly ). to handle those mistakes we need to make the new implementations to be so generic may not a good idea.  there should be some point of deviation to be tolerated, beyond which we can't make handle only those bugs to be fixed in the earlier implementations.     Yes, I do agree with the idea of robustness & to be interoperable with old versions. but if we find that understanding itself was wrong then at some point of time it must be fixed. we just can't handle this problem by just making the new implementations to handle the old discrepancies also.   This might lead to major problem in maintaining the system at later point of time ( because of various deviations from normal syntax ).   -jiri _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors   Regards, ------------------------------------------- Nataraju A.B. Huawei Technologies India Pvt. Ltd., Tel : +91-98455-95744 -------------------------------------------

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors