draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions

[Peter Constable]

> From: ned.freed at mrochek.com [mailto:ned.freed at mrochek.com]


> > 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