Vernon opined:
---
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.
---
I agree with your observations about programmers and their tendencies. I
think we agreed to modify the ABNF slightly (to make the grandfathered
production cleaner) as a result. In fact, I'd go further: the draft
*explicitly identifies* that such implementations will exist (Section 2.2.3
"Classes of Conformance"). Some care was taken so that ABNF-only
implementations (which the authors take to include many extant RFC 3066
implementations) would not be broken by any sort of draft-langtags
implementations, including future extensions, and to ensure that "junk" tags
emitted by these implementations don't cause problems for more capable
implementations.
Actually, this isn't any different than the case with RFC 3066 today, where
implementations must assume that junk tags are just registrations that they
don't recognize. By altering the "grandfathered" production in the ABNF we
ensure exact parity for everyone, since the general case is that production.
Best Regards,
Addison
Addison P. Phillips
Director, Globalization Architecture
http://www.webMethods.com
Chair, W3C Internationalization Working Group
http://www.w3.org/International
Internationalization is an architecture.
It is not a feature.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf