Hi Martin, thank you for the quick response. I gather your reply means that we can go ahead with the pull request [1] as proposed now. [1]: https://github.com/core-wg/core-problem-details/pull/40 So the following points are just for potential future documents in this space: > Well, you actually didn't just make a copy. You replaced a production name ('grandfathered' -> 'legacy’), Yes. Time marches on… (No semantic change.) > you removed the comments from the 'irregular' and 'regular' productions to make them take less space, (No semantic change.) > and you added productions for ALPHA and DIGIT. Of course; the ABNF is incomplete without these snippets from RFC 5234, so this was a required addition. (No change from the semantics as I would expect they were intended — the import is only implied in RFC 5646.) > I don't think you introduced any errors, but it's changes like these that may start a slippery slope or introduce subtle errors. Indeed; getting these changes/additions (if required, as with ALPHA/DIGIT) right is likely to be one interesting job for the RFC-referencing mechanism in CDDL 2.0. >> What got us to now propose blunting that grammar is the strong impression that there may be less consensus about the grammar defined by RFC 5646 than we thought. So it seems the grammar in RFC 5646 is fragile, not the act of copying it out... > > There's a wide gap between "fragile" and "not set in stone". The grammar in RFC 5646 is not set in stone, but to call it "fragile" is overstating the issue. In other specifications, we often distinguish a “framework” grammar from a “validation” grammar, where the first one is the total envelope for extensions, and the second one has the current structure (so that one doesn’t accidentally include extensions). PR #40 is essentially switching from a validation to a framework grammar (which we steal from the XML spec, as suggested). [The validation grammar is enshrined in -06, which can be dug out by implementers or if we ever want to use it in another document.] CDDL also is able to do both functions within the same grammar (using RFC 9165 “.feature”), but the somewhat anaphylactic reaction to using the RFC 5646 ABNF indicated to me that this wasn’t the direction we wanted to take here. > But what's important is that technologies, in the IETF as well as elsewhere, should only be linked as strongly as needed, not more strongly. That way, technology can evolve more independently and freely, with less needs for implementation or specification changes. That is easier to do if the referenced specification indicates which parts of it are intended to be malleable (and which are “invariants”, as in RFC 8999). I read RFC 5646 as exposing a clear set of extension points so there would not be a need to change the grammar, but I have now learned to read this differently. > [One of the main places where the I18N community learned this was that in the mid 1990es, at one point everybody was very happy to get certain specs (e.g. HTML) to cite Unicode. But when a year later Unicode was updated, we started to get questions about whether the spec in question also could be used with the newly added characters. The answer should have been "yes, of course", but the specs were not written that way. After hashing things out, Unicode now provides reference examples for both versioned and versionless references (see https://www.unicode.org/versions/index.html#References).] Definitely a problem that we have with every single normative reference to a document that still has life in it… >> https://github.com/core-wg/core-problem-details/pull/40/commits/bbe72e2 >> (I’m making a point about copying here as I believe copying out snippets of CDDL from RFCs and other specifications will be a significant part of CDDL 2.0.) > > I don't know enough about CDDL to be able to say whether that is a good thing or not. It’s intended to be a good thing, but it is nonetheless hard to get right (see one example above). Thank you again for your input! Grüße, Carsten -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
