[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Figuring out what can be displayed
What you described (at least the technical part) is quite different from
IDNA so it should not be mixed up with IDNA.
Since you are a probably new to the IETF process (see RFC 2026), let me
repeat the same thing I told others:
The best way to proceed is to document your proposal in an internet draft
and submit it to the IETF. Only then could we have a proper discussion of
You may also want to look at some other drafts the group have seen.
Particulary, John's dnssearch.
----- Original Message -----
From: "JFC (Jefsey) Morfin" <firstname.lastname@example.org>
To: "IETF idn working group" <email@example.com>
Sent: Wednesday, September 11, 2002 9:49 PM
Subject: Re: [idn] Figuring out what can be displayed
> I have discussed here the IDNA issue. I have related with Adam Costello on
> the list and off list and I thank him for that. I have heard the different
> remarks of many. I will now tell you how I will document and implement my
> axcess engine system "IDNA" support.
> I offer that to permit an analysis on a real project. I do not expect to
> criticized on religious/theoretical grounds but to be helped towards a
> better end-user and OPES support, in a way creating the minimum
> or no discrepancy with the standard you propose.
> I do this because I fight for my own business survival in a real
> international world, not as a corporate manager or a distinguished
> academic. I only possibly paid by real customers with real users.
> My premises:
> 1. I live for 25 years (1977) in the international data communications
> world. I always made my money there for ma family, except since I came
> the IP world. I still accept it as a long investment period.
> 2. Since the very beginning I am involved with the international namespace
> (INS). It interconnected in 1984 with DNS (there are some differences in
> perspectives quoted by John Klensin who was not involved here by then but
> has a command of the Internet history. Probably because of the time flow,
> and because when you build a gateway there is by nature a male and female
> perceptions). This is of low interest. What is of interest is the
> experience: we must take advantage from the pros of both sides and avoid
> the cons of both sides (I understand that is what he means). This gives me
> an unique experience about the way the real world behaves; and some more
> intuitive knowledge of the needs and constraints than those who related on
> the matter with Govs, operators, market, corporates, law makers, end
> local tech support, end-application developers. Sorry to quote that: it is
> only to explain why I suppose this mail might be of use.
> 3. for 20 years the only thing which really worked and made the "Internet"
> in most people minds is the DNS part of the namespace. The reasons why it
> works is because it is stable, simple and most of all consistent with
> intuitive addressing feeling.
> I co-created the namespace in a form which developed all over the world,.
> But with a semantic which would NOT have had the same impact as the DNS.
> We started with the root names, then from LEFT to RIGHT (as in a sorts,
> disk directories etc.) we permitted operators to add hostname as an
> extension, then sub-hosts. We created the hierarchy, but it was a mess.
> Because we had no zone (as in IP addresses). What the DNS brought was to
> respond intuitively to the need of the users in sorting out clearly that
> mess. The reversing from right to left at the gateway and the use of the
> "." as a reversing indicator did it all. RFC 920 the "prefix" of the time
> was the suffix ".arpa".
> (When you start with an unique thing you start with two: it and not it.
> is by nature a family and a family grows).
> It did it all, because the resulting addressing logic was brainware
> consistent with postal addressing and EDI rules. Country last. And you can
> keep adding details first. Like on an envelope the name (e-mail name)
> first (and as in the "vielle France" etiquette: the use the "@" [at the
> proper "à Monsieur," place] as it was created for this in Middle-Age (@ is
> latin "ad"). This means a brainware consistent system with an habitus of
> more than 8 centuries.
> We kept BOTH system working. We interfaced a few people to ARPA in right
> left hierarchy and supported in left to right the numeric names X121
> hierarchy. From 1982 to 1986 I carried the same task as IDNA - but the
> other way : instead of expanding from 38 characters to billions, I reduced
> from 36 to 10. For the same public.
> From experience, the reason why it worked (IMHO) is that we adapted to
> least able technology. We were using names and had to support digital only
> addresses. We used "numeric names". But we had all the capacities of the
> names, so when Transpac was only using an IP-address like scheme , we had
> the flexibility of a complete real time, flexible and powerful database.
> we proposed value added services but not a new system.
> I think the only way IDNA can succeed is the same way. Unicode is the
> powerful system: DNS is the less powerful one. I am an seaman: the speed
> a convoy is the speed of the slowest vessel less the zig-zags. IDNA must
> considered as a DNS service, subject to the constants of a dual system.
> IDNA can only be DNS value added, not as an alternative system, even
> embedded.. The only alternative system would be to study, specify,
> experiment a new DNS. IMHO it cannot be done in two minutes (IMO it will
> take years and due to the political implications that it is a big, big
> ahead which will involved 190 countries universities, Telcos, Govs,
> communities). I also think it cannot be done one shot. This is why I
> suggest to look into DNS.2 (improving stabilizing the system, its
> operational architecture, its political insertion, etc... in compatible
> with the current DNS - I do not even know if we need to increase the
> character set). This is why I also work on top of it on extended DNS
> services, like IDNA, authetification, access engines, etc (DNS+). This is
> the rational of the Dot-Root proposition ( http://dot-root.com ) still in
> infancy and only partly documented in English. But with gaining interest.
> So I only consider serious and conform use of the DNS: the rule and the
> bible. Errors/tricks in using it are of no concern to me. Errors and
> do not make the basis for a rule (this is a basis of the Roman Law and of
> social life).
> There is a hierarchy of the addressing information. That hierarchy is
> necessary to get the next info. There is no use to know an ASCII or
> the forename of someone if you do not know the name, the city and the
> country. The way you write that information does not make it different.
> Question: are there existing additional hierarchies in postal (brainware)
> addressing? ie something the mailman need to chose between different mail
> destination - and or mail path?
> - not the title (Mr, Mrs, Dr, M. Mme, Snr, M.M., Her, Esq. etc...)
> - not the type of information: a nickname is accepted as long as the layer
> below accepts it. I mean than "Jack" is accepted for "John" in an Irish
> family and "Jefsey Morfin" will be accepted in the "Morfin" mailbox.
> - partly the service : is it a hierarchy/an added information in the
> hierarchy? Postal Services all over the world use "Port Payé" or "Port
> The same as all the DNS Managers use "MX". The routing: "AirMail" or
> "ParAvion". (note: these hierarchies are not in naming. They are used when
> applying before or in parallel to the routing).
> - the scripting is an intuitive (real) hierarchy: is the scripting local
> the sender, to the sendee or international scripting? Usually only
> international and sendee scriptings are accepted. The place where the
> discrimination is carried is the first point where a scripting is not
> understood anymore. In some cases it can go beyond through an alternative
> path: in adding "c/o some go-between" who will translate.
> 4. access engine. To understand the way I am going to use IDNA+, and why,
> one has to understand the access engine concept. I name and develop
> engines" DNS resolvers which use an extended resolution strategy. For
> example my domain name is http://utel.net . There is no access engine
> implemented there, but http://jefsey.morfin.utel.net could accept the call
> as the default for utel.net and resolve the 3 and 4LD as
> jefsey.morfin.utel.net, morfin.jefsey, jefsey, morfin, vacations etc...
> This kind of OPES provides a directory service but also an easy ULD (upper
> level domains) management system in using LDAP like system or more
> directory solutions, etc...
> This means that I have no problem to introduce transparently punnycode
> support in my existing names. http://U+xxxU+yyyyU+zzzz.utel.net are OK.
> The access engine resolves in two ways. Either as a reroute or as a normal
> DNS server. This depends on the economics and on the user system
> architecture. They are transparent. http://jefsey.utel.net can resolve one
> day as a reroute to http://jefsey.com and the next day as a CNAME for
> http://jefsey.com. I note that the test for a French application supports
> 1.500.000 names with a target for 150.000.000, with some added value
> variations (abbreviations, accents,e ct) what corresponds to billions of
> names. The DNS could not support all this, but provide a stable, simple,
> existing support for the ULDs.
> These access names are either free or cheap and will be legally enforced
> one day (we will support the national IDs, immotic telemates, etc). We
> cannot plan to spend much energy to support billions of names for millions
> of people.
> Obviously these names must be transparent to different accepted writings:
> upper, lower, accentuated cases. "eleve" must be bijective with "élève".
> That engine can to some extend accept the most common typos and the
> sound-alike wording. But it will not easily accept that a French "O" is
> replaced by a Greek "o".
> 5. legal issues. Due to the IETF current lack of documentation between the
> software domain name as an alphanumeric pointer to an IP address, and the
> brainware mnemonic cannonic/alias to a domain name, there are out of
> context laws/jurisprudence such as ACPA, Whois, etc. we must live with.
> I do not want to run into endless UDRPs and "a la Joe Sims" contractual
> issues because a Chinese way to write something will print on all the
> French non-IDNA displays and printers as "iesg-ibm.fr" or as a racist
> Not a minute nor single penny to spend helping other to understand if what
> will legally counts is one or the other formula.
> Now the "Jefsey's solution".
> 6. From all this (and other economy, marketing, social etc... points) my
> implementation and explanation will be as follows.
> a) there is an unique DNS naming sequence. That sequence utilizes the
> International Domain Names System Character set, named "IDNScode". Today
> IDNScode includes 0-9, A-Z dash and dot. Nothing prevents it to be
> by the DNS designers.
> b) the extended-Unicode set (e-Unicode) includes the current Unicode
> version plus the current IDNScode version..
> c) the support of natural Internet names is organized through specialized
> sub-domains the charter of which defines the e-Unicode supported sub-set,
> and the bijective e-Unicode/IDNScode reading/writing function. Their ULD
> (upper level domain) will be of the form ".prefix--suffix.tld", where
> - prefix indicates the conversion system
> - the suffix indicate the used e-Unicode restriction.
> The prefix will be the "iesg--" prefix for the IDNA system. The null
> will default to "IDNScode".
> d) registrations will use current NIC management systems with a
> transwritting using a punnycode routine after a sub-namespace character
> e) abbreviated name presentation will be supported to possibly hide/insert
> the script sub-domain. This will be insured by "prefix--suffix" loaded or
> embedded plug-ins (on the system) or as OPESes.
> 7. I will use the French name "élève" (pupil) fro this discussion, since
> is supported by my keyboard and should probably be by all of yours.
> a) support of international registration by AFNIC : http://eleve.fr
> b) support of the French registration by AFNIC:
> - uppercase scripting : http://ELEVE.FR - existing as http://eleve.fr
> - accentuated lower case : http://élève.iesg--fr.fr
> entered also as :
> - http://eleve.fr (decision to be taken by AFNIC to comply with
> French law)
> - http://eleve.iesg--fr.fr (until the IDNScode == Unicode)
> c) update of the e-Unicode character set
> - one shot ^parallel registration of the new scripting equivalent
> - management of the possible conflicts
> - de registration of the obsolete e-Unicode scripts once every user
> supports the new version.
> d) work to be done to support this service
> - creation of the "iesg--fr" domain name
> - adding of a French character set list in the Punnycode C code.
> - delay to the market: 24 hours after the release of the "iesg--"
> e) user implementation
> - this is transparent to the current situation
> - e-Unicode support can be provided by who wants and different natural
> character sets can be implemented depending on the user keyboard.
> f) legal implications
> - none
> - the e-Unicode scripting is by nature 3+LD names outside of the WIPO
> area of influence.
> - jurisprudence will develop probably on brainware mnemonic second
> level, but it should be related to the documented good, rather than a good
> by itself. if the good is the domain name: the standard UDRP apply on the
> registered DNS entry: nothing changed. If it applies on any other good:
> domain names are not even only more considered as such.
> g) extensibility
> - there is no addition to the DNS which can be as freely extended as
> - there is an unlimited extension of the natural character set through
> the suffix. There an unlimited capacity of extension on the processes
> through the prefix. There is a quasi unlimited capacity of extension
> another semantics.
> h) load
> - the load forecast on the DNS imposed by current IETF proposition may
> be tremendous a TLD may become a new worldwide ".com" with hundred of
> millions of entries, on the whim of a fashion. The sub-domain approach
> obviously permits the transparent load of billions of Internet names.
> - however the load shifts towards the sub-domain information
> within the work frame of the new loads imposed on the root server system
> and on the DNS. This load is to be considered all together with the load
> imposed by Microsoft's "dynamical" DNS management, portables, DNS lookup
> leaks, racing multiple root calls for speed of some resolvers, ENUM
> support, security concerns etc..
> The whole Recommendation is that the Internet Community agrees that a
> domain name including a double dash "--" means a domain name which can
> hidden/created by applications should the corresponding set of recursive
> processes (defined by its charter) it describes, have been applied.
> Some examples:
> - iesg-- : this domain specializes in IDNScode scripts
> - iesg-fr this domain specializes in "French names".
> - fm-- : this domain specializes in telephone follow-me services
> - iesg--fm-fr : this domain specializes in telephone follow-me services in
> French accentuated names.
> - enum--fr: enum names tel://139500510.enum--.fr
> - tel--fr: enum through french name names : tel://eleve.tel--fr.fr entered
> on my mobile as "éléve.fr" that may be transcoded into tel://eleve.fr,
> tel://élève.tel--.fr.fr http://eleve.iesg-tel--fr etc. depending on the
> services organized by the operator.
> I certainly accept that it is rather different from the current wording
> concerns. But I think it is compatible. I hope it may help. I will keep
> posting on the implementation ... as I find the funding.