[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Postel's Law Has No Exceptions


postel liberal accept
> From: Joshua Allen [mailto:joshuaa@m...]
> Sent: Wednesday, August 20, 2003 7:11 PM
> To: Julian Reschke; Simon St.Laurent; xml-dev@l...
> Subject: RE:  Postel's Law Has No Exceptions
>
>
> > Speaking from server implementation experience: just because one
> popular
> > server chose to be "liberal" (in that case, non-compliant),
> implementors
> > competing servers are now forced to implement that buggy behaviour as
>
> That case (assuming you mean WebDAV servers) is not an example of
> "liberal in what you accept".  If the servers in question are so
> liberal, why do they not accept perfectly wellformed input from other
> clients?  If they are conservative in sending, why do they produce
> non-wellformed XML?  Certain WebDAV servers seem like a perfect example
> of blatant disregard for Postel's law to me.

The issue is different. If server A (sold by a big company and widely
deployed) accepts broken requests, clients may start relying on that
behaviour. Other, smaller vendors thereby have the choice of either
implementing to the spec (rejecting the broken requests) or emulating the
broken server behaviour.

My point being, unless *everybody* is accepting the same kind of broken
requests, interoperability will actually be *worse*. But if indeed everybody
*is* accepting the same requests, it would have made more sense to actually
define this as *correct* behaviour and have draconian error checking.

> There is a difference between gracefully recovering from recoverable
> input errors and *requiring* input errors as a condition of functioning.

Yes, and as far as I can tell "recovering gracefully" is actually harmful
unless the sender is signalled that the request indeed was broken.

I think often people do not realize that the robustness principle doesn't
necessarily mean "accept as many broken requests you can", but just "expect
broken requests, and handle them in a sane way". Depending on the protocol,
the "sane way" may well be to reject the request:

         Software should be written to deal with every conceivable
         error, no matter how unlikely; sooner or later a packet will
         come in with that particular combination of errors and
         attributes, and unless the software is prepared, chaos can
         ensue.  In general, it is best to assume that the network is
         filled with malevolent entities that will send in packets
         designed to have the worst possible effect.  This assumption
         will lead to suitable protective design, although the most
         serious problems in the Internet have been caused by
         unenvisaged mechanisms triggered by low-probability events;
         mere human malice would never have taken so devious a course!

         Adaptability to change must be designed into all levels of
         Internet host software.  As a simple example, consider a
         protocol specification that contains an enumeration of values
         for a particular header field -- e.g., a type field, a port
         number, or an error code; this enumeration must be assumed to
         be incomplete.  Thus, if a protocol specification defines four
         possible error codes, the software must not break when a fifth
         code shows up.  An undefined code might be logged (see below),
         but it must not cause a failure.



Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.