----- Original Message -----
Sent: Tuesday, October 07, 2003 12:38
PM
Subject: RE: [Sip-implementors] Is
"lr=on" a correct syntax for the lr-pa ram?
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.
[ABN]
If that
is the case, those stacks are not fully compliant with the defined rfc. In
this case how shold we handle ?????
even the ABNF syntax specifies ( not only for
lr parameter )
other-param
= pname [ "=" pvalue
]
pname
=
1*paramchar
pvalue
= 1*paramchar
here
the pvalue is optional...
If some
implementations have some problem with this basic requirement, then that lead
to problem with almost all the header which can have generic parameters.
If this
requirement has been handled properly then they could as well handle ( lr
param ) like this generic parameter..
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 -----
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 ).
Regards,
-------------------------------------------
Nataraju
A.B.
Huawei Technologies India Pvt. Ltd.,
Tel :
+91-98455-95744
-------------------------------------------
