IDNs and Language definitions and labeling (was: RE:
New version, draft-faltstrom-idnabis-tables-02.txt, available)
John C Klensin
klensin at jck.com
Fri Jun 22 17:53:24 CEST 2007
--On Friday, 22 June, 2007 11:12 +0100 Debbie Garside
<debbie at ictmarketing.co.uk> wrote:
> Hi John
> Thank you for taking the time to formulate such an informative
> and useful depth response - I cannot tell you how helpful this
> is! I have read one or two of the RFC's but it is good to
> have the "full set" identified. I am sure others monitoring
> this forum will think so too.
I don't know that you should consider that list the "full set".
It is very hard conclude that any list in this area is
comprehensive without also considering, e.g., particular
applications or applicability. See below.
> Wrt RFC4646bis and ISO 639-6, I have been an active
> participant of IETF-languages and subsequently LTRU for the
> past 4 years. See
> ml and follow subsequent postings if you are interested in the
> latest discussion wrt 639-6.
As many readers of this list know, I'm personally much more
interested in references and referencing methods that are
optimized for use by human beings than I am in ones that are
optimized for identifying network resources. (I've referred to
these elsewhere as "user facing" and "network facing" to avoid
getting tied up in abstractions that are less easily
understood.). The fact that DNS names have been usable for
user-facing references has been a great convenience.
Internationalizing them expands their mnemonic utility for both
network-facing and user-facing applications, but will never, by
itself, provide the sort of finely-tuned, language and culture
sensitive, localized location and navigational facilities to
which many of us aspire. The latter will certainly require
language identification and other supporting metadata.
The difficulty with both 639-6 and the LTRU work in that area
isn't in building code lists or taxonomies --although both are
important and significant pieces of work-- but figuring out how
to determine and relate appropriate granularity to a particular
problem, whether at assignment (sender) or matching (receiver)
time. 639-6 may be less easy in that regard precisely because
it isn't structured in an obvious way.
> However, I can see that my ideas for allocating Unicode code
> points to the writing systems within ISO 639-6 does not meet
> the objectives of this particular forum; sorry for muddying
> the waters but it is a bit of a passion of mine which means it
> is quite hard to stop my fingers moving on the keyboard
> sometimes :-)
I appreciate your understanding of the issues.
More information about the Idna-update