RE: [OT] Reusing the same property (was: RE: PRI #202: Extensions to NameAliases.txt for Unicode 6.1.0)

From: Doug Ewell <>
Date: Wed, 31 Aug 2011 10:12:40 -0700

The solution would have been easy:

- use for the generic site
- use for the English-language site
- use for the French-language site
- use (and only that) for the Wawa site

No need for private-use identifiers here. (I agree that coding
standards like 639 should have private-use areas, but not to extend the
standard beyond its intended scope as Philippe suggests in his last

Or, since the Very Well-Known Site already uses several language codes
that do not conform to, and even conflict with, the existing standards,
just use 'wawa' in the Wawa URL instead of 'www' and that solves the
problem too.

Sorry for the non-Unicode digression.

Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14 | | @DougEwell ­
> -------- Original Message --------
> 2011/8/31 Doug Ewell <>:
> > I don't know if this was what Philippe had in mind, but it reminded me
> > of a situation in the world of language tagging.
> >
> > Apparently ISO 639-3/RA got a request, from an individual associated
> > with a Very Well-Known Web Site, to change the 639-3 code element for
> > the Wawa language from 'www' to something else.  Turns out that the site
> > uses language codes in its URLs to link to different language versions:
> >
> > - links to the generic site
> > - links to the English-language site
> > - links to the French-language site
> >
> > And they wanted to have a site in Wawa, and encountered a name
> > collision.
> Here again, it's impossible to avoid collisions with all uses of
> identifiers (names or numeric identifiers) that could occur within
> specific applications. But at least ISO 639 provides a solution : you
> can use a prefix that is unambiguously "private use" and use such
> prefix to add the conflicting identifier. In ISO 639, the "q" prefix
> will work well, so you can use "q-www" and still make use of the
> standard ISO 639 prefix to avoid the collision with standardized host
> names associated to web services offered in any domain.
> The domain name system allows amny more solutions that will never
> conflict with ISO 639 (you could as well use a digit for prefixing the
> language code).
> For this reason, there's absolutely no need for ISO 639 to provide
> such aliases. There does exist standard aliases in ISO 639 (for
> example several historic 2-letter codes in ISO 639-1, the technical
> and bibliographic ISO 639-2 codes, 3-letter codes in ISO 639-2 and ISO
> 639-3) but their origin only comes from previous standards which
> competed to the same application before ISO 639, and that were unified
> in the same standard.
> But there's no reason to pollute the unified namespace more (because
> it would in fact create even more conflicts requiring an escaping
> mechanism for some applications). But this also mean that any
> well-behaved standard *unified* namespace has to include a private-use
> space, as it allows integration and coexistence with other standards
> or applications initially not designed to identify the same thing (for
> example, here mixing the identification of a language, and the
> identification and addressing of an Internet host)
Received on Wed Aug 31 2011 - 12:13:58 CDT

This archive was generated by hypermail 2.2.0 : Wed Aug 31 2011 - 12:13:59 CDT