> Well, for #2, we have started to consider cherry picking (at least, > I've had that impression), and the reasons for considering it > applied just the same to #1 -- we just didn't get to a point while > #1 was on the table of actually considering it. But this isn't a > point worth debating. Actually, we considered and rejected it for #1, IIRC. Then some attempts were made at a compromise that used cherry-picking. Given all that, I don't see why #3 doesn't potentially lead to cherry-picking too. The picking of cherries is orthogonal to the solution chosen. > > Again, I thought that we were cherry picking in which cases the > extlang form was even considered valid (IOW, cherry picking the > macrolanguages): zh, ar, sgn and a few others. Well, yes. Unless we don't. > > in ways that are incompatible with our previous > > tenets. > > Haven't groked that yet. (I just thought of all this and wrote it > up immediately for feedback.) I had in mind, in particular, that our current matching schemes require only the tags/ranges themselves, without any a priori information, in order to function. Canonicalization (a separate process) helps and is recommended here (but not required) because strict subtag matching can't deal with tag/subtag replacement (deprecation). Not requiring the registry is, to my mind, a fundamental tenet of matching as it sits today. > > A possible concern is that "Preferred-Value" is not only used in > canonicalization *for matching purposes*, but it is also what > people SHOULD be using to tag all their content and interchange: as > the opening sentence of 4.5 says, > I agree that this applies. But I think it is important that we establish a general trend in tag choice. Multiple choices in language tags are bad news. > > So, indeed, the means we have for supporting canonicalization in > the registry is also how we handle deprecation, and so we currently > have to deprecate either X-Y or Y to handle these in > canonicalization. Just as you say. The concern is that we are also > saying that only one or the other SHOULD be used in interchange and > in tagging content. I'm concerned that might lead to the very same > barrier to consensus that we had for #1: some think > content/interchange should use (say) "cmn" while others would like > to see "zh-cmn". We do have a long-ish section about extlangs in the section on tag choice to address this concern. We do say to use the canonical form and it *is* preferred and there are good reasons for us to prefer one form or another. However, the reason this compromise has any chance is that it allows people to disagree and still interoperate. > > I guess what I'm really suggesting for #3 is that we still have the > effects of canonicalization used in matching without saying that > the canonical form (just wrt extlang -- X-Y vs. Y) is what SHOULD > always be generated. Again, we can spell out the reasons one might choose to ignore the SHOULD in the section on tag choice. > I'm not making myself clear: whereas currently, we have (IIUC) > cherry picked only certain macrolanguages and sgn as potential > prefixes for extlang, I was suggesting for #3 that LTRU doesn't > need to make those choices up front, that the RFC can specify *any* > macrolanguage (or sgn) can be a prefix for extlang, and then it can > be left to IETF-Languages to decide (perhaps differently for > different cases) whether X-Y or Y is better in general (i.e. for > most applications) / preferred for purposes of tagging and > interchange. (We'd still want something that specifies a > "canonical" form that would be picked up automatically in matching.) No, you're perfectly clear. However, not making a choice is, de facto, making a choice... because Doug would need to choose in 4645bis. Or we make no extlangs out of the box and let ietf-languages wrangle over individual extlang registrations later. Or we put all enclosed languages in as extlangs (making it more difficult to justify future non-registration of an extlang). Cherry-picking was employed in the current #2 precisely because (I believe you pointed this out) the real issue/need/desire for extlang revolved around a cherry-picked set and had increasingly little to do with macrolanguages per se. But we could choose to do all macrolanguages again. I actually don't care that much about how Quechua is tagged. > > Again, the main concern I'm trying to address anticipated > difficulty in agreeing on whether content should get tagged "zh- > cmn" or "cmn". > If the solution were obvious, we'd have been done months ago. The current compromise is that both camps are "satisfied" (you can use both forms), but one form is less preferred going forward. Most important, we describe what results to expect and what issues arise from a user's tag choices. I am supporting and have made technical arguments for one particular position, but am willing to go the other way if that's where consensus lies. In part that's because I'll be free to do "what I know to be the Right Thing", even if doing it breaks from consensus. 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.