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

Re: Postel's law, exceptions


postel s law tcp
Elliotte Rusty Harold wrote:

>  
> The original statement of the law comes from section 2.10 of RFC 793 
> which can be found here:
>
> http://www.ibiblio.org/pub/docs/rfc/rfc793.txt
>
> The actual quote is:
>
>   TCP implementations will follow a general principle of robustness:  be
>   conservative in what you do, be liberal in what you accept from
>   others.
>
> Clearly at the the time Postel meant it to apply only to TCP. 

Good call.  Important in this is Reliability (p. 4)

    "The TCP must recover from data that is damaged, lost, duplicated, or
    delivered out of order by the internet communication system." 


This kind of fault tolerance was not a goal of XML.  And it is very 
important
to note that TCP only has tolerance of errors that may happen in 
passing, not errors
in the TCP as sent: if someone is sending badly formed TCP packets in the
first place, no recovery is possible: a badly formed packet will be 
treated as
damaged and therefore discarded, *not* accepted and corrected the way 
that proponents
of slack parsing have it.

To an extent, Postel's law may also be a consequence of IETF's procedures,
where an RFC is difficult to evolve or correct (a new RFC is created
instead, seems to have been the model, at least then) IIRC.  So if two 
implementers
were to interpret an RFC differently, but legitimately, Postel thought
it would have to be resoved by implementations respecting each others
variants rather than insisting on private interpretation.

Am I going to far to see another possible angle?  Postel's law also acts to
deprecate subsets: in other words, rather than mandating that you should 
be allowed
to send any old crap, it says that receivers should attempt to accept
the widest range of (legitimate) inputs even if they generate only
some minimally safe subset of outputs: e.g. have a full XML
parser rather than some subset parser, even if you only eve
generate Common XML at your output. For example page 18 has:

" There is no guarantee that senders will use this option, so
receivers must be prepared to process options even if they do
not begin on a word boundary"

This prevents one vendor from making their own subset to
the exclusion of others, while at the same time saying "but we
do TCP".

Cheers
Rick Jelliffe


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.