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.
