> > > I think it a mistake to water down "deprecated". > > If you want "deprecated" to have its original strong meaning of > "SHOULD > NOT," that is fine, but we MUST be consistent about it. We need to > stop > giving people the false impression, in drafts and mailing-list > conversation, that it will be acceptable to use deprecated tags or > subtags. No, we (at least most of us) have been consistent: it is always permitted that you can use a deprecated tag or subtag. From that perspective, it is "acceptable". However, it is not and has never been recommended. I have gone out of my way to open the door to people proposing that we deprecate in the other direction, noting why I don't prefer that position. But under no circumstances would I welcome a watered down deprecation. Either deprecate or don't. > We need to stop trying to placate people in the X-Y > versus Y > debate by saying it doesn't matter much which form is deprecated, > that > the difference is only one of matching and fallback. It will be a > major difference. +1. It matters a lot which form is deprecated in terms of how one implements matching. However, the difference in "deprecation direction" is much smaller than other differences. > > How is it "just a different set of arbitrariness" if we handle all > of > the encompassed languages the same way, instead of hand-selecting a > few > macrolanguages like "zh" and treating their encompassed languages > differently from, say, the languages encompassed by "fa"? There is inherent arbitrariness in the existing set (no, sh: take a bow), plus a certain amount of instability in 639-3's handling so far. And we've had plenty of discussions of languages such as Moldovan. Ultimately, the languages that matter are the very short list John Cowan and Peter Constable bruited awhile ago. The others we have allowed in out of a (I think misguided) sense of "fair play". I support John Cowan's observation that this is strictly a backwards compatibility mechanism, for which we have a specific list of languages. > > Is everyone satisfied with this explanation of why these particular > languages were chosen? Yes, except you missed 'sgn'. > > I withdraw the radical proposal, but I hope it got us thinking a > little about some of these issues. No reason to withdraw it: it is an option. As noted, I'm okay with certain aspects of it. What we need is a sense of whether we have a consensus for something. All of these proposals ring hollow for me because they seem to be addressing inchoate fears of what someone *might* say about the proposed document, not what people have actually said. Addison _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.