> > It's my impression that at least part of what kept us from going that route was > > > > (a) the scenarios in which extlang-to-macrolanguage fallback didn't provide useful results, > > (b) the scenarios in which extlang might hinder useful right-truncation fallback > > in existing implementations because region or script are more useful than extlang, and > I see (a) and (b) as being practically the same argument, since they are > both focused on kinds of right-truncation fallback. Any heuristic that returns > something other than what the user explicitly asked for deserves a "health > warning". The question is whether we allow a heuristic with known limitations > to override all other concerns. I agree, and also I'm concerned that regardless of the form of the tag, then 4647bis is going to have to address fallback in some way that is smarter than right-truncation. None of the techniques we've discussed work for all apps with pure right-truncation > > (c) the assumption that, if we use extlang at all, then we must use it for all macrolanguages > > rather than being able to specify particular cases (no cherry picking). > I don't see this as an obstacle. It seems to me that we're cherry picking zh no matter which direction we go, so I don't think this should be a major concern. ========================================== > As co-chair: > I'm very concerned that this issue continues to come up. That suggests > that either our rationale isn't clear enough in the i-d, or that we've got it > wrong. It could be that this is just one of those situations where there is > no "right" answer, and we need to just pick one. > When Peter started this thread, he gave us a useful explanation of how > two differing points of view led to our current situation. Perhaps it might > be useful to work through the pros and cons of the alternatives from > the perspectives of important user communities, both as producers and > as consumers of tagged data, new and legacy. I agree. I think that we've come to the current point through good intentions, but that the end result doesn't give us the clarity that we originally expected. I think we need to back up a bit and look at the bigger picture rather than trying to tweak a couple paragraphs. - Shawn _______________________________________________ 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.