CVS libidn/doc/specifications

[libidn-commit]

Update of /home/cvs/libidn/doc/specifications
In directory dopio:/tmp/cvs-serv4419

Added Files:
        draft-ekrema-smldn-00.txt 
Log Message:
Add.


--- /home/cvs/libidn/doc/specifications/draft-ekrema-smldn-00.txt       
2004/11/18 22:16:49     NONE
+++ /home/cvs/libidn/doc/specifications/draft-ekrema-smldn-00.txt       
2004/11/18 22:16:49     1.1
Standardization of Multilingualizing            Rifaah Ekrema
Domain Names( MLDN)                             Mohamed A. Elhamalaway
[Target Category: Standards Track]              Omar Bakleh
                                                Khaled Alahmad
<draft-Ekrema-smldn-00.txt>                     Fidaa Al-Jundi
Expire: 8-April-2005                            Mhd. Elfatih Altijani

"By submitting this Internet-Draft, I certify that any applicable 
patent or other IPR claims of which I am aware have been disclosed, 
orwill be disclosed, and any of which I become aware will be 
disclosed,in accordance with RFC 3668."


        Standardization of Multilingualizing Domain Names( MLDN)


Status of this Memo:
        This document is an Internet-Draft and is in full conformance with all 
        provisions of Section 10 of RFC2026 except that the right to produce 
        derivative works is not granted.

        Internet-Drafts are working documents of the Internet Engineering Task 
        Force(IETF), its areas, and its working groups. Note that other groups 
may 
        also distribute working documents as Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of six months 
and 
        may be updated, replaced, or to be made obsolete by other documents at 
any 
        time. It is inappropriate to use Internet-Drafts as reference material 
or to 
        cite them other than as "work in progress.

        The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt

        The list of Internet-Draft Shadow Directories can be accessed 
        at: http://www.ietf.org/shadow.html.
        
        Copyright Notice:
        Copyright (C) The Internet Society (2004).  All Rights Reserved. 
         
Abstract:
        Until now, many standards was issued to standardize creating and 
managing 
        IDN (Internationalized Domain Names), all those standards discussed the 
        technical problem issued from the need to keep the structure of the 
internet 
        that uses standard (ASCII) domain names untouched; using this pretext 
those 
        standards forced  some rules that make lingual grammars for some 
languages 
        not respected on the language domain names.

        This document will try to define a new type of domain names called the 
        "multilingual domain names" (MLDNs) , these names are supposed to 
respect 
        the grammatical and spelling of every language so at least, every 
language 
        can use the words of its own dictionary in its own domain names.
        The system supposed to manage the reservation and the resolution of the 
new 
        domain names (MLDNs) must also respect the infrastructure of the 
traditional 
        domain names system (DNS) untouched so it will not jeopardize the 
stability  
        of the internet.
        In the rest of the document we will refer to that system by MLDNS 
(Multi-
        Lingual Domain Names System).  

        MLDNS Will use the same large repertoire of Unicode characters to 
compose 
        its domain names and that means the use of none-ASCII characters, this 
use 
        must allow all languages to have their domain names that respect their 
        language properties and rules. Also it must depends on a technique that 
        keeps the stable DNS system untouched.

        Comments on this document can be sent to the authors at:
        address@hidden

Table of content:
        1.Introduction
        2.Problem Analysis
        3.Introducing MLDN
        4.ML Recommendations
        5.MLDNA
        6.Full Copyright Statement:
        7.References
        8.Terms
        9.Authors


1. Introduction:
        Internationalized domain names (IDN) are still a subject of a great 
        debates between technical associations and organizations, each one 
        tries to create new standards that controls the new addressing mass 
        that will be launched by the new unlimited possibilities of non ASCII 
        domain names, all those standards agree on one major issue that is 
        keeping the current stable DNS system  unaffected by the new era of 
        using UNICODE domain names.

        Focusing on technical issues in all drafts and RFCs talking about IDN 
        imposed a lot of natural language usage limitations, and these 
        limitations prevent national languages from using all their characters 
        and all their vocabulary and their sentences structure in their 
        national domain names. And in some times those limitations force the 
        user to use domain names that does not satisfy the grammars of the 
        natural language.

        For example, the prevention of using space character in domain names 
        will force languages that contain joint characters (characters that  
        change their shapes according to their place in the word) to have un-
        readable domain names, the suggested solution is to use dashes to 
        separate between words consists of joinable characters and this is not 
        acceptable grammatically. like Chinese and Arabic languages as  RFC 
        3743 and internet draft "draft-bakleh-reg-adm-acg-apu-00.txt".


2. Problem Analysis:
        The problem mentioned in the introduction is caused by the fact that 
        IDN rule makers have prepared general studies to control the creation 
        of IDNs, such studies does not take in consideration the properties 
        and the specialties of each language and as a result we have 
        Internationalized domain name that does not satisfy the user needs of 
        having user friendly domain names which are familiar to his own 
        national language which is called multilingual domain name MLDN. 

        This can be clearly seen by the fact that we have a UNIQUE nameprep 
        proposed to test all the domain names in the world in all the 
        languages of the world nations, and this nameprep is recommended to be 
        the first layer to handle the domain name and decide wither it can be 
        used as an IDN or not. which isnÆt a technical need to keep the 
        current DNS stability and the network infrastructure untouched.
 

3. Introducing MLDN:
        The term MLDN stands for MultiLingual Domain Names, the only 
        difference between IDN and MLDN is that MLDN allows each language to 
        implement its own nameprep to test its own domain names, and it allows 
        each language to put syntactical rules of composing its own domain 
        names. And so it will be the sole  responsible of determining its 
        domain names method and nameprep method managing its reservation and 
        registration systems, but it is NOT allowed to each language to have 
        its own ACE (ACII Compatible Encoding) to represent its domain names.
  
      
4. ML Recommendations:
        MLDN must have several namepreps but a unique ACE to encode the 
        national domain name. based on these MLDNs recommendations:

        1.MLDNA must not use more than one lingual character set in  any part 
          of MLDNs.

        2.The lingual nameprep must gives the possibility to use all 
          languageÆs words in the domain name system from both technical and 
          grammatical point of view.
        
        3.MLDNA reservation must have the technical possibility to register 
          any domain name agreed by its nameprep method.

        4.MLDN must give each nation a full control to determine its lingual 
          nameprep and its elements (the UNICODE characters set and its 
          (MLgTLDs) Multilingual generic Top Level domain names and its 
          (MLccTLDs)  Multilingual country code Top Level Domain Names) to 
          be the UNIQUE  choice to use in its domain names. The nation's 
          control must be submitting by the accreditation of its official 
          countries through its ccTLDs authorities as the sole publisher 
          through ICANN and IANA.

        5.MLDN must create  an smart ACE based on variant characters 
          encoding according  its using rates to have  longer MLDNs more 
          than the PUNYCODE gives.
                       
5. MLDNA:
        To realize this goal we have to take the previous RFCs talking about 
        IDN (Internationalized domain names) in consideration, specially RFC 
        3490 talking about IDNA (Internationalized Domain Names in 
        Application) this RFC offers a reasonable solution to realize non 
        ASCII domain names system based on the current DNS system.
        IDNA suggests that the following structure to realize IDN system.
        

                            +------+
                            | User |
                            +------+
                               ^
                               | Input and display: local interface methods
                               | (pen, keyboard, glowing phosphorus, ...)
           +-------------------|-------------------------------+
           |                   v                               |
           |          +-----------------------------+          |
           |          |        Application          |          |
           |          |   (ToASCII and ToUnicode    |          |
           |          |      operations may be      |          |
           |          |        called here)         |          |
           |          +-----------------------------+          |
           |                   ^        ^                      | End system
           |                   |        |                      |
           | Call to resolver: |        | Application-specific |
           |              ACE  |        | protocol:            |
           |                   v        | ACE unless the       |
           |           +----------+     | protocol is updated  |
           |           | Resolver |     | to handle other      |
           |           +----------+     | encodings            |
           |                 ^          |                      |
           +-----------------|----------|----------------------+
               DNS protocol: |          |
                         ACE |          |
                             v          v
                  +-------------+    +---------------------+
                  | DNS servers |    | Application servers |
                  +-------------+    +---------------------+
        
   This structure gives the possibility to realize what we have already 
   called MLDN, according to this RFC each IDN system will have its 
   toASCII function or layer that grantees the conversion of UNICODE 
   domain names into standard domain name. the main obstacle in IDNA that 
   prevents the realization of MLDN is the existence of the UNIQUE 
   nameprep in the toASCII layer. 

   So the idea of MLDNA is to use the IDNA structure but to let each 
   language build its own nameprep and us it in the toASCII layer. 
   Allowing the national language users to build its nameprep will permit 
   them to put linguistic rules to control the creation of the languages 
   national domain names according to its grammatical and orthographical 
   rules. And this will guarantee the creation of user friendly MLDNs 
   with the full respect to both internet current  infrastructure and 
   national languages needs.


6. Full Copyright Statement:

        Copyright (C) The Internet Society (2004).  This document is subject to 
the 
        rights, licenses and restrictions contained in BCP 78 and except as set 
forth 
        therein, the authors retain all their rights. 
         
        THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN ARE PROVIDED ON AN 
"AS IS" 
        BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS 
SPONSORED BY 
        (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 
DISCLAIM 
        ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
WARRANTY 
        THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 
ANY 
        IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 
PURPOSE.  
         
        DISCLAIMER 
         
        THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN 
"AS IS" 
        BASIS AND THE AUTHORS, THE ORGANIZATION THEY REPRESENT OR ARE SPONSORED 
BY, THE 
        INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
        WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
WARRANTY THAT 
        THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 
IMPLIED 
        WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


7. References:
   [RFC3492]
        Punycode: A Bootstring encoding of Unicode for Internationalized 
        Domain Names in Applications (IDNA)A. Costello Univ. of 
        California, Berkeley Category: Standards Track, March 2003

   [RFC3491]:
        Nameprep: A Stringprep Profile for Internationalized Domain Names 
        (IDN) P. Hoffman, IMC & VPNC M. Blanchet, Viagenie Category: 
        Standards Track, March 2003.

   [RFC3490]:
        Internationalizing Domain Names in Applications (IDNA) P. 
        Faltstrom, Cisco, Category: Standards Track P. Hoffman, IMC & 
        VPNC, A. Costello, UC Berkeley, March 2003. 

   [RFC3743]:
        Joint Engineering Team (JET) Guidelines for Internationalized 
        Domain Names (IDN) Registration and Administration for Chinese, 
        Japanese, and Korean.

8. Terms:
        MLDN: Multi Lingual Domain Name.
        IDN: Internationalized Domain Name.
        IDNA: Internationalized Domain Name in Application. (RFC 3490)
        Nameprep: A Stringprep Profile for Internationalized Domain Names; 
draft-
        ietf-idn-nameprep, Feb 2002, Paul Hoffman, Marc Blanchet, work in 
progress.
        Punycode: An encoding of Unicode for use with IDNA, 
draft-ietf-idn-punycode, 
        Feb 2002, Adam M. Costello,   work in progress.

9. Authors:
   Rifaah Ekrema:
        AIETF Organization
        P.O: 30775
        Damascus, Syria.
        Phone: +963 93 611087
        Fax: +963 11 2238490
        address@hidden

   Omar Bakleh:
        Damascus University, Damascus, Syria
        Phone: +963 93 363004
        Fax: +963 11 2139804
        address@hidden
        
   Mohamed A. Elhamalaway: 
        Al-Azhar University, Systems & Computers Engineering dept.
        Cairo, Egypt.
        Phone: +20 6321465
        Fax: +20 6377446
        address@hidden
        

   Fidaa Al-Jundi: 
        Nozum Alhausabah Company,
        Dubai, UAE.
        Phone: +971 50 6507282
        address@hidden

   Khaled Alahmad:
        High Institute of Applicable Science & technology,
        Damascus, Syria
        Phone: +963 93 330345
        address@hidden

   Mhd. Elfatih Altijani:
        Technical Manager, Sudatel,
        Alkhartoum, Sudan.
        Phone: +249 12 390573
        address@hidden