Re: [idn] Re: [idn-nameprep] Arabic hyphen-like glyph

["James Seng/Personal" <James@Seng.cc>]

John,

I do agree an analysis of the security implications are useful at least
as informational.

But I need to stress the wg need to proceed with internet drafts. We can
talk endlessly on ideas in emails but it will remains as what it is, ie,
email. This is the message I am trying to bring across to Lee: Write
draft first, then we can discuss based upon it.

As wg co-chair, I will make no judgement about what goes into the pool
or what's not so long there is sufficient interest and request (and of
course within our charter).

But on a personal note, I think Patrik hits the nails on the head. I am
not sure if IDN WG is the right forum to discuss 'look-alive characters'
issues. Remember we not only talking about codepoints, reportairs and
also fonts rendering and font variants...

-James Seng

----- Original Message -----
From: "John C Klensin" <klensin@research.att.com>
To: "Soobok Lee" <lsb@postel.co.kr>
Cc: "James Seng/Personal" <James@Seng.cc>; <idn@ops.ietf.org>
Sent: Friday, July 27, 2001 4:25 AM
Subject: Re: [idn] Re: [idn-nameprep] Arabic hyphen-like glyph


> --On Thursday, 26 July, 2001 19:50 +0900 Soobok Lee
> <lsb@postel.co.kr> wrote:
>
> > Using hyphen in place of NWNJ in Arabic multi-word domains
> > may cause confusion because arabic script already contains
> > hyphen-like letters already. that's the point.
> > That's not related directly to nameprep, but to IDN security.
> >
> > I hope those small ratholes may not become security holes in
> > IDN.
>
> It seems to me, regardless of other IDN work and its outcomes,
> that an analysis that identifies these "small ratholes" in
> matching and character identification and their security
> implications would be a very useful contribution.  Its text might
> ultimately become part of something else, or it might be
> published separately.  And I would hope that the WG Co-chairs
> would not impose an "interest level" requirement on drafts or
> components of such an analysis, treating it instead as part of
> the general requirement on the WG to produce a "security
> considerations" analysis of any proposed standards-track
> materials it produces.
>
>     john
>