> From: ned.freed@xxxxxxxxxxx [mailto:ned.freed@xxxxxxxxxxx] > > RFC 3066 left us with bigger problems: it doesn't give us any > > way to identify pieces that we would be encountering in registered tags > > (apart from hard-coded tables compiled from versions of the registry > > that pre-exist a given implementation). > > With, as you point out below, one important exception: It did have a way > to > reliably identify a country code in most cases (but not all). If "in most cases" means from among tags in use today under the terms of RFC 3066 (as John Cowan would say, "what is true"), then yes. But if "in most cases" means trom among tags permitted by RFC 3066 (as John Cowan might say, "what is the rule") -- including some that users have been wanting to use but have delayed using pending a revision of RFC 3066-- then no: RFC 3066 allowed for reliable identification of a country code in only a small portion of all possible cases: only if it occurred as the second subtag following an ISO 639 code (it does not prohibit a country code from occurring anywhere after the first subtag). > And this ability > to say "2 character subtag in the second position, most be a country code" > was > quite useful even though it might miss other occurences of country codes > in some cases. The draft would still grant the ability to make that statement, and would permit new implementations never to miss *any* occurences of country codes. > 3066bis provides a reliable way to locate country codes in all cases, but > the > algorithm is different. And this is a non-backwards-compatible change. Surely this has been the point of greatest contention in this discussion, and is clearly not obvious, for there are several who have repeatedly indicated that they do not see any such backwards non-compatibility. Please, anyone claiming there would be incompatibility, be pedantic: define whatever terms, make explicit whatever assumptions are required to support this claim. (I suspect the root of this disagreement lies in unstated assumptions.) Those who claim backward compatibility do so on the basis that every existing implementation conformant to RFC 3066 will continue to operate precisely as designed and in conformance with RFC 3066 regardless whether they encounter a tag presently well-formed and valid under the terms of RFC 3066 or one that would be sanctioned by this draft. If there is any term needing clarification in that statement or any suspected assumption not made plain, please ask for clarification. > Of course there's the option Dave Singer has raised: Reverse the positions > of > script and country codes in 3066bis. I see two problems with this: > > (1) Script codes are in general more important than country codes, and > therefore really should come first so that simple truncation matches > work "better". (There are probably exceptions to this assertion > lurking > out there somewhere, but I believe it is mostly true.) Thank you for voicing support for this position. > (2) I believe it increases the number of grandfathered codes that won't > conform > to the new format. If I'm not mistaken, I think there would be no difference in this regard. Peter Constable _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf