[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] SLC minutes
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.