I have spoke to both Jefsey & Rick on this. Certain words Rick used was in humor rather than meant as a personal attack, altho his point is well-taken.
As such, on Jefsey's request, I am writing this mail to close this thread. -James Seng ----- Original Message ----- From: "Rick Wesson" <[EMAIL PROTECTED]> To: "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, September 18, 2002 12:04 PM Subject: Re: [idn] > > Ok I haven't made a post for some time, i hope this one makes up for it. > > comments in line... > > -rick > > On Sat, 14 Sep 2002, JFC (Jefsey) Morfin wrote: > > > > <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? > > all other participitants understood the terms as did the IESG when the wg > was chartered. This is the first note I've read bashing a charter > developed over 3 years ago. > > > > > <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). > > The IETF didn't send out a questionnaire to see if TCP would be best over > IP. The IETF does not send out questionnaires. > > > 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. > > IETF standards do not impose, that is for people to do. IETF documents > stand for themseleves on the mantle of the participiants that wrote them. > > > - Is this an acceptable approach? > > yes, you provide no alternative. > > > - Is it technically feasible? > > it appears to more successfull than any other technology built by humans. > > > > > <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. > > out of scope for the IETF. If we would have disussed Intelectual Property > in RFC883 we would not be communicating via email today. Its not the > IETF's problem, see how governments have delt with ENUM. > > > 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. > > smoke less grass, or mabe move from hash to grass. I prefer hash but it > fucks up my writing too. > > > 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. > > out of scope, IDN deals with whats on the wire, not whts on the disk > drives. Formats of application data is not in scope for this working > group. Pick an open source application and write the code, or roll your > own ( you can sing allong if you like... roll roll roll your joint gentley > down the stream...) > > > > > <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. > > well call me limited, you're just going to have to restate that one for > me. as for the quote, dam right we are not making any more global > monopolies or borides that need to manage or administrer them. proven to > be a bad idea. > > > > > <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? > > ok, clue me on the solution, you provide no refrence, we require at least > an Internet-Draft. You appear to be capable of writing one. Without an I-D > you have no soap-box to stand on in the IETF. > > don't like that, then go play at the ITU. > > > > > <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. > > you sound like you want to chair the IETF, maybe you should talk to Harold > about that... > > > > > <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? > > ok, i can actually add some content here insted of wipping you with a wet > noodle. We did discuss the requirements draft, we had one, it expired. the > group discussed writing one on how we got to the place we were; atlast we > decided that documenting the convluted process we went through could a > destructive process and not one willing soul stood up to take on the > project. > > so we won't meet that goal. sure it sucks, but sometimes working groups > don't meet all their goals. the process is imperfict -- we are humans, > should you expect more? > > > > > <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". > > I'd propose you read the archives of the list and the numerous I-Ds > proposed. there was even a design team that reviewed many of the proposals > and wrote up their view. It was posted to the list, read the archives. > > Again, make a draft, post it to the list; we don't write them for you. > > > > > <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 . > > no. > > > Question: would that effort of ours be of any worth to you? > > If yes, I will try. > > I don't think your effort would be of any use at all. I care not what > lawyers think of this. It is not the IETFs job to reach out an educate > those, like you, that need be educated; especially when they have been > instructed on how to self educate and have chose not to do so. > > Making posts such as you have do nothing for us, this is not constructive, > you offer us nothing but words, unconnected dots. > > -rick > > > >
