Re:
"James Seng" <[email protected]>
| Newsgroups | gmane.ietf.idn |
|---|---|
| Message-ID | <002e01c25c16$bb735950$6000a8c0@JSENGTOSHIBA> |
Jefsey, Offline again: I really really advise you to go to www.i-d-n.net and revise the archives we have for the last 3 _years_. -James Seng ----- Original Message ----- From: "JFC (Jefsey) Morfin" <[email protected]> To: <[email protected]> Sent: Sunday, September 15, 2002 12:17 AM Subject: [idn] > I was mislead by the text of the scope into believing that seeked user > inputs could be formulated in the user plain language. I understand now > that we developers, users, DNS Managers are to follow the IETF rules to > permit this WG to fulfill its mission to repot on us. Because these rules > prevent external pressures and help you determining real life needs. > > I therefore try to gather enough expertises in these areas and to make them > write a draft document. I have no resource for such an endeavor and very > little time. So I will continue only if it would be of help? > > The first inputs and meetings, lead to questions that a reveiw of the WG > mandate helps listing. What do you think covered, you want to disregard and > you would wish we focus on? > > <quote> > The goal of the group is to specify the requirements for internationalized > access to domain names and to specify a standards track protocol based on > the requirements. > </unquote> > > We have problems with an International Standard constistent definition of > "internationalized", "access" and "domain names". Is there an IETF, ISO, > CEI definition we could use? Is there a more complete documentation of the > posed problem? > > > <quote> > The scope of the group is to investigate the possible means of doing this > and what methods are feasible given the technical impact they will have on > the use of such names by humans as well as application programs, as well as > the impact on other users and administrators of the domain name system. > </quote> > > this group has determined that Unicode was to be used to support natural > names into the DNS. We do not find a discussion of the alternatives. A part > from being in the charter, it is the only way to foster innovation and/or > evolutions in continuity. > > our target is to help this group's investigation concerning the impact on > humans and applications as well as on computer and network services > including DNS, OPES, mail, web services ..administrators. > > We understand that no questionnaire has been sent yet to the Internet > community to gather the necessary information and comments. Current group > exchanges show there is a lack of agreement among the WG on the needs and > impacts. Also that "technical impact" is understood in extremely > restrictively (within the proposed solution, not as all the technical > impacts of a proposed solution). > > no user, developer, administrator group should impose its requirements, and > impact the global solution. So we are only ready to share, with other user > groups, in the drafting of a questionnaire to poll the Global Internet > Community. > > - Is this an acceptable approach? > - Is it technically feasible? > > > <quote> > A fundamental requirement in this work is to not disturb the current use > and operation of the domain name system, and for the DNS to continue to > allow any system anywhere to resolve any domain name. > </quote> > > we feel that the currently proposed solution affects the current operations > and management of the DNS system due to: > > 1. the lack of documented separation between the domain name as an > alphanumeric pointer to an IP address, and as a mnemonic. The only current > response are the US ACPA and to some extent the ICANN UDRP. We do not think > they are technical responses matching the IDN additional concerns. > > 2. the non documented (analyze, rational, nature, evolution) introduction > of a "prefix" in DNS names. At minimum we understand it as a second > parallel namespace, unrelated to the first namespace by any existing rule > from the first namespace. But, based upon pragmatic experience, we > understand it as the introduction of a cross hierarchy in the namespace. > > 3. the lack of proposed solution to separate IDN zones in DNS files. > > We may be wrong, but we feel that should the IETF work on the first very > basic point, every other point we rise would be easy to solve, or would > even not exist. > > > <quote> > The group will not address the question of what, if any, body should > administer or control usage of names that use this functionality. > </quote> > > We agree as no one should be made in position to maintain a second DNS > cross-hierarchy. This is why we feel the prefix proposition may result from > some existing administration. The solution should be global. If > pre-existing practices are supported: all the better, but this should not > limit the thinking. > > > <quote> > The group must identify consequences to the current deployed DNS > infrastructure, the protocols and the applications as well as transition > scenarios, where applicable. > </quote> > > As a particular group, we may have a solution to propose. We believe it is > transparent to the existing DNS infrastructure and requires no protocol and > minimal application changes; and no transition as it only calls on > progressives updates of the applications software on a per keyboard basis. > > This proposition would motivate our effort. But our main target would be to > help this group to better understand the needs and the impacts on the > users. How should we proceed? > > > <quote> > The WG will actively ensure good communication with interested groups who > are studying the problem of internationalized access to domain names. > </quote> > > This is the problem we want to help addressing. > For that we need the help and the understanding of this group. > I would suggest that other groups do the same. > > > <quote> > The Action Item(s) for the Working Group are > 1. An Informational RFC specifying the requirements for providing > Internationalized access to domain names. The document should provide > guidance for development solutions to this problem, taking localized (e.g. > writing order) and related operational issues into consideration. > </quote> > > This is where we want to help. > May be as co-author? > > > <quote> > 2. An Informational RFC or RFC's documenting the various proposals and > Implementations of Internationalization (i18n) of Domain Names. The > document(s) should also provide a technical > evaluation of the proposals by the Working Group. > </quote> > > This is where we would like to see our proposition evaluated. This is why > it would be really useful to us if a definition of the different layers > involed could be made. We trust the expertise of this group for the inner > Unicode/Ascii "black-box": we are interested in the management of its "I/O". > > > <quote> > 3. A standards track specification on access to internationalized domain > names including specifying any transition issues. > </quote> > > it seems that a rough consensus here is that a solution could go in > operations and to be tuned further on. This cannot be: one cannot repel > millions of names. To avoid "babelnet" the alternative is: > - to proose a very limited IEFT experiment (aside of the other test beds), > - to get a solution universally endorsed by users, developpers, admins and > lawyers . > > Question: would that effort of ours be of any worth to you? > If yes, I will try. > > thank you. > jfc >