RFC 3066bis: extensions
petercon at microsoft.com
Tue Jan 20 00:35:22 CET 2004
> -----Original Message-----
> From: jcowan at reutershealth.com [mailto:jcowan at reutershealth.com]
> Sent: Friday, January 16, 2004 10:33 AM
> The difficulty is that many existing environments have a single slot
> "language" or "locale", and extending the content is far easier than
> extending the wrapper.
But that misses the point that either these extensions do or do not need
to be interoperable. If they do, you'd need to formally define them in a
client protocol anyway; even if you have a "slot" through which you can
pass them, they're not openly meaningful as long as they're privately
defined. We could also revise RFC 2978 to allow an extension mechanism
for character set tags, since that's a "slot" that's available in
various environments, but I can't pass useful information through that
extension unless we specify how those extensions are to get used, and
that takes writing a new higher-level-protocol spec.
If they don't need to be interoperable, then one can always say you're
employing some derivative implementation without needing to create the
mechanism in this RFC.
Globalization Infrastructure and Font Technologies
Microsoft Windows Division
More information about the Ietf-languages