[
Lists Home |
Date Index |
Thread Index
]
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
|
