Subject: [idn] WG Update

From: "James Seng/Personal" <[email-masked]>
Date: Thu, 4 Oct 2001 09:50:15 +0800

In the last London meeting, there are still some outstanding issues
which we agreed to bring it back to the mailing list to discuss.

First, the issue of nameprep. nameprep have been renamed to stringprep
and the new draft is available few days ago. Please review
draft-ietf-idn-nameprep-06.txt.

And related to nameprep are the jpchar, hanguelchar and tsconv drafts.
The authors should get together to consider an architecture document.
We should set a deadline for this to be concluded, probably sometime
before Salt Lake meeting.

This architecture document should take into consideration of:
a. the recommendation from the Unicode Consortium to the WG dated 02Sept
b. the source and stablity of the referenced work/codepoints

(Personally, I would strongly recommend that nameprep remains as it is
and the rest of the "localization" to be deal at a different level,
either at the input method or below at the zone file.)

Secondly, there is a reordering draft draft-ietf-idn-lsb-ace. We have
already seen some results on reordering but we have not seen much
discussion on the downside of reordering. In anycase, we would like
to encourage further discussion on reordering draft as we would like
to conduct a strawpoll on the draft soon.

Thirdly, we have seen a strong number of people who is against UNAME and
UDNS. Therefore, we will be removing UNAME and UDNS from the WG Pool in
the next few days. Please take note that this does not prevent someone
from coming forward with another proposal.

The wg chairs have also receive several request to make updates on the
goal & milestone of the charter to reflect the current wg position. We
will send out a first draft for comments very shortly.

Some other wg matters:

As agreed in London meeting, the requirements draft will be moving
forward for IETF Last Call.

Based on the hum in London, the chairs also believe we have consensus
on AMC-ACE-Z (draft-ietf-idn-amc-ace-z) as the choosen ACE. We feel
a wg last call would provide no further information for the chairs to
determine consensus since most people are in the "don't care but just
want to see one ACE choosen" group. We will move AMC-ACE-Z forward to
the IESG at an appropriate time.

(minor note: we also agree that we should look for another name for
AMC-Z but I think that discussion have already started :-)

A prefix for AMC-Z will be assigned using the normal IESG/IANA/
RFC-editor procedure for coordinating assignment of protocol
parameters during IETF last call and publication as an RFC.

Given this, we would like to advise people to start doing
interoperability testing on their implementation of AMC-Z.

For you information and comments.

James Seng
co-chair IDN wg

---

From: Erin Chen <[email-masked]>
Date: Sun, 07 Oct 2001 17:42:02 +0800

James and Dear all,

As James mentioned in the WG Update infromation, the requirements draft will

be moving forward for IETF Last Call.

Actually we'v seen many people discusswed about what IDN were they expected
before and after Landon meeting. To define the requirement of IDN is an
fundamental and important goal of our IDN WG. If the draft requirement-08 is

going to moving forward for IETF Last Call, we are strongly suggest
equirement-08 should fully meet the real requirement of IDN.

As in the 2. General Requirements of 2.3 Canonicalization

[21] In order to retain backward compatibility with the current DNS,
the service MUST retain the case-insensitive comparison for US-ASCII
as specified in RFC 1035. For example, Latin capital letter A (U+0041)
MUST match Latin small letter a (U+0061). Unicode Technical Report #21
describes some of the issues with case mapping. Case-insensitivity for
non US-ASCII MUST be discussed in the protocol proposal.

I recommend modify the last line "MUST be discussed" to be
"MUST be provided", as to be " Case-insensitivity for non US-ASCII MUST be
provided in the protocol proposal"

Beside [21], I think draft requirement-08 still need all the WG members to
review
carefully to insure it meet the real IDN requirements.

Erin Chen

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 07 Oct 2001 08:22:32 -0400

> As James mentioned in the WG Update infromation, the requirements draft
> will be moving forward for IETF Last Call.

The management of this document has been problematic, and the editors are
non-responsive to requests for modification -- the "Intended Scope" section
retains its ACE recommendation -- this appears to be an article of religious
conviction.

> Beside [21], I think draft requirement-08 still need all the WG members
> to review carefully to insure it meet the real IDN requirements.

I don't think the existing requirements document must be abandoned, but it
must be edited by editors who are _editors_ before it leaves this WG or its
valu is limited.

I've made process suggestions to the editors, without comment or reply, to
the co-chairs (some overlap), and to the ADs and the TA.

Eric Brunner-Williams

---

From: [email-masked] <[email-masked]>
Date: Sun, 7 Oct 2001 22:38:08 +0800

> provided in the protocol proposal"
        The term " Case-insenstivitty for non US-ASCII "  should be defined
and described clearly, especially in any phase before ACE translation.
        Unicode is the collection of all scripts in all native code.  Some
scripts  are  alphabetic  font of "Full size  or double character size ASCII
font" coded in  native code and collected in UNICODE table.  That part  are
treated the same as US-ASCII characters in nameprep by case mapping with the
table of Unicode Technical Reports #21. I think this part is not related to
the issue of Case-incenstivity for non-US-ASCII ".
         The TC/SC equivalent class is always conceptually described by the
similar properties of  case in ASCII characters ,  but one thing in
retaining the out-look of original form is very inportant in CJK characters
of equivalent class .  That is say, to retain the case-insensitive
comparison for US-ASCII should not be implemented with nameprep  by
"force-all-to-lower-case" , I think the approach of "forced all ASCII
characters to lower case and losing the information of case" is not
necessary in nameprep phase. So, the key point of "Case-insenstivity for non
US-ASCII " is to reserve the case information before ACE translation.
Because AMC-ACE-Z  encoding has the feature that can retain the case of
US-ASCII characters in  ACE formatted IDN.   And the comparison is
accomplished by the current LDH-DNS server in insensitive-case comparison.
        The backward compatibility in retainning  the out-look of case of
ASCII is important now . It is  not just to keep the compatibilty of past
ASCII name but also help to use the case anotation of AMC-ACE-Z to  support
CJK characters can be recovered to the original scripts form.  The
comparison of TC/SC equivalent class are also based on the same feature of
case-insensitive comparison in LDH-DNS but it need to retain all the
original case form in passing-thru all processing phase. So the non-ASCII
part of IDN can be recoveried to their original scripts form.

L.M.Tseng

> review carefully to insure it meet the real IDN requirements.
>
> Erin Chen
>
> James Seng/Personal 寫入：
>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 07 Oct 2001 09:34:38 -0700

>  the "Intended Scope" section

Folks,

A requirements document needs to specify requirements, not solutions.  It 
is not for the purpose of choosing a technology.  It is for the purpose of 
specifying the functions that a technology must provide.

A requirements document that crosses over into making specific technical 
recommendations is LESS useful, not More.  It is creating an opportunity 
for controversy.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 07 Oct 2001 15:39:12 -0400

> recommendations is LESS useful, not More.  It is creating an opportunity 

Dave,

If no one disagreed with the recommendation, it would still be bogus.

I disagree with the recommendation, but I'd be just as concerned about
an editing excess if it read:

    It is recommended that the solution necessarily entails more than 
    the DNS itself, can not be satisfactorily resolved by indirection
    (layering), and should not be resolved by an alternate mechanism
    (directorie service).

Requirements documents, particularly in complex and contentuous areas, are
not party favors, to be awarded uncritically to the party in favor.

Reading the damn thing critically, and taking the time to write carefully,
has been time wasted.

Eric

---

From: David Hopwood <[email-masked]>
Date: Sun, 07 Oct 2001 07:33:06 +0100

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

> provided in the protocol proposal"

I disagree. As it happens, all of the proposals provide case-insensitivity
for non-US-ASCII, but it is *not* a requirement. The protocol would work
fine and would be perfectly acceptable to users without it. We should be
clear about the difference between features that are *desirable* (in this
case for consistency), and *required* features.

In particular, preservation of case is wholly unnecessary, IMHO.
[21] is perfectly OK as it is (although much of the rest of the requirements
draft is not; I'll discuss that in another post).

<[email-masked]> wrote:
> similar properties of  case in ASCII characters, ...

No, it is not. TC/SC folding is an entirely separate issue to case
folding. As I've pointed out before, it is counterproductive to try to
argue by an analogy that a consensus of the WG does not accept.

- -- 
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: "tsenglm@????.??.tw" <[email-masked]>
Date: Mon, 8 Oct 2001 08:52:22 +0800

----- Original Message -----
From: "David Hopwood" <[email-masked]>
> case for consistency), and *required* features.
              I  think the requirement in case-insensitives for non-US-ASCII
should be specified in applied rang of UNICODE , that is only applied to
"Han" characters only.
> argue by an analogy that a consensus of the WG does not accept.
         Right !  Describing TC/SC with the term "case folding" will
produce confusing .  TC/SC equivalence class will be translated to ACE ASCII
with CASE , so it can be caseinsensitive comparison  and  also be recoveried
to their original scripts form .  In this siyuation , it is very different
from pure-ASCII characters case folding.

L.M.Tseng