Subject: Punycode at ASCII for IDN & MDN via Y2K Project Management

From: linuxa linux <[email-masked]>
Date: Sun, 9 Nov 2008 19:56:42 +0000 (GMT)

Please read response below.  

I am not a technical expert, thus my understanding
could be flawed, thus I would like to say sorry for any
errors throughout this. 

Regards

Meeku

--- On Tue, 4/11/08, Ruszlan Gaszanov <[email-masked]> wrote:

> From: Ruszlan Gaszanov <[email-masked]>
> Subject: RE: Solutions to the IDN Problems Discussed
> To: [email-masked]
> Cc: [email-masked]
> Date: Tuesday, 4 November, 2008, 11:34 AM
> > There is a problem with solution #1 - it already
> > exists :) though for semi-ASCII language and
> > Internationalised domain names it does not work :(
> > because I visited this website
> > http://www.nameisp.com/puny.asp and did  an
> experiment
> > with total-ASCII language domain names and the
> > punycode representation was the same as the domain
> > name.  Thus there is a problem with punycode machine
> > code presently, as it "cheats" and does not
> "code" the
> > total-ASCII language domain names like it does with
> > semi-ASCII language and Internationalised domain
> > names.

......

> Any other implementation would be incompatible with
> existing DNS
> infrastructure and requires developing a completely new
> name-lookup protocol
> as well as setting up a parallel server infrastructure.

Punycode exists at the Whois for Internationalised Domain Names and you could easily put a Y2K project management with a timeline for ending old type ASCII registrations and where new type Punycode registrations would commence at ASCII names.  ASCII names would get processed via the Punycode field like you have with IDN and your previous ASCII field shuts, that's all.  Both systems could exist simultaneously, the new process open and the previous closed yet continuing then later when there's learning curve development you could consider correcting the old type closed ASCII system.  This system would allow registrations that are (1) IDN (Internationalised Domain Name) and also those that are (2) MDN (Multilingual Domain Names).   

> Since such protocol
> would be fundamentally incompatible with any existing
> internet applications,
> new software will have to be developed.  This would
> practically mean
> creating a second Internet. 

Software applications would catch-up to this via the Y2K sort project management and also via market.  Unicode got accepted then Punycode at ASCII registrations compatibility should also get accepted.  

> Considering the cost and time requirements of such a
> project, as well as all
> the confusion and inconveniences the transition would
> cause, I do not really
> believe the user community would benefit from it. In any
> case this kind of
> project is quite beyond the mandates of either ICANN or
> Unicode Consortium.

You have Punycode existing at IDN then you can also use same at ASCII.  Only the registration window get's changed and you have an extended Punycode that also changes ASCII registration into Punycode.  The user community would really become happy because you would get quicker IDN implementation and a new type registration that are Multilingual.  Software application integration would happen early.  This would help those people that speak / write more than one language.  People could then interact better and with virtue atmosphere than before they were able to with only their single language domains and software applications.  You find that there are countries where the railway stations are using their traditional languages as well as the english language.  The world has become more cosmopolitan and thus you need this to happen very urgently.

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Ruszlan Gaszanov" <[email-masked]>
Date: Sun, 9 Nov 2008 21:21:02 +0100

Meeku,

Ok, I could go into more details and explain why your proposal is extremely
problematic from the technical point of view... but I don't believe Unicode
mailing list is the proper place to discuss this topic, since Internet
protocols are not directly related to the Unicode Standard. Standards for
DNS, IDNA and punycode were developed by IETF/ISOC, so this would be much
more appropriate place to take this to. 

Ruszlán

-----Original Message-----
From: linuxa linux [mailto:[email-masked]] 
Sent: Sunday, November 09, 2008 8:57 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Punycode at ASCII for IDN & MDN via Y2K Project Management

Regards

Meeku

......

> as well as setting up a parallel server infrastructure.

Punycode exists at the Whois for Internationalised Domain Names and you
could easily put a Y2K project management with a timeline for ending old
type ASCII registrations and where new type Punycode registrations would
commence at ASCII names.  ASCII names would get processed via the Punycode
field like you have with IDN and your previous ASCII field shuts, that's
all.  Both systems could exist simultaneously, the new process open and the
previous closed yet continuing then later when there's learning curve
development you could consider correcting the old type closed ASCII system.
This system would allow registrations that are (1) IDN (Internationalised
Domain Name) and also those that are (2) MDN (Multilingual Domain Names).   

> creating a second Internet. 

Software applications would catch-up to this via the Y2K sort project
management and also via market.  Unicode got accepted then Punycode at ASCII
registrations compatibility should also get accepted.  

> project is quite beyond the mandates of either ICANN or

You have Punycode existing at IDN then you can also use same at ASCII.  Only
the registration window get's changed and you have an extended Punycode that
also changes ASCII registration into Punycode.  The user community would
really become happy because you would get quicker IDN implementation and a
new type registration that are Multilingual.  Software application
integration would happen early.  This would help those people that speak /
write more than one language.  People could then interact better and with
virtue atmosphere than before they were able to with only their single
language domains and software applications.  You find that there are
countries where the railway stations are using their traditional languages
as well as the english language.  The world has become more cosmopolitan and
thus you need this to happen very urgently.

---

From: "Ruszlan Gaszanov" <[email-masked]>
Date: Sun, 9 Nov 2008 23:21:41 +0100

Meeku,

> all.  

The main point of punycode is that pre-IDN ASCII domains are encoded with
themselves in ASCII while other unicode Characters could be encoded with a
sequence of ASCII characters, so that IDN could be implemented on existing
DNS infrastructure. ASCII domain names *are* in fact punycode domain names
by definition. 

As soon as you want to encode ASCII characters with something else, you'll
need a new parallel DNS infrastructure and at this point a new version of
DNS protocol that works natively with UTF-16 or b64 encoded UTF-16 or UTF-8
(oh, wait, UTF-8 also encodes ASCII characters as themselves) could just as
well be developed. But the bottom line is that there is no way to develop a
"new punycode" encoding ASCII domain names with something else then ASCII
and implement that on existing DNS infrastructure without completely
breaking the Internet, period.  

> management and also via market.  Unicode got accepted then Punycode at
> ASCII registrations compatibility should also get accepted.  

You were complaining yourself in your correspondence with ICANN
representative how slowly IDN are being implemented by software developers
(even though this implementation is a simple matter of adding a
Unicode-to-punycode translation routine, provided the application is
actually using Unicode functions to process text in the first place). Do you
seriously think they would implement faster a new name-lookup protocol that
might require them to completely rewrite large portions of their code? 

> You have Punycode existing at IDN then you can also use same at ASCII.
> Only the registration window get's changed and you have an extended
> Punycode that also changes ASCII registration into Punycode.  The user
> community would really become happy because you would get quicker IDN 
> implementation and a new type registration that are Multilingual.
> Software application integration would happen early.  This would help
> those people that speak / write more than one language.  People could then
> interact better and with virtue atmosphere than before they were able to 
> with only their single language domains and software applications.  You
> find that there are countries where the railway stations are using their 
> traditional languages as well as the english language.  The world has
> become more cosmopolitan and thus you need this to happen very urgently.

Frankly I can't really see the point of all this. The only reason why the
users sometimes need to use "raw" punycode strings is because IDNA is not
properly implemented in all software yet. Once the software catches up, the
users won't really need to care how exactly punycode works. 

Yes, it takes time to implement IDNA to the point where it can be widely
used, like it also took quite some time to implement Unicode in text
processing (even now it is still not implemented in all applications and
some features of Unicode are not implemented at all). Consider btw that the
reason why UTF-8 encoding scheme gained so much popularity is because of its
ASCII-transparency and backward-compatibility with octet-oriented
applications. 

In any case IDNA, as defined by the current standard, can be realistically
implemented much faster and easier then any alternative solution that is not
backward-compatible with current applications and I can't see why you are so
unhappy with it.

Ruszlán

---

From: linuxa linux <[email-masked]>
Date: Mon, 10 Nov 2008 23:15:49 +0000 (GMT)

--- On Sun, 9/11/08, Ruszlan Gaszanov <[email-masked]> wrote:

> Subject: RE: Punycode at ASCII for IDN & MDN via Y2K Project Management
> To: [email-masked], [email-masked]
> Date: Sunday, 9 November, 2008, 10:21 PM

> ......ASCII domain names *are* in fact
> punycode domain names
> by definition. 

That's the problem and the reason for Punycode2 allowing ASCII registrations to be Punycoded via Punicode2.

> DNS protocol that works.......

You got this wrong because when you Punycode via Punycode2 ASCII registrations you will have ASCII letters however they will be in machine  code, same as IDN thus equal virtue and for ASCII registrations to be viewed they will be viewed similarly as IDN (Internationalized Domain Names / Internationalised Domain Names) and here also equal virtue.    

> .......But the bottom line is that there is no
> way to develop a

Again you are putting something which I have not said for Punycode2.  While you wait for learning curve developments, I suggest you use ASCII based letters for Punycode 2 however you machine code the ASCII registrations like you are doing with IDN. 

I am not a technical expert, however based on what I have gleaned can I suggest the 2 IDN algorithms: ToASCII and ToUnicode perhaps would need tweaks hence ToASCII2 and ToUnicode2 with perhaps ASCII registrations needing also an ACE sort prefix, say yn-- similar to xn-- that are put for IDN.  This development could then allow MDN (Multilingual Domain Names) that would help the users that are multilingual / would like multilingual text at domain name platform. 

I hope this signals to you the urgency that is required for implementing.

Regards

Meeku

---

From: linuxa linux <[email-masked]>
Date: Tue, 11 Nov 2008 09:09:36 +0000 (GMT)

Further to what I wrote yesterday, "the 2 IDN algorithms: ToASCII and ToUnicode perhaps would need tweaks hence ToASCII2 and ToUnicode2 with perhaps ASCII registrations needing also an ACE sort prefix, say yn-- similar to xn-- that are put for IDN.  This development could then allow MDN (Multilingual Domain Names) that would help the users that are multilingual / would like multilingual text at domain name platform."

You can have for MDN another ACE sort prefix, say zn-- to distinguish them from IDN and ASCII registrations.

Regards

Meeku

--- On Mon, 10/11/08, linuxa linux <[email-masked]> wrote:

> From: linuxa linux <[email-masked]>
> To: [email-masked], [email-masked]
> Cc: "Ruszlan Gaszanov" <[email-masked]>
> Date: Monday, 10 November, 2008, 11:15 PM
> That's the problem and the reason for Punycode2
> allowing ASCII registrations to be Punycoded via Punicode2.
> 
> > need a new parallel DNS infrastructure and at this
> point a
> > new version of
> You got this wrong because when you Punycode via Punycode2
> ASCII registrations you will have ASCII letters however they
> will be in machine  code, same as IDN thus equal virtue and
> for ASCII registrations to be viewed they will be viewed
> similarly as IDN (Internationalized Domain Names /
> Internationalised Domain Names) and here also equal virtue. 
>   
> 
> > "new punycode" encoding ASCII domain names
> with
> > something else then ASCII
> > and implement that on existing DNS infrastructure
> without
> > completely
> Again you are putting something which I have not said for
> Punycode2.  While you wait for learning curve developments,
> I suggest you use ASCII based letters for Punycode 2 however
> you machine code the ASCII registrations like you are doing
> with IDN. 
> 
> I am not a technical expert, however based on what I have
> gleaned can I suggest the 2 IDN algorithms: ToASCII and
> ToUnicode perhaps would need tweaks hence ToASCII2 and
> ToUnicode2 with perhaps ASCII registrations needing also an
> ACE sort prefix, say yn-- similar to xn-- that are put for
> IDN.  This development could then allow MDN (Multilingual
> Domain Names) that would help the users that are
> multilingual / would like multilingual text at domain name
> platform. 
>

---

From: "Ruszlan Gaszanov" <[email-masked]>
Date: Tue, 11 Nov 2008 10:36:22 +0100

> That's the problem and the reason for Punycode2 allowing ASCII 
> registrations to be Punycoded via Punicode2.

This is called *backward compatibility* and this is what permits punycode registrations to be implemented on the DNS infrastructure without messing up the registrations that have been there for decades.

> You got this wrong because when you Punycode via Punycode2 ASCII 
> registrations you will have ASCII letters however they will be in machine  > code, same as IDN thus equal virtue and for ASCII registrations to be 
> viewed they will be viewed similarly as IDN (Internationalized Domain 
> Names / Internationalised Domain Names) and here also equal virtue.

ASCII is also *machine code* for goodness sake! You just do not see it as machine code because virtually all software knows how to translate it to something you can read. Any information stored on computers and transmitted over digital networks is *machine code* - it is only a matter of whether your software can present this or that machine code in human-readable form or not.

>> and implement that on existing DNS infrastructure without
>> completely breaking the Internet, period.  
>
> Again you are putting something which I have not said for Punycode2. 
> While you wait for learning curve developments, I suggest you use ASCII 
> based letters for Punycode 2 however you machine code the ASCII 
> registrations like you are doing with IDN. 

Yes, this is exactly what your proposal *implies*, even though you don't realize it due to the lack of basic understanding of how computers and the Internet work. You simply don't realize that you can't just update existing registrations to new format instantly on millions of DNS servers all over the World operated by different organizations. If ICANN starts doing that, the whole domain-name-lookup infrastructure will submerge in complete chaos for months, which would render the Internet virtually unusable. 

> I am not a technical expert, 

This is exactly your problem - you are messing around with staff you don't have the slightest idea about. I really suggest you leave it to those who are *technical experts*. The *only* problem with IDNA right now is the scarcity of proper software implementations. There are no other problems, really. 

Ruszlán

---

From: linuxa linux <[email-masked]>
Date: Tue, 11 Nov 2008 20:20:16 +0000 (GMT)

--- On Tue, 11/11/08, Ruszlan Gaszanov <[email-masked]> wrote:

> Date: Tuesday, 11 November, 2008, 9:36 AM

> .......... without messing up the registrations that
> have been there for decades.

The proposal is for new registrations, why twist the issue?  Previous registrations would become sort after learning curve developments like I said to you.

> ASCII is also *machine code* for goodness sake! You just do
> not see it as machine code because virtually all software
> knows how to translate it to something you can read. Any
> information stored on computers and transmitted over digital
> networks is *machine code* - it is only a matter of whether
> your software can present this or that machine code in
> human-readable form or not.

You are putting a molecular backend eye to ASCII, when you know quite well we are discussing from a user and practical layer, see http://en.wikipedia.org/wiki/Image:ASCII_full.svg  That image shows you "Complete set of printable ASCII characters" and the letters are  roman/latin based letters.  These and a few symbols are what the frontend internet/web user sees / is able to see at the frontend layer.  I am concerned about the nepotistic network that has developed where a shortcut is being given to ASCII roman/latin character based language at the frontend layer however for the non-ASCII based languages the user gets an almost backend / machine code service.  Thus the proposal is to give a equal field where all users get a frontend layer service.  This proposal also would bring about MDN (Multilingual Domain Names) an issue that you are totally ignoring.

> .......you can't just update
> existing registrations to new format instantly on millions
> of DNS servers all over the World operated by different
> organizations. If ICANN starts doing that, the whole
> domain-name-lookup infrastructure will submerge in complete
> chaos for months, which would render the Internet virtually
> unusable. 

However you are accusing without any technical basis and all your arguments are FUD (Fear, Uncertainty and Despair).  You know that IDN is based on ASCII machine code thus non-IDN / ASCII registrations should also use ASCII machine code.  You want ASCII at the frontend however you should not have a nepotistic service, quite the opposite you need to implement an equal service to all users at the frontend layer.  Thus you need to put the equal service for all users not that you give one user class a poor frontend layer that's almost backend machine code and another class a rich frontend layer.  Then there is a class that want MDN (Multilingual Domain Names) however you are basically say don't give them any service.  Thus your proposal is a nepotism one where only close conspiratorial charactered friends get a real frontend service and those that are not have to become close conspiratorial charactered friends.  This is then your goal at the internet/web, it
 also then also related to your passive/active goal beyond internet/web technical activities. 

Regards

Meeku
http://twitter.com/nepotism