RFC 3066bis: extensions

[jcowan at reutershealth.com]

Peter Constable scripsit:
> 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.

I don't think this is a very good example.  Better would be my famed
example of New York Chinatown dialect, yuh-us-x-dialect.taishan-local.nyc.
(In the 1766/3066 regime, this would be zh-yue-taishan-us-nyc.)

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

The difficulty is that many existing environments have a single slot for
"language" or "locale", and extending the content is far easier than
extending the wrapper.

> 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 think the use of . and % could be readily dispensed with, by replacing the
. with another - and forgoing the use of non-ASCIInumbetical characters.

-- 
John Cowan  jcowan at reutershealth.com  www.reutershealth.com  www.ccil.org/~cowan
The known is finite, the unknown infinite; intellectually we stand
on an islet in the midst of an illimitable ocean of inexplicability.
Our business in every generation is to reclaim a little more land,
to add something to the extent and the solidity of our possessions.
        --Thomas Henry Huxley