> From: Vernon Schryver <vjs@xxxxxxxxxxxxxxxxxxxx> > Subject: Re: New Last Call: 'Tags for Identifying Languages' to BCP > To: ietf@xxxxxxxx > Message-ID: <200412141904.iBEJ4755037066@xxxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf