Subject: [idn] last call reminder

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 4 Feb 2002 10:02:41 +0800

This is a reminder that the working group last call for

1. Internationalizing Domain Names in Applications (IDNA)
http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-06.txt

2. Stringprep Profile for Internationalized Host Names
http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-07.txt

3. Punycode version 0.3.3
http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-00.txt

4. Preparation of Internationalized Strings ("stringprep")
http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-00.txt

will end on Feb 11th 2002, 23h59m GMT-5.

-James Seng

---

From: "Jonathan Rosenne" <[email-masked]>
Date: Sun, 10 Feb 2002 18:21:43 +0200

Regarding Hebrew:

The proposals are inadequate for Hebrew domain names as follows:

Hebrew vowel signs etc. (points) should be stripped (mapped out) by
nameprep. Unicodes 05B0 to 05B9, 05BB to 05BD, 05BF, 05C1, 05C2, 05C4.

Explanation: These marks in Hebrew are optional, one may or may not use
them, for example to clarify a possible ambiguity. They should be
allowed but they should be ignored. Their presence or absence should not
make two host names different.

Note: This implies that FB2A to FB4e and FB1D should be mapped to their
base letters in nameprep.

Jony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of James Seng/Personal
> Sent: Monday, February 04, 2002 4:03 AM
> To: [email-masked]
> Subject: [idn] last call reminder
> 
> 

-James Seng

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 11 Feb 2002 21:42:39 +0000

Jonathan Rosenne <[email-masked]> wrote:

> Their presence or absence should not make two host names different.

This is a language-level equivalence issue, similar to
traditional/simplified Chinese or Danish aa/a-with-ring-above or English
color/colour.  Nameprep is not the place to deal with this.  Nameprep
produces canonical-form strings, not canonical-form words.

AMC

---

From: David Hopwood <[email-masked]>
Date: Mon, 11 Feb 2002 04:11:32 +0000

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

> make two host names different.

The following paper:

  Steven Atkin, Ryan Stansifer, Mohsen Alsharif,
  Bidirectional Domain Names,
  19th International Unicode Conference.

takes the position that the Arabic and Hebrew points should be
disallowed. I'm not familiar with Arabic or Hebrew, but from a
technical point of view there is nothing to exclude either solution,
and no additional difficulties from mapping them out. The question
is simply whether we want to allow them in encoded domain names, for
example URI links in HTML, email, etc.

I can't find the above paper on the web any more, so it is temporarily
at <http://www.users.zetnet.co.uk/hopwood/unicode/idnbidi.pdf>.
Here is the relevant section (I'm not necessarily agreeing with it;
just quoting it for discussion):

# There are a number of Arabic characters that can be safely
# excluded from domain names. Specifically, these include the
# Arabic presentation forms, U+FB50-U+FDFF and U+FE70-U+FEFC.
# It is safe to exclude these characters, as they only represent
# ligatures and glyph variants of the base nominal Arabic
# characters. Additionally, the Arabic points U+064B-U+0652,
# U+0653-U+0655, and U+0670 should also be excluded. In
# most cases the Arabic points are only used as pronunciation
# guides. If the points were to be included, then names that
# differed only in their use of points would be treated as if
# they were distinct and different names. This is like the
# English homograph "bow" (the arrow) and "bow" (the ship) which
# are ambiguous. Removing the Arabic points eliminates such
# problems, with the understanding that not every Arabic word
# would be able to be represented. The Koranic annotation signs
# U+06D6-U+06ED can also be eliminated from domain names, as
# they are not used to distinguish one name from another.
# In Hebrew the cantillation marks U+0591-U+05AF and Hebrew
# points UFB0-U5C4 can be excluded as they are predominately
# used as pronunciation guides and for indicating the underlying
# structure of text. Additionally, the Arabic and Hebrew
# punctuation characters are also excluded from domain names as
# they are currently not permitted. The list of acceptable
# Arabic and Hebrew characters are listed in Table2.
#
# Table 2: Acceptable Arabic and Hebrew characters
#
# Unicode Range         Script   Notes
# U+05D0-U+05F4         Hebrew   ISO8859-8
# U+0621-U+064A         Arabic   ISO8859-6
# U+0660-U+0669         Arabic   Arabic-Indic digits
# U+0671-U+06D3,U+06D5  Arabic   Extended Arabic letters
# U+06F0-U+06FE         Arabic   Persian, Urdu, and Sindhi

> Note: This implies that FB2A to FB4E and FB1D should be mapped to their

With nameprep as it is now, yes. However, if NFC-normalisation was done
before mapping (there are other good reasons to do that), then it wouldn't
be necessary, because these characters are canonically equivalent to the
base character followed by the point character. Since they also have a
composition exclusion, they will never occur in NFC (or NFKC).

- -- 
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: David Hopwood <[email-masked]>
Date: Wed, 13 Feb 2002 17:33:08 +0000

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

"Adam M. Costello" wrote:
> color/colour.

No, it's a script-level issue. The similar case of Arabic points is also
a script-level issue. (Someone mentioned the Khmer inherent vowels
U+17B4/17B5; that might be similar, but I'm less convinced because they
are apparently only used for phonetic transcription.)

Unlike TC/SC or other language-specific equivalences, mapping out
Hebrew and Arabic points is absolutely trivial to implement, trivial
to specify, and makes sense for all languages using the affected scripts.

- --

---

From: "Kent Karlsson" <[email-masked]>
Date: Sat, 16 Feb 2002 13:25:25 +0100

> U+17B4/17B5; that might be similar, but I'm less convinced 
> because they are apparently only used for phonetic transcription.)

Note that the Khmer "INHERENT" (no, not 'inherent', there are no
characters for those) vowels are invisible, and should normally not
be used.  But if they are, they cannot be seen (except in "view 
invisibles" mode).

> to specify, and makes sense for all languages using the 

Likewise, mapping *out* Hangul compatibility letters (which are not
as trivial to map properly to conjoining Hangul jamo) and mapping
letter cluster Hangul jamos *to* their constituent letters are trivial
to implement.  Doing the latter is also in accordance with the
desing of the Hangul script, *not* doing so *goes against* the design
of the Hangul script.

		Kind regards
		/kent k

---

From: "Kent Karlsson" <[email-masked]>
Date: Sat, 16 Feb 2002 15:13:18 +0100

> Likewise, mapping *out* Hangul compatibility letters (which are not

By "map out" I here meant "map to illegal", NOT "ignore/delete".

	Sorry for any confusion
	/kent k