[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Postel's law, exceptions
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|