Re:

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
>
>
>
>