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(_dot_)spacek(_at_)nic(_dot_)cz> 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