With respect to the proposed update to the Language Subtag Registry
draft-ietf-ltru-4645bis-10:
I would like to lodge an objection to the deletion of the Preferred-Value for
language subtag YU.
This change breaks the equivalence class relation between YU and CS. It
detrimentally changes the behavior of existing implementations.
The loss of the relationship between YU and CS makes documents that were
believed to be tagged equivalently, to no longer be equivalent.
There is also no benefit to this change.
To be concrete, assume a user attempts to find documents for languages from
Yugoslavia.
Using the then current registry data, a query tool noting the preferred value
relationship, matches either xx-YU and xx-CS.
Another user searches for documents for Serbia.
A query tool using the current registry data noting the preferred value
relationship, matches either xx-YU and xx-CS.
The results are in some sense accurate and complete, given the history of the
subtag.
After this change in the preferred value relationship, the query tool does not
know to search for both xx-YU and xx-CS, since the registry does not indicate a
relationship. Only one or the other subtag is used for each query. However, the
query results are now incomplete since some documents for xx-YU have been
tagged with the one-time preferred tag of xx-CS.
Comments in the registry are not a solution. Comments are a good thing for
recording rationale and tangential history. However, implementers are not going
to go thru and read the comments on any or all tags in order to make a correct
implementation. They are going to implement based on the schema and operate
with the data values.
The registry should stay as it is with respect to YU and retain CS as the
preferred value.
As CS is now being used as a preferred value, deprecated or not, there isn't a
compelling motivation to remove the preferred value for YU.
Please eliminate this needless change that breaks applications relying on the
relationship between YU and CS.
tex
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf