"Barry (work)" writes:
>> >As a general point, about the need for parsers to be forgiving - there is
>an
>> >argument that 'over-aggressive' parsers are useful because they prevent
>> >unpredictable and potentially serious operational problems
>> >from arising in a complex interworking environment.
>>
>> I'm not sure I agree. Can you give an example of the concern you
>> beleive you're addressing?
>>
>
>Let's say a forgiving parser in system A passes some crud on to another
>system B. A has no knowledge of how B will react to anything that is
>outside the spec. Nor does A know, for example, whether or not the systems
>are in a safety-critical situation. The only reasonable assumption A should
>make about B is that B is responsible for performing correctly within the
>spec. i.e. that given correct input, B should behave correctly, and that
>given incorrect input, B will behave unpredictably.
Presumably, you're talking about a scenario like:
UAC -----> A (proxy) -----> B (UAS)
And it sounds like your intention is to use the proxy A as some
sort of protocol police. That seems like a reasonable thing to
do in very particular safety-criticial setups. It is,
however, **extremely** special purpose, and not suitable
behavior for a proxy in general.
Take note that over-agressive parsing on the part of node A,
however, may (and probably will) lead to interoperability
problems under the circumstances that the UAC and node B (the UAS)
are using an extension that, in theory, the proxy doesn't
need to know about. For example, I saw proxies at the bakeoff
that would reject requests if the To: line was a tel: URL, even
though the Request-URI was a sip: URL. The consequence was
that I couldn't even call my own (tel: aware) client with
itself through these proxies.
THIS IS BROKEN BEHAVIOR.
By making these proxies more restrictive than necessary, you
are introducing intentional interoperability problems into
the network. This is not an ITU protocol; we don't do that
sort of thing on purpose. The philosophy of the IETF protocols
has, for a long time, been: "be strict in what you generate,
but forgiving in what you accept." The beauty of this is that,
in most cases, you need *two* broken implementations for things
not to work.
And our goal here is to get things to work.
--
Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[EMAIL PROTECTED] | Fax: +1 972 669 0154 | Richardson, TX 75081 USA
