On Sun, 2017-06-18 at 10:25 +0200, Petr Špaček wrote: > > On 17.6.2017 16:26, Paul Wouters wrote: > > On Jun 17, 2017, at 10:18, Petr Špaček <petr.spacek@xxxxxx> wrote: > >> > >> > >> This is exactly the point where our opinions differ. > >> My point of view is that specification should clearly define extension > >> points and implementations should: > >> a) Use Postel's principle within defined 'extension' points. > >> b) Treat any deviation from documented protocol (including non-defined > >> aspects of protocol outside of extension points) as an error. > > > > So abort all your HTML pages from loading? > > > > b) is an error that should be handled in a Postel way and the RFC should > > be updated to address the issue. Then maybe years down the line you can be more strict on the failure. > > Please let me clarify that can be reasonably applies only to new > protocols or new extensions of existing protocols. We do not have time > machine and I'm not proposing to break existing deployments... > 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. In fact being liberal in what you accept is a necessity for implementations and any guidance we give to break the connection will be ignored. Best we can do is to make both the sending and processing of protocol messages clearly defined in our specs. So for example we should not say "The Certificate Data field contains an X.509 certificate", but should instead say "The Certificate Data field contains a DER-encoded X.509 certificate conforming to RFC 5280. The receiver MUST verify that the content is valid DER and that all required fields are present." This won't eliminate market forces, but at least it can reduce the cases where different implementers interpreted the specification in a different way. Yoav