I
would love to have implementations support 'lr' as a single value parameter.
This would actually be in spec. I've just run into several implementation in the
field that just can't handle it right now. It almost seemed as if folks have
arranged to use lr=true as a standard, but did not document it
anywhere.
Thanks,
-jasson
-----Original Message-----Let me add my "me too" to this thread. While implementations may choose to be forgiving they should not be required to be forgiving.
From: M. Ranganathan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 20, 2002 7:59 AM
To: [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] lr parsing and handling
Regards
Ranga.
Vijay Kamath wrote:
Hi,
I agree with Christer. In fact, we had to change our implementation to be compliant with some proxies that were inserting ";lr=true" at the last sipit.
If we go by ABNF lr is not a name-value pair. And people just have to follow that.
Rgds... Vijay
Christer Holmberg wrote:
Hi,
Are we going to write a how-to-fix draft everytime someone implements something in a wrong way???
The ABNF in the spec says that "lr" is the correct way to go, so I think people should make sure that is the way their implementations do work.
I think it's wrong to say that "values for lr have no meaning", because if we take that path we may run into other problems in future, when people implement things in the wrong way and others will have to change their implementations to "ignore" it.
Regards,
Christer Holmberg
Ericsson Finland
Robert Sparks wrote:
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
On Mon, 2002-11-18 at 18:50, Jasson Casey wrote:
It seems that little to no devices our there support the lr tag as it applies to record-route and route. What I have seen are two things: lack of proper parsing support of a single value token in the record-route/route headers, and lack of support of lr as a function. I'm not that concerned w/ little to no support for lr just yet, proxies/ua(s) don't have to understand lr, just parse it properly. However, I have seen many bugs w/ just proper parsing. It also seems that a syntax of lr=true has been implemented to get around these problems. Should this parameter string (lr=true) be recognized as needing lr route handling? Will this parameter string get added to the sip spec?_______________________________________________
I would like to follow the general convention, but I cannot find much information on the matter.
Thanks,
-jasson
_______________________________________________
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
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
**************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ****************************************************************************************-- M. Ranganathan N.I.S.T. Advanced Networking Technologies Division 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899 Tel:301 975 3664; fax:301 590 0932 Advanced Networking Technologies for the people!
