IDN over EPP
(IDNPROV)
IETF BOF, Washington DC
November 2004
Agenda
Agenda Bashing (5 min)
IDN / EPP Basics (2 min)
IDN Registration Background (8 min)
Problem Statement / Discussion (30 min)
Moving Forward (15 min)
IDN Basics
IDNA

Specifies that ToACE conversion to be managed at
the application layer at the client for DNS resolution
Nameprep

Specifies equivalent Unicode Characters to map and
full scope of valid characters
Punycode

ASCII Compatible Encoding (ACE)
ICANN IDN Guidelines


Intended Language should be considered at
registration
Conservativeness Principle
EPP Basics
XML based, created with Domain Registration in
mind but extensible for other registries
Session Management Commands (2):

Login/Logout
Query Commands (4):

Check, Info, Poll, Transfer
Transform Commands (5):

Create, Delete, Renew, Transfer, Update
Current Standard Mappings:



Domain Mapping
Contact Mapping
Host Mapping
IDN Registrations
What data is to be passed from the
Registrar (Client) to the Registry (Server),
and vice versa?


Submitted String (the IDN)
Provisioning Elements
Language-Tags
IDN Variants

Protocol Design
Submitted IDN String
Format of IDN




Punycode?
UTF-8?
Others?
Allow submission in multiple formats?
“Sanitization” of IDN submitted


Must the client submit Nameprep-ed string?
Should the option of sending a nonNameprep-ed string be included in the core
protocol?
Provisioning Elements
Language-Tag





ICANN IDN Guidelines
RFC3066 (BCP47)
Declaration of Intended Language(s)
Multiple Language-Tags for single registration
Updating of associated Language-Tags
Basic Concept of Variants
Given an IDN registration:



Submitted String (Primary IDN)
Intended Language (Language-Tag)
Corresponding Language-Table (Character
Equivalence Mapping Table)
A Set of IDN Variants are Generated. These
Variants may be:



Automatically “Activated” and included in zone
Reserved and not available for provisioning by other
registrant
“Activated” to the zone at a later time
Variants generally inherit the statuses of its
Primary IDN, and the set can be considered a
subordinate.
Variants Provisioning
Variants





Client / Server determined variant tables?
Conveyance of Variants between Client and
Server (full list may be very large)
“Activation” and “Deactivation” of Variants
Manageability / Inheritance of Variants (status
values, expiry, name server delegations, etc.)
Host Objects for Variants
Basic Problem Description
IDN Registration will likely become a frequent
transaction and a core functionality for most
Domain Registries
Diverging Extensions to EPP for the provisioning
of IDNs is not in the best interests of the industry
and defeats the purpose of having a
standardized EPP
IDN Registration requirements relate with
Registry Policies, but IDN over EPP extensions
should simply allow provisioning of the core
elements for IDN registrations to allow Registries
to implement their own policies
Current States
Do Nothing (.PL)




No extensions to EPP for IDNs
IDNs transported in Punycode format
No Language-Tags required
Acceptability based on set of valid codepoints
Domain Mapping Extensions (.INFO)


Extensions for conveyance of Language-Tags
IDNs transported in Punycode format
New IDN Object (testbed at .TW)


Language-Tags and Variants provisioning
IDNs transported in UTF-8 (Nameprep-ed)
Our proposal
Extend EPP, so provision of IDN “works”

We already see diversity among solutions
Do this work in a new wg of the IETF
Potential Scope for the wg
Defining a policy-less framework (i.e. set
of core requirements for IDN provisioning)

What data to be passed between Client and
Server
Format of Submitted String

Determining standard format(s) to be used
during transport
Protocol Design
Deliverables
Architecture specification


What data is passed between what entities
Overall architecture description
epp extension specification

Extensions to epp
What if the wg detect changes to core epp
is needed?

New version of epp after rechartering
Thank You
Edmon Chung

[email protected]
Patrik Falstrom

[email protected]
Howard Eland

[email protected]