[EMAIL PROTECTED] wrote:
>
> JR writes:
> > Well, it will do one of two things:
> >
> > 1. its forgiving, as A is, and accepts the request
> > 2. its strict, and rejects the request
> >
> > In the case of (1), the request will succeed, and thus A did the right
> > thing by not rejecting it. In the case of (2), the end result is the
> > same as if A had rejected the request. So, by passing the requests on
> > even if they are not perfect, we improve the overall system
> > robustness,
> > since we have increased the chances of a successful request
> > at no cost.
> >
> > I think being forgiving regarding syntax (and protocol semantics, too)
> > is absolutely essential for real interoperability. The simple fact is
> > that it is humans that are, in the end, implementing these protocols,
> > with the invariable result of some amount of variability in what is
> > being done. Being forgiving wherever possible helps us handle
> > the "human factor" better.
>
> If we allow invalid SIP messages passed through, this encourages the
> existence of broken SIP implementations (no need to fix them). This would
> easily lead to H.323 like quasi-interoperability in which everything is
> allowed (just agree with Microsoft what their implementation actually
> understands so you can use Microsoft version of SIP instead of standard
> SIP).
Explain to me how implementations which are flexible to allow lots of
things leads to interoperability problems. Seems like an implementation
that is flexible will improve interoperability.
>
> For Date and other informative headers this forgiving feature might make
> sense not to verify them but where do we end ? Is SIP URL verified ? SDP m
> attribute ? Loop-detection (which is a MUST in spec) ?
The rule is simple. If you don't need it to perform your function, don't
reject it if that piece is bad. So, a proxy should probably not get so
upset about malformed Date headers, but is well within its rights to
complain about a malformed request URI or missing Call-ID.
>
> Somebody said that proxies are not supposed to be syntax police; they're
> supposed to proxy messages.
> Doesn't this mean that these kind of boxes are not SIP proxies at all,
> rather they are packet forwarders (making simple editing like adding Via
> header) ?
Don't be ridiculous. What this is saying is that proxies have some
functions to perform; these functions do not require every header in the
message. It is not the job of the proxy to verify those fields which it
is not concerned about. Only those fields a proxy needs for its
operation (which will of course vary depending on the service) need be
validated.
-Jonathan R.
--
Jonathan D. Rosenberg 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (732) 741-4778
http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244
http://www.dynamicsoft.com
