RFC3066 replacement nearing completion
L. David Baron
I'm understanding this message correctly:
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02759.html
See links there for more details, including the document.
I'm sending this to dev-l10n because it might be relevant to the
language tags we use to identify localizations.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Robert Kaiser
> One half of the replacement for RFC3066 seems to have been approved, if
> I'm understanding this message correctly:
> http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02759.html
> See links there for more details, including the document.
>
> I'm sending this to dev-l10n because it might be relevant to the
> language tags we use to identify localizations.
Thanks. This half
(<http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-15.txt>)
seems to only concern ranges and pattern matching though, which isn't
affecting us a lot.
The drafted other half,
<http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt> is
the more interesting one, but it looks very much as if they are only
extending RFC3066 and not changing it substantially, which means that
our locale names stay conforming to the current specs - at least they
don't break it, that is. We are only supporting a subset of what RFC3066
allows for our locale names at the moment, and it looks like this will
stay the same, even once the new spec will obsolete that RFC.
Still, thanks for informing us about what's happening in that area.
Robert Kaiser
Simon Montagu
Yes. One of the explicit design goals of the revision was that no
existing RFC 3066 language tag should become invalid in the new version,
see especially section 8.