Message-Id: <6.2.1.2.2.20050524032333.04472ca0@mail.jefsey.com>
Date: Tue, 24 May 2005 04:13:20 +0200
To: "Addison Phillips" <addison.phillips@quest.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: RE: [Ltru] [psg.com #967] address homograph issues
	insecurityconsiderations
In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B7F3930@irvmbxw01.quest.c
 om>
References: <634978A7DF025A40BFEF33EB191E13BC0B7F3930@irvmbxw01.quest.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ltru@ietf.org
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Addison,
in case my vacations are finished a few points.

1. I introduced the homograph issue. You discussed it at length, so I hoped 
you would understand as you did for the dated entries... The homograph 
problem I rose is not about the registry but about the script/charset 
conflicts and/or script variations. Your system does not introduce/document 
any protection against homograph issues, while users would legitimately 
believe they are protected.

2. ditto about security and "nationality" disclosure. I do not want Randy 
to ban me again for defending Human Rights., so, I prepared and circulate a 
short declaration on lingual rights respect by standard makers. This kind 
of text needs to be reviewed by many for moral and ethical endorsement. It 
will propose it to  IETF as to everyone else. If IETF chooses to oppose it, 
your concept could continue. If IETF chooses to support it, it will 
probably call for a complete review. I told the problem enough ... I try to 
speed things. My target date is July 1st, Paris meeting with everyone 
there. I will obviously copy it to you as soon as I can.

3. My printer is down. I spent more than three dollars today to get your 
.02.txt version printed. Then I stared reviewing it. Now, you announce 
version 03.txt. I cannot follow: I will make a final review and publish it 
during the Last Call. Like Randy did: one mail per remark. Trying to reach 
consensus by exhaustion has also draught back. I only hope that 04.txt 
includes a global change and addresses the numerous remarks I made.

 From trying to make a summary today, just a suggestion.I disagree with the 
document and do not speak English, so I would be a poor contributor: I know 
you live with this text for one year; but you could try to think as a 
developer reading the current text for the first time. May be it could help 
your text to be easier to read and understand?
Cheers.
jfc



On 00:03 24/05/2005, Addison Phillips said:
>Note that confusables cannot appear in the registry: registry entries are 
>always lowercase excepting regions (uppercase) and scripts (titlecase). 
>Scripts and ISO 3166 codes are both alpha-only (no digits!!)
>
>Confusables can only affect language tags. These tags will not be 
>well-formed excepting the use of 0/o and 1/l in primary language tags and 
>variants.
>
>So then... would this text work (in possibilities for registration section??):
>
><t>Language tags are formed from ASCII letters and digits. Some of these 
>characters may be confused when displayed in certain fonts in certain user 
>interfaces. In well-formed tags (where all of the subtags are actually 
>valid), the only subtags that are affected are registered primary-language 
>subtags (those longer than four characters, none of which exist at the 
>time of adoption of this document) or variant subtags. The character pairs 
>normally considered confusable in these subtags are 0 vs. O (%x30 vs. 
>%x4F) and 1 and l (%x31 vs. %x6c). No subtags will be permitted for 
>registration that differ only by these character pairs. For example, if a 
>subtag 'example' (%x65.78.61.6d.70.6c.65) were registered as a variant, 
>the subtag 'examp1e' (%x65.78.61.6d.70.31.65) would not be valid for 
>registration. In addition, applications for registration that present 
>obviously confusable sequences (such as 'examp1e') will probably be 
>rejected.</t>
>
>Addison
>
>Addison P. Phillips
>Globalization Architect, Quest Software
>Chair, W3C Internationalization Core Working Group
>
>Internationalization is not a feature.
>It is an architecture.
>
> > -----Original Message-----
> > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On
> > Behalf Of Peter Constable
> > Sent: 2005?5?23? 14:20
> > To: ltru@ietf.org
> > Subject: RE: [Ltru] [psg.com #967] address homograph issues
> > insecurityconsiderations
> >
> > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]
> > On Behalf Of
> > > John Cowan
> >
> >
> > > As long as everything is cased consistently, there is no problem, but
> > if someone
> > > uses anomalous casing, these would become a problem under your
> > proposal.
> > > I propose therefore that only zero/oh, one/eye, and one/ell be treated
> > as
> > > confusables; these could arise only in variant subtags.
> >
> > As John notes, there isn't an issue for subtags from ISO source
> > standards when casing conventions are applied, though there certainly
> > could be when they are not -- e.g. "ia" and "la" in ISO 639-1 -- but we
> > don't want to prohibit such on the basis of failure to apply casing
> > conventions: a security-conscious app *should* apply the casing
> > conventions if displaying these tags in a UI.
> >
> > As John also notes, zero/Oh, one/Eye and one/el issues can arise for
> > variants, and we should ensure that they are prevented. They can also
> > arise for the registered-lang subtag, and that should also be prevented.
> >
> > The registered-lang subtags is also susceptible to the el / "Eye" issue
> > since there are no casing conventions for this subtag. I think we should
> > be adding prevention for that as well.
> >
> > Since extensions cannot be interpreted without reference to other RFCs,
> > I don't think we need to worry about homographs within extensions.
> >
> >
> >
> > Peter Constable
> >
> > _______________________________________________
> > Ltru mailing list
> > Ltru@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru