From: Vernon Schryver <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com>
Subject: Re: New Last Call: 'Tags for Identifying Languages' to BCP
To: ietf(_at_)ietf(_dot_)org
Message-ID:
<200412141904(_dot_)iBEJ4755037066(_at_)calcite(_dot_)rhyolite(_dot_)com>
Besides, I didn't say that one should ignore the English, but that
implementors give precedence to the ABNF. When you are writing an RFC
that you hope will be implemented, you MUST remember that programmers
are lazy. We transliterate the ABNF to build the parser and so
implement
the syntax and read the English to figure out and so build the
semantics.
As I said, if you must have contradictions between your ABNF and your
English, you must accept the fact that most technical people will
assume your ABNF is right and your English is wrong. That fact seemed
to me to conflict with statements in this thread, and that suggests a
problem in your working group and your RFC.
This is somewhat moot since the author has indicated the relevant
portion of the ABNF will be revised. In this case, though, the ABNF
could not be said to be in contradiction with the English prose:
anything permitted by the constraints specified in the English prose
would be recognized using the ABNF.
It is true that there are strings that could be recognized by the ABNF
that would not be permitted by the English prose, but the revision being
made to make the ABNF production in question match what Bruce Lilley
thought it should be does not change that. The only way to write the
ABNF in a way that it permits exactly no more or no less than what is
specified by the English prose would be to have the production rule
simply enumerate a specific set of terminal strings, which does not seem
to be particularly helpful, especially when the the RFC would establish
a machine-readable registry maintained by IANA in which those very
strings are enumerated.
Peter Constable
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf