1. IDN over EPP (IDNPROV) IETF BOF, Washington DC November 2004

2. Agenda Agenda Bashing (5 min) IDN / EPP Basics (2 min) IDN Registration Background (8 min) Problem Statement / Discussion (30 min) Moving Forward (15 min)

3. IDN Basics IDNA Specifies that ToACE conversion to be managed at the application layer at the client for DNS resolution Specifies that ToACE conversion to be managed at the application layer at the client for DNS resolutionNameprep Specifies equivalent Unicode Characters to map and full scope of valid characters Specifies equivalent Unicode Characters to map and full scope of valid charactersPunycode ASCII Compatible Encoding (ACE) ASCII Compatible Encoding (ACE) ICANN IDN Guidelines Intended Language should be considered at registration Intended Language should be considered at registration Conservativeness Principle Conservativeness Principle

4. EPP Basics XML based, created with Domain Registration in mind but extensible for other registries Session Management Commands (2): Login/Logout Login/Logout Query Commands (4): Check, Info, Poll, Transfer Check, Info, Poll, Transfer Transform Commands (5): Create, Delete, Renew, Transfer, Update Create, Delete, Renew, Transfer, Update Current Standard Mappings: Domain Mapping Domain Mapping Contact Mapping Contact Mapping Host Mapping Host Mapping

5. IDN Registrations What data is to be passed from the Registrar (Client) to the Registry (Server), and vice versa? Submitted String (the IDN) Submitted String (the IDN) Provisioning Elements Provisioning ElementsLanguage-Tags IDN Variants Protocol Design Protocol Design

6. Submitted IDN String Format of IDN Punycode? Punycode? UTF-8? UTF-8? Others? Others? Allow submission in multiple formats? Allow submission in multiple formats? “Sanitization” of IDN submitted Must the client submit Nameprep-ed string? Must the client submit Nameprep-ed string? Should the option of sending a non- Nameprep-ed string be included in the core protocol? Should the option of sending a non- Nameprep-ed string be included in the core protocol?

7. Provisioning Elements Language-Tag ICANN IDN Guidelines ICANN IDN Guidelines RFC3066 (BCP47) RFC3066 (BCP47) Declaration of Intended Language(s) Declaration of Intended Language(s) Multiple Language-Tags for single registration Multiple Language-Tags for single registration Updating of associated Language-Tags Updating of associated Language-Tags

8. Basic Concept of Variants Given an IDN registration: Submitted String (Primary IDN) Submitted String (Primary IDN) Intended Language (Language-Tag) Intended Language (Language-Tag) Corresponding Language-Table (Character Equivalence Mapping Table) Corresponding Language-Table (Character Equivalence Mapping Table) A Set of IDN Variants are Generated. These Variants may be: Automatically “Activated” and included in zone Automatically “Activated” and included in zone Reserved and not available for provisioning by other registrant Reserved and not available for provisioning by other registrant “Activated” to the zone at a later time “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.

9. Variants Provisioning Variants Client / Server determined variant tables? Client / Server determined variant tables? Conveyance of Variants between Client and Server (full list may be very large) Conveyance of Variants between Client and Server (full list may be very large) “Activation” and “Deactivation” of Variants “Activation” and “Deactivation” of Variants Manageability / Inheritance of Variants (status values, expiry, name server delegations, etc.) Manageability / Inheritance of Variants (status values, expiry, name server delegations, etc.) Host Objects for Variants Host Objects for Variants

10. 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

11. Protocol Design Extending EPP Two Main Approaches: Extension to Domain Mapping Extension to Domain Mapping New IDN Object Mapping New IDN Object Mapping Do Nothing: everything to be managed out-of-band

12. Current States Do Nothing (.PL) No extensions to EPP for IDNs No extensions to EPP for IDNs IDNs transported in Punycode format IDNs transported in Punycode format No Language-Tags required No Language-Tags required Acceptability based on set of valid codepoints Acceptability based on set of valid codepoints Domain Mapping Extensions (.INFO) Extensions for conveyance of Language-Tags Extensions for conveyance of Language-Tags IDNs transported in Punycode format IDNs transported in Punycode format New IDN Object (testbed at.TW) Language-Tags and Variants provisioning Language-Tags and Variants provisioning IDNs transported in UTF-8 (Nameprep-ed) IDNs transported in UTF-8 (Nameprep-ed)

13. Our proposal Extend EPP, so provision of IDN “works” We already see diversity among solutions We already see diversity among solutions Do this work in a new wg of the IETF

14. 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 What data to be passed between Client and Server Format of Submitted String Determining standard format(s) to be used during transport Determining standard format(s) to be used during transport Protocol Design

15. Deliverables Architecture specification What data is passed between what entities What data is passed between what entities Overall architecture description Overall architecture description epp extension specification Extensions to epp Extensions to epp What if the wg detect changes to core epp is needed? New version of epp after rechartering New version of epp after rechartering

16. Thank You Edmon Chung edmon@afilias.info edmon@afilias.info Patrik Falstrom paf@cisco.com paf@cisco.com Howard Eland heland@afilias.info heland@afilias.info