RFC 3066bis: extensions

[Peter Constable]

I'd like to raise a question regarding the value of the extensions
mechanism in the proposed successor to RFC 3066. 

Consider a tag such as "az-Arab-x-SIL.AZE". The same semantics could be
contained as two metadata attributes, "az-Arab" in one and "SIL.AZE" (or
some equivalent) in the other.

The tag "az-x-SIL.AZE" would be applied to some content or resource, or
passed through some interface to request or reference certain content or
resources, following some higher-level protocol. 

If the higher-level protocol is proprietary, then anything could be
done, including using proprietary extensions to the language tag spec to
arrive at tags that would not conform to the spec, such as tags that
used otherwise invalid characters like "/", that allowed tags beginning
with "u=", etc.. In this situation, it is not a concern if there are
portions of a language tag -- the extension -- that have private
semantics. Note, though, that one would be free to define that protocol
instead using additional attributes / parameters and use RFC3066bis
langids that do not include extensions.

In the case of an open-standard protocol, it seems to me that
privately-defined extensions would serve no purpose. The only possible
exception would be if one was referring to a public standard of a very
general nature, such as XML, serving as a platform on which some
application is built. But in that application, separate
attributes/parameters could rather be used, again allowing an RFC3066bis
that does not include extensions. 

It just seems to me that anything that could be done using extensions
could very easily be done without such a radical innovation. At the same
time, adding the extension mechanism involves some costs and back-compat
issues.

I'd like to hear from Addison and Mark on the case for adding the
extension mechanism. I also wonder what opinions others have.


Peter
 
Peter Constable
Globalization Infrastructure and Font Technologies
Microsoft Windows Division