Message-Id: <6.2.3.4.2.20050829005345.0597c530@mail.jefsey.com>
Date: Mon, 29 Aug 2005 01:14:09 +0200
To: ietf@ietf.org, ietf@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <200508281042.53894@mail.blilly.com>
References: <4amb37$ak3l4l@mx02.mrf.mail.rcn.net>
	<200508281042.53894@mail.blilly.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: Last Call: 'Tags for Identifying Languages' to BCP
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 16:42 28/08/2005, Bruce Lilly wrote:
> >  Date: 2005-08-25 20:55
> >  From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
> > please document how do you do, while respecting the hybrid format of
> > the proposed ABNF where information is not indentified by fixed
> > position, but also relative position and size, with "-" as sole
> > separator. And they want to keep labels between "-" 8 characters
> > long. Tell me how you support IDNs.
> >
> > Let suppose that I have "lang-tags.org:" as a scheme.
> > or "xn--abcdef.com:". Tell me how you support them
>
>It's unclear what you're trying to get at here.  A URI scheme is a
>protocol element (an "assigned number") registered by IANA, not a
>piece of text (see RFCs 1958 and 2277).

A proposition I received from the WG-ltru was to slice URI tags into 
8 aphanum labels, etc. Among many problems URI tags accept domain 
names, mail names and IP addresses as registered identifiers. The 
main problem with the ABNF is therefore the use of "-" as a separator 
since "-" is a legitimate character in domain name. The support of 
IRI tags is impossible.

Our work is on CRC (common reference centers). offering such 
references. URI tags are the correct solution (with some restrictions 
we will probably document once the RFC is published)

>As such, it has no need of
>an indication of language, for it has no language; it is a language-
>independent protocol element.  Confusing protocol element issues with
>language will only muddy the water; try to stay focused on real
>problems.
>
>For that matter, DNS labels are public names (i.e. protocol elements,
>again see RFC 1958 (sect. 4.3, noting that "text" there has a different
>meaning than in RFC 2277)) and as such there should not have been any
>reason to overload the semantics and baggage of internationalized
>text (in the RFC 2277 sense).  Now, having made the decision to
>nevertheless do so, you might well point out that per RFC 2277, there
>ought to be a means of indicating language in IDNs.  However, that is
>primarily an issue with the IDN specification(s), not with the document
>under discussion (except to the extent that the document under
>discussion extends the likely length of tags in a way that is likely to
>conflict with the DNS label length and domain name length limits, *if*
>there were in fact provision in IDN for the use of language tags.

Fully correct. The response is with the approved pending URI Tags RFC.
IRT IDN, as a "multilingualiser" I disapprove IDNA. But whatever the 
final solution the MLDN charsets may use a langtag like solution. 
Hence the interest. Another interest is that currently the IANA uses 
RFC 3066 language tags to identify the IDN tables. What is IMHO an error.

>You
>might also point out that as IDNs use utf-8 exclusively as a charset, and
>as script is easily inferred from the Unicode code points corresponding
>to utf-8, that the length-increasing provision for conflating script with
>language would be unnecessary and redundant *if* IDNs had provision for
>language tags.  But IDNs have no such provision at this time.

Correct. The MLDN problem is IMHO a different issue. However I say:

1. a langtag may be associated to a locale (this is in the WG-ltru 
Charter [Unicode CLDR project and our own ISO 11179 related solution])
2. we think there should be DNS locale for some important sites and services
3. DNS locale could also be the proper place to distribute MLDN 
virtual zones charsets (several concepts to discuss, specify and deploy).

jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf