Subject: RE: [idn] Should we add U+FF0E FULLWIDTH FULL STOP to section 5. 10 of Nameprep?

From: Yves Arrouye <[email-masked]>
Date: Fri, 20 Jul 2001 14:11:55 -0700

> FULLWIDTH FULLSTOP(U+FF0E) is already compatibility 
> decomposed into Latin FULLSTOP (U+002E)  in KC Normalization 
> step in NAMEPREP. You can confirm that in page 4 of 
> http://www.unicode.org/charts/PDF/UFF00.pdf .
> 
> If any label contains U+ff0e to be mapped into u+002e in kc 
> norm in nameprep, it will be treated as error  in the 
> following prohibition stage in nameprep , since
> u+002E. is prohibited.

But that is exactly the problem I want to address: if you type:

	SOMETHING<U+FF0E>JP

For example, it will not be seen as a domain name in the .JP domain, even
though this was the intent (let's say also that JP can be in full-width
ASCII, which makes the U+FF0E very plausible). Just like typing:

	SOMETHING<U+3002>JP

won't. This is the exact same thing. So I think we need to handle it just
like U+3002 is handled.

YA

---

From: Yves Arrouye <[email-masked]>
Date: Fri, 20 Jul 2001 15:16:04 -0700

> For example, it will not be seen as a domain name in the .JP 
> domain, even though this was the intent (let's say also that 
> JP can be in full-width ASCII, which makes the U+FF0E very 
> plausible). Just like typing:
> 
> 	SOMETHING<U+3002>JP
> 
> won't. This is the exact same thing. So I think we need to 
> handle it just like U+3002 is handled.

I wasn't really clear. Since it's forbidden because of the compatibility
mapping, all I want is some text that identifies that as a caveat for IDN
implementers, so that they don't just map U+3002 to U+002E before Nameprep
and then wonder why this one doesn't work.

YA

---

From: David Hopwood <[email-masked]>
Date: Fri, 20 Jul 2001 23:35:33 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Yves Arrouye wrote:
> > http://www.unicode.org/charts/PDF/UFF00.pdf.
> >

I agree (and the same for anything that compatibility-maps to U+002E in
future versions of the tables).

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "Adam M. Costello" <[email-masked]>
Date: Sat, 21 Jul 2001 00:04:21 +0000

Yves Arrouye <[email-masked]> wrote:

> I wasn't really clear.  Since it's forbidden because of the
> compatibility mapping, all I want is some text that identifies that as
> a caveat for IDN implementers, so that they don't just map U+3002 to
> U+002E before Nameprep and then wonder why this one doesn't work.

I'm still not sure what you want, but I just noticed that the existing
explanation of the prohibition of U+3002 is a bit misleading.  It
currently says:

    U+3002 is used as if it were U+002E in many input mechanisms,
    particularly in Asia.  This prohibition allows input mechanisms to
    safely map U+3002 to U+002E before doing nameprep without worrying
    about preventing users from accessing legitimate host name parts.

However, mapping U+3002 to U+002E "before doing nameprep" isn't specific
enough.  If it happens immediately before doing nameprep, then nameprep
will fail.  It needs to happen before the domain name is split into
labels.  Therefore I think the text should read:

    U+3002 is used as if it were U+002E in many input mechanisms,
    particularly in Asia.  This prohibition allows input mechanisms to
    safely map U+3002 to U+002E before splitting a domain name into
    labels, without worrying about preventing users from accessing
    legitimate host name parts.

This recalls an earlier discussion about just how much processing
should be done before a domain name is split into labels.  Should
fullwidth-full-stop be mapped to full-stop before the splitting?
Probably.  How about one-dot-leader (for which full-stop is a
compatibility decomposition)?  Maybe.  Should digit-one-full-stop be
replaced by its compatibility decomposition "1."?  Or square-CO by its
compatibility decomposition "CO."?  Maybe not.

Should this be left up to the user interface designer, or should there
be recommendations or requirements?

AMC