Subject: Re: IDN and language

From: Bruce Lilly <[email-masked]>
Date: Wed, 5 Jan 2005 04:01:38 -0500

>  Date: 2005-01-04 12:06
>  From: John C Klensin <[email-masked]>

> the
> IDN situation is not an issue except in a very narrow sense and
> similar situation would apply to local-parts if we ever do
> something there.  In the IDN case, the protocols are written in
> terms of arbitrary Unicode strings and just about have to be --
> there has never been a DNS restriction requiring that the labels
> be names or words in a language.  The protocols apply some
> mapping rules that reject a few characters (and hence the labels
> that contain them) and change some characters into others, but
> the net effect is still a set of standards written in terms of
> strings, not languages.

My concern is the distinction between "names" (in the sense used
in RFC 1958, i.e. protocol elements) vs. "text" (RFC 2277),
and internationalizing domain names seems to make sense only if
the domain names are being treated in some way as text (i.e.
human-readable content, and therefore (possibly, at least) in
some language (see 2277 section 2, third paragraph and section
4.1, first sentence).  RFC 2277, a.k.a. BCP 18, requires (sect.
4.2) that protocols which transfer text must have provision for
carrying language information.  The considerations for making
provision for language-tagging (N.B. not requiring that every
IDN be tagged) are clear when one considers presentation
issues for the visually impaired; a screen reader needs to be
able to identify language to correctly present at least some
subset of labels which might appear in either an IDN or
internationalized local-part.

> The situation with local-parts will, most of us are convinced,
> work out in much the same way.  There is a long history of
> strings used in local-parts that are not "names", "words", or
> otherwise bound to a particular language. [...]

Agreed, and I'd be happy if local parts and domain names were
to be treated purely as protocol elements.  But given the
decision to internationalize and hence the treatment as text
at least for presentation, there ought to be provision for
indicating language where necessary for correct presentation.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 5 Jan 2005 03:37:43 -0500

>  Date: 2005-01-04 13:04
>  From: John Cowan <[email-masked]>
 
> Finding country codes is straightforward: any non-initial subtag of two letters
> (not appearing to the right of "x-" or "-x-") is a country code.
> This is true in RFC 1766, RFC 3066, and the current draft.

I believe that:
1. it is not strictly true of the registered tag sgn-CH-de, except
   by the coincidence that "de" describes a language as well as a
   country; unless Switzerland has united with Germany when I
   wasn't paying attention.
2. there is no way that an RFC 3066 parser could have made such an
   assumption as there is no specification regarding interpretation
   of 2-letter subtags in the 3rd or subsequent positions.  In
   particular, what you state as a rule appears nowhere in 1766 or
   3066.

---

From: John Cowan <[email-masked]>
Date: Thu, 6 Jan 2005 07:34:57 -0500

Bruce Lilly scripsit:

> > Finding country codes is straightforward: any non-initial subtag of
> > two letters (not appearing to the right of "x-" or "-x-") is a country
> > code.  This is true in RFC 1766, RFC 3066, and the current draft.
> 
> I believe that:

Fair enough: "de" in this case is clearly not a country code.

>    particular, what you state as a rule appears nowhere in 1766 or

I stated it (again) as the truth, not a rule; but I concede that it is
not the truth.

-- 
John Cowan      http://www.ccil.org/~cowan      [email-masked]
Be yourself.  Especially do not feign a working knowledge of RDF where
no such knowledge exists.  Neither be cynical about RELAX NG; for in
the face of all aridity and disenchantment in the world of markup,
James Clark is as perennial as the grass.  --DeXiderata, Sean McGrath