On Jun 18, 2017, at 12:55, Yoav Nir <ynir.ietf@xxxxxxxxx> wrote: > > I don't think both Netscape and Microsoft wrote their browsers so that > they accepted very malformed HTML just because Postel said so. They > figured (probably correctly) that users would prefer a browser that > worked with all websites to a browser that worked with many websites. Indeed, dumping the error messages on the human user would have been nonsensical. Now assume for a second that HTTP had had a backchannel that would have allowed a browser to send error messages back to the server. Of course, we don’t know whether browser implementer would have provided meaningful messages, and we don’t know whether server implementers would have collected them in a useful way. And, of course, we also don’t know whether site authors would have had a look at these collected error messages. Still, I think that this approach would have resulted in less soupifying of HTML than what actually happened. What can we learn from this thought experiment? When designing protocols, we can’t sustain the fiction that implementations will be compliant. Instead, we have to think about what to do with the non-compliance that we’ll encounter. And we have to think about ways that information about this can flow to a place where it can be acted upon. (Or, preferably, where there actually are forces that make it likely that it *will* be acted upon.) (Other points from the current discussion playing into this are: — be *definite* in what you accept — I think we are getting better at that; and — clearly identify (and envelope!) extension points — still much work needed. There was also a good discussion in the past that extension points need to be regularly exercised, or there will be problems at the time when they are actually needed.) Grüße, Carsten