Internet DRAFT - draft-iucg-punyplus
draft-iucg-punyplus
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]
