Re: [arch-d] deprecating Postel's principle- considered harmful

[Henning Schulzrinne <[e-mail]>]

One could argue that the Microsoft abandonment of IE and the now-oligopoly
of Chrome, Firefox and Safari is a consequence of that design choice. In
general, for complex protocols, we seem to "converge" to two or three
implementations, with two rolling up 80% of market, the third at maybe
10-15% and everybody else below that (and much of that remainder is usually
legacy, i.e., code no longer under active development). Postfix and
sendmail, bind and ?, httpd and nginx, etc.

The major difference for HTML was that a lot of content is still
hand-edited; telnet for SMTP is probably less common.

Henning

On Wed, May 8, 2019 at 12:17 PM Henry S. Thompson <[e-mail]> wrote:

> Paul Wouters writes:
>
> > ...
> > The problem is not the Postel principle. The problem is that we have "too
> > big to fail" implementations
>
> A historical example may illustrate how high the (organisational) stakes
> can be.
>
> The W3C lost control of HTML as a result of a decision, late in the last
> century, to commit to XML as the basis for the successor of HTML4 (for
> the W3C's own account of this, see [1]).
>
> The 'too big to fail' implementations in this case were initially those
> of Apple, Mozilla, and Opera, with Google joining in a bit later.
> Different aspects of XHTML2 (the proposed XML-based successor to HTML
> 4.01 and XHTML1.0) were problems for different constituencies and to
> different degrees, but what its opponents regularly cited as XML's
> insistence on a "halt and catch fire" approach to ill-formed documents
> was the one that was argued with perhaps the most bitterness.
>
> Postel's 'law' was regularly invoked in arguments against the XML
> approach, and it lives on in the current version of what is now called
> the "Living Standard" of HTML5, as published by the W3C, where we find,
> _inter alia_, in the section entitled *Conformance requirements for
> authors":
>
>   "Unlike previous versions of the HTML specification, this
>    specification defines in some detail the required processing for
>    invalid documents as well as valid documents." [2]
>
> One way of understanding the dynamic behind the transfer of effective
> ownership of HTML from the W3C to the WHATWG (a quasi-consortium of
> Apple, Mozilla, Opera and Google) is as a replay of (the mythology of)
> the foundation of the W3C itself, namely, that back in 1988 Microsoft
> and Netscape needed a way of managing HTML development that didn't
> violate the anti-trust rules.  In the early part of this century, a
> major part of browser interop problems lay in the area of error
> recovery.  The W3C's XML-based approach was intended to solve this by
> "cleaning up the Web":  XHTML2, by being XML, would require strict
> enforcement of well-formedness and encourage strict enforcement of
> validity.
>
> The browser vendors, in contrast, were terrified of the cost of
> increased support calls they predicted would arise, and preferred a
> solution sometimes described using the phrase "paving the cow paths",
> that is, standardising error recovery.  [see below at **]
>
> The result is a 1069-page-long standard with no BNF or any other form of
> concise grammar.  There are 11 pages of prose describing the low-level
> 'syntax' (angle-brackets and equal signs), and 100 pages of prose
> describing the generic parsing _process_, including, of course, error
> recovery. And there are just under 500 pages of prose describing, for
> every allowed element, how to process its serialisation in detail,
> including error recovery.
>
> Would we have been better off with XHTML2?  Not in the short term, I
> don't think.  But by now?  How can we know?  But, as Berners-Lee is fond
> of saying, "The future is longer than the past"...  We will keep paying
> the cost of the lack of incentives to clean up the Web for a long time...
>
> ht
>
> [1] https://www.w3.org/TR/html5/introduction.html#introduction-history
> [2]
> https://www.w3.org/TR/html5/introduction.html#conformance-requirements-for-authors
>
> ** John Klensin's recent post arrived after I had written this.  I think
> his description of "the first option" is perfectly borne out by what
> I've described above:
>
> > -- trying to specify every possible detail so that an
> > implementer knows what to do in every case and for every design
> > choice, including what is supposed to be done about each variety
> > of deviation from the standard by others.
>
> > ...
>
> > We know a few things about [this option].  It causes the standards
> > development process to take much longer than [the alternative].
> > Because standards designers are not infallible, it is prone to errors,
> > errors that could make the standard completely unworkable.  For [HTML,
> > it was only possible because] there are complete and deployed
> > implementations around that [could] be examined and analyzed ... in
> > combination, in [building] the standards.
> --
>        Henry S. Thompson, School of Informatics, University of Edinburgh
>       10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
>                 Fax: [phone], e-mail: [e-mail]
>                        URL: http://www.ltg.ed.ac.uk/~ht/
>  [mail from me _always_ has a .sig like this -- mail without it is forged
> spam]
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>