Subject: [idn] SLC minutes

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 21 Dec 2001 18:58:33 +0800

Scribes Notes for IDN WG Sessions at IETF 52 in Salt Lake City
David Lawrence and Cricket Liu

In these notes, when "(?)" appears it means I was not entirely clear
on what was said.  Some personal names might also be misspelled; my
apologies.

Note that although notes were taken on the presentations, they are not
entirely complete.  The full presentations are at http://www.i-d-n.net.

================================================================
Monday, 10 December 2001, 1300-1500

Usual introduction of chairs/website/mailinglist.

Agenda bashing:
 * Paul Hoffman wondered why tsconv was on the agenda when it had been
   declared on the mailing list as being out of scope.
 * James Seng asked whether the group wanted to remove the tsconv
   presentation from the agenda.  Not much feedback, decided to have
   the discussion anyway.
 * Paul Hoffman would like to discuss draft-hall-dm-idns even though
   the author was not present.

================

Marc Blanchet - WG document status

* requirements
  - refer to statement sent
  - agenda item
* idna
  - minor rev, ready for last call
* nameprep
  - author rev, then last call
* amc-ace-z
  - ready for last call
* (?)
* tsconv
  - refer to statement sent
  - agenda item
* jpchar
  - expected to be withdrawn by authors
  - moving the issue to a higher layer
* hangeulchar
  - refer to statement sent
  - agenda item
* draft-hall-dm-idns
  - needs more work
* aceid
  - on hold

* lsb-ace
  - Chairs see no consensus in the wg to add this to the architecture;
    propose to drop from document pool
  - Vote:
    Have enough to information make decision?  => No people said they
did not.
    Drop it? => Vast majority of room says yes.

* hangeulchar
  - Chairs along with Area Director advice have concluded that this
  work is not within IETF competence and should be pursued in other
  organizations.
  - Discussion:

    Soobok Lee: Could we wait to decide whether to drop it?
    James Seng: idn wg does not fix problems in other organizations
standards.
        Also, the group does not have the expertise in order to even
        determine whether this is a real problem, much less how to
        fix it.
    Marc Blanchet: Dropping a document from this particular group is
        not a comment on the value of the work.
    Paul Hoffman: It is not clear whether this can be fixed in Unicode
        according to their rules.  Could wait to find this out, but I
        propose we do not.  Even have disagreement among experts as
        to whether we need this.
    Dave Crocker: Always pieces of tech outside our work that we need
        to incorporate but are not quite the way we want them.  If you
        think of this as being like changing ethernet, you see it is
        really not the place for IETF to deal this.
    Soobok Lee: By ignoring the problem we are making a decision.
    James Seng: We can not really determine whether NFKC is broken, we
        just do not have that expertise.  We can only either reference
        it or not reference it.
    Paul Hoffman: To my understanding, the errors have been there for
five
        or six years at least but changing it has not even been
        formally proposed to the Unicode consortium, waiting for that
        to happen and then action to be taken could well mean we'll
        be waiting for years.
    Rick Wesson: This really is Unicode's realm, we should drop it.
    Soobok Lee: This is unacceptable, you are not experts but you are
        still making a decision to ignore this problem.
    Thomas Narten: We have not even made the determination that it is
        a problem because we just do not have the expertise.
    Michel Suignard: Please bring this to us at Unicode to consider.
    Dongman Lee: If the current proposal of nameprep cannot solve this
        problem why do we even have nameprep to deal with localization
        issues?
    Paul Hoffman: Because we can still do a very good job with the
        tools we are given.  Normalization is not only imperfect for
        Hangeul, but also other scripts.  Yet still everyone has been
        saying they want imperfect normalization because it generally
        does help the goal of being able to do exact matching of names
        in the DNS.
    Soobok Lee: I don't want to change Unicode normalization, I just
want
        to bypass them.
    James Seng: We consider that to be the same thing in practice.
    Dave Crocker: We should not be spending 30 minutes on a topic that
        is out of scope.

  - Strawpoll:
    Objections to move hangeulchar out of idn WG? => Only 2 people
objected.

================

tsconv,  Kenny Huang - JET Secretariat

Paul Hoffman: The latest document (version 3) is not in the internet
 drafts directory so most people have not yet read it.
Rick Wesson: How is this different from the conversation we just had
 on Hangeul?
James Seng: This is really three drafts in one, and will be split.
 * Chinese domain name requirements
 * Half self-encoding algorithm
 * Chinese domain name validation

Harald Alvestrand: Do I understand from your slide that you do not
        want to consider HSE anymore?
Kenny: Just for today's talk want to focus on CDN validation, but
       still need to talk about HSE later.

* Table maintenance will be outside of IDNA.
* We consider it to be extension of nameprep's "prohibit" step.
>...

Validation Advantages:
  - reduce 2^n problem to a managable size
  - remove invalid combination of TC-SC domain names
  ... (Scribe: Sorry I missed this, I do not mean to imply there are no
       advantages of merit, I simply did not get them down. See ppt
       on http://www.i-d-n.net/)
Validation Disadvantages:
  - Security
    Changing the function of a critical resource like DNS has security
    implications.
  - Table management:
    Outside of the architecture, but its proper management is critical
    to the working of the architecture.

================
Against tsconv - Shuichi Tashiro

Keep it Simple!
Do not put local rules into global standard.

TC<->SC conversion is a local issue.
* In general, SC are not recognized by mane people outside of mainland
  China, so very local issue.
* Some SC's shapes are identical with unrelated characters, because of
  CJK unification.
  - For example, U+673A has a meaning different in Japan from China
  mainland.   The meaning of China's U+673A would be represented by
  U+6A5F in Japan.

* One to N mapping, one simplified mean many different traditional char.

Global standard should be global.

Applications and registration rules can be localized, but domain name
must be global.

Paul Hoffman: We essentially just had two presentations on different
issues.  I want to address the first one.  It proposes an essential
change to either IDNA or nameprep that would be restrictions on naming
(mixing Japanese/Chinese/Korean Han characters) that would not exist
for any other set of scripts.
>...

Edmon Chung: <Some comment I did not quite get the point of about how
TC/SC does not actually prohibit mixing the way Tashiro-san suggested.>

Marc Blancet: Chairs statement:
  The chairs along with Area Director advice have concluded that all
  parts of this work is outside of the scope of the IDN WG.  The parts
  of this work that fall within IETF scope should be proposed for
  inclusion in other IETF efforts, suych as irnss.

  Kenny Huang: Since people have not seen the -03 draft and it is
    about to be split into three parts it is too early to make this
decision.
  Paul Hoffman: What we might want to do is drop it all now but keep
    open the possibility that if some parts have been sufficiently
    broken down into issues relevant for this group then accept them
    back in.
  John Klensin: There are a number of pieces of work here that are
    very, very important that may be within IETF scope but are not
    within the IDN group scope.  People who want to pursue it should
    work with the IAB/Area Directors to find the appropriate home for
it.
  Rick Wesson: Agree with John, disagree with Paul, let's move this out.
  Harald: Let me advertise the new intloc group which has been formed
    to deal with many of the rats that have been uncovered through
    work in the IDN group.
  Erin Chen: Why not move all of the prohibit function of nameprep to
    other working groups?
  Paul Hoffman: Nothing we deal with in nameprep is about locality.  If
you
    find things in it that are location based, please bring it to the
    list, because we really want it to be only about
    internationaliztion, not localization.
  Ted Hardie:  I think you have made an absolutely critical point here
    but I think you have not taken it far enough.  Yes, all of the
    people in the world will be using Chinese domain names.  But they
    will also be using Japanese and Korean.  However, since CJK
    unification what you want to do is just not possible base on code
    points alone.  You need data external to the characters in order
    to determine the meaning.  What you want to do is valid and
    important but it just does not fit within this group.

* Any objection (to moving it out)? => 5 people opposed.
  In favor? => Clear majority of room.

================
requirements doc

Marc Blancet:
  Chairs with Area Directors have concluded that the requirements are
  outdated, no longer in sync with wg activities, and have some
  technical errors.  Rather than attempt to fix the document, we
  propose to drop the document in its current form and replace it with
  a new short document that captures the approach the idn wg is taking
  and what we have learned about the problems we are facing.  We
  expect it to be done within a short time, just a few weeks.

* Questions:
  - Do people agree that requirements document is outdated, no longer
  in sync with wg activities and has some technical errors?

  Zita: I somewhat object to the wording of the statement since we
    have been trying to keep it in sync and have found that was a moving
    target.  Maybe the old one should become an FYI while a new one is
    created.
  Paul Hoffman: I propose that we only do a requirements document if
    it will truly be useful to people, unlike some of the existing IETF
    requirements documents, which are pretty useless.
  John Klensin: The best document would be to have a document that
    includes all of the history of addition and removal of
    requirements as to why various requirements were added or removed.
    This would be an immensely useful document.
  Paul Hoffman: I basically agree, but observe that has failed in the
    past with things like RFC 2821 -- it didn't stop the rat holes
    from being re-opened.
  Rick Wesson: We shouldn't do the history thing, it has never really
    worked for us and takes too much time.  Also seems kind of stupid
    to come up with a requirements document after we've already come
    up with the standard that the requirements are supposed to lead,
    so I propose we just drop it.

  Vote: Agree? => Couple dozen people.
        Disagree? => No one.

  What should we do?
  1. Drop document, no replacement.     -> 12 people
  2. Fix current document.              ->  2 people
  3. New short replacement document.    -> 20 people

  Current document will be dropped, will bring to mailing list whether
  to have a new document that would capture the approach the idn wg is
  taking and what we have learned about the problem.

* Interested authors should contact co-chairs

================
Marc Blanchet: WG Next Steps

* Last Calls:
  - idna
  - nameprep
  - amc-ace-z

* Verify on mailing list if we want to do a replacement of
  requirements document.

================
Discussion on Eric Hall's dm-idns draft.

Paul Hoffman: This is basically IDNA plus UTF-8 on the wire using
EDNS-0.  The docucment does not describe in what way this is better
than IDNA, however, and I would like to understand from its 7
supporters, if any are in the room, why it is better.

James: How many people have read the draft?  Of those who have not,
why didn't you?

Rick Wesson: Didn't see it in the WG web site or the document pool.

Harald: Didn't read it because I saw the title.

>...

Harald: We are having a lot of comments on process and none on the
actual document, so I recommend that we close the discussion.

With that, the discussion was closed and the meeting ended.

---

From: "Edmon" <[email-masked]>
Date: Fri, 21 Dec 2001 19:33:23 -0500

> TC/SC does not actually prohibit mixing the way Tashiro-san suggested.>

What I meant is that one of the misconceptions about TC/SC mapping is that
it prohibits the use of one of the mapped character, but that thinking is
not true.  For example, if a TC or SC character is mapped to T/S', a
registrant or a user can still use a domain that is in the form:

<TC><SC><TC>.example

It simply means that during matching within the DNS,

<T/S'><T/S'><T/S'>.example

will be used. So, even if a person typed in <TC><TC><TC>.example, it will
still match with <T/S'><T/S'><T/S'>.example.

This is the same as my thinking about LGC (Latin/Greek/Cyrillic) mapping,
that is

<ALPHA><a><A><alpha>.example

will be matched as

<a'><a'><a'><a'>.example

So, we can really fulfil the spirit of Nameprep that: "The user should not
be limited to only entering exactly the characters that might have been
used, but to instead be able to enter characters that unambiguously
[represents] the characters in the [perceived] host name.

Perhaps this issue (what I call, Character Equivalence Mapping) will be
discussed in other wgs but I just want to clarify what I meant during the
SLC-IDN meeting and that I think it is important for the usability of
multilingual domain names when they are deployed.

Edmon