Network Working Group Jean-Francois C. Morfin Internet-Draft Intlnet Intended status: Independent submission December 6, 2009 Expires: June 7, 2010 Case sensitive IDNA draft-iucg-punyplus-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 obsoleted 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. This Internet-Draft will expire on January 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Morfin Expires June 7, 2010 [Page 1] Internet-Draft punyplus December 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo documents an IDNA proposition (AKA IDNAPLUS), which supports upper and lowercases and new possibilities for the Internet name space. Table of Contents 1. Introduction................................................... 3 2. Discussion list................................................ 3 3. The Interplus approach......................................... 3 4. Punyplus algorithm............................................. 4 4.1. Support as a regular character........................... 4 4.2. Support through a dedicated format....................... 4 5. Value of the UMI codepoint..................................... 4 5.1. To use a DISALLOWED codepoint............................ 4 5.2. To use an UNASSIGNED codepoint........................... 5 5.3. To use a PVALID codepoint................................ 5 5.4. To register a dedicated codepoint........................ 5 5.5. Solution................................................. 5 6. Naming added services.......................................... 5 7. Further extensions............................................. 5 8. Multilinguistics section....................................... 6 9. Security section............................................... 6 10. IANA section.................................................. 6 11. Acknowledgments............................................... 6 12. References.................................................... 6 Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Morfin Expires June 7, 2010 [Page 2] Internet-Draft punyplus December 2009 1. Introduction According to the current WG-IDNABIS proposal, which is based on the punycode support algorithm, the entries in domain name locations should be subjected to a systematic preceding lowercasing without later restoration. This means that uppercases are not supported on an end-to-end basis and that uppercased domain names are resolved as if they were their lowercase equivalent. Therefore, half of all the characters of the world's alphabets are thereby ignored by the IDNA. The WG-IDNABIS considers this to be perfectly acceptable. The WG-IDNABIS also believes that this does not significantly affect the overall "internationalized" domain name usage. The resulting semantic loss by orthotypographic limitation makes IDNA unfit for: * a good steganographic use of the namespace (mnemonics, encryption, etc.) * a direct support of the Semantic Addressing System (SAS) that the IUCG is exploring. This memo documents a punyplus algorithm that fully supports the SAS and offers a strictly compliant IDNA option. 2. Discussion list This proposition can be discussed on the iucg@ietf.org. 3. The Interplus approach The Interplus is an Internet "better use" architecture to bring users better Facilitation services. It deploys additional layers on the user side in a manner that is transparent to the Internet layers' operations. It is in this way that it can support extended network functions (active content support) and additional services (such as the support of ambient content). The Interplus architecture includes an ML-DNS (multi-layers domain name system) pile. This pile comprises three naming layers: * User Domain Names (UDNs) that can be case sensitive full UTF-8 * Application Domain Names (ADNs) that can be case sensitive NFC * Internet Domain Names (IDNs) that comprise alphadecimal (0-Z) labels (case insensitive by nature) in using strong (".") separators, and a weak ("-") separator between the sub-labels. Empty sub-labels (resulting in a "--" separation) are understood as the operationally validated way to support the Internet Presentation virtual layer, in which they separate a presentation prefix (or Morfin Expires June 7, 2010 [Page 3] Internet-Draft punyplus December 2009 suffix) from the naming payload. "xn--" is understood as the "extended names presentation" prefix. 4. Punyplus algorithm The punyplus algorithm is used to convert (back and forth) ADNs into IDNs. An option of punyplus conforms to the punycode algorithm and does not support uppercases. To reliably obtain this, punyplus is a strict punycode copy with the added capacite (as a removable option)to insert the "^" prefix to signal the replacement of an uppercase by a lowercase. There are then two possible ways to support this insert. 4.1. Support as a regular character When executing the punycode algorithm itself, it converts "^" as a non-ASCII (UMI) upper-case metadata indicator and then handles its code point in the regular way. When converting back to non-ASCII, it restores the UMI as "^", or deletes it if the next character is restored as an uppercase. Exemple: UDN: User domain name : Etat.fra ADN: Application domain name : ^etat.fra IDN: Internet domain name : xn--etat-abc.fra (abc depending on the choice of UMI). 4.2. Support through a dedicated format The "^" insert is replaced by the "---1" sequence. The advantage of this solution is its independence from the coding system, that it is open to the support of other needs by sequence of "---x" or "---zz" type, its readability is simple and direct entries car be easily manually made. Its disadvantage is the user of four or five bytes to send a metadata. Exemple: UDN: User domain name : Etat.fra ADN: Application domain name : ^etat.fra IDN: Internet domain name : xn--e---1tat.fra 5. Value of the UMI codepoint There are four possibilities for the choice of the UMI code point: 5.1. To use a DISALLOWED codepoint Morfin Expires June 7, 2010 [Page 4] Internet-Draft punyplus December 2009 This will be transparent to IDNA unaware applications and uncertain with IDNA2003 applications, but blocked by IDNA2008 compliant applications. There is no risk of confusion with a lowercase described destination. 5.2. To use an UNASSIGNED codepoint This will be transparent to IDNA unaware applications and uncertain with IDNA2003 applications, but blocked by IDNA2008 compliant applications. A conflict may result from a further edition of ISO 10646. Otherwise, there is no risk of confusion with a lowercase described destination. 5.3. To use a PVALID codepoint The code point would be out of regular use sequence, therefore signaling a special use. This will be transparent to IDNA unaware applications and accepted, but not necessarily understood, by IDNA2003 and IDNA2008 compatible applications. There is no risk of confusion with a lowercase described destination. 5.4. To register a dedicated codepoint This will be transparent to IDNA unaware applications and uncertain with IDNA2003 applications, but blocked by IDNA2008 compliant applications. There is no risk of confusion with a lowercase described destination. A further IDNA update could make that code point PVALID and extend IDNAPLUS to all the IDNA users. 5.5. Solution These possibilities will be submitted to tests and discussion with users. 6. Naming added services The punyplus algorithm being transparent to pure ASCII UDNs/ADNs, it is applicable to all Internet domain names. It can therefore be used as an ML-DNS naming command parser and universal UDN/DNA/IDN converter. Its concerted generalization will therefore participate in an ambient canonalization of the naming space. 7. Further extensions The punyplus algorithm will progressively be extended to support DNS related security projects, linguistic mail addresses, DNS class selection, semantic addressing and Netix (interplus explored interapplication system) commands. Morfin Expires June 7, 2010 [Page 5] Internet-Draft punyplus December 2009 8. Multilinguistics section Multilinguistics is understood as the cybernetics of linguistic diversity. This memo enables improved Internet multilinguistic support. 9. Security section The ability to use a larger number of code points that are denied; or an additional alphadecimal character in naming (corresponding to the "power" sign) that is blocked by all the naming functions, which in turn should not create security issues for those applications that are properly written or those interfaced by properly written applications. The inability to use uppercases dramatically reduces the interest of randomly generated or encrypted domain names in access protection strategies. The global stability of the Internet will probably be affected by some uses taking, like IDNA, a better advantage from its protocols. This should motivate a wide separated study. The author things that the punyplus practice may bring a positive added experience in the study and the solving of the new problems that may be encountered. 10. IANA section The selected value of the UMI should be recorded by the IANA. 11. Acknowledgments I particularly thank the members of the france@large center of expertise on IDNs for their dedicated support and pertinent contributions. 12. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's address Jean-Francois C. Morfin INTLNET 23 rue Saint Honore Versailles 78000 Versailles France Phone: (33.1) 39 50 05 10 Morfin Expires June 7, 2010 [Page 6] Internet-Draft punyplus December 2009 Email: jefsey@jefsey.com URI: http://intlnet.org Morfin Expires June 7, 2010 [Page 7]