2.1.4 IDN over EPP (idnprov)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-11-02


Howard Eland <heland@afilias.info>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

As the global DNS applications and Top-Level Domain (TLD) registries
begin to adopt the IDNA (Internationalized Domain Names in
Applications) standards the registration of IDNs (Internationalized
Domain Names) at shared registry systems becomes an important element
of operational functionality for domain registries.

Furthering the discussion from the PROVREG group, describing
the "desire to allow a registrar to access multiple registries via the
same protocol, even if the registries differ in operational models,"
there is interest for the same to apply to the provisioning of IDNs.

Although the EPP RFCs have already provided extension guidelines, due
to the foreseeable frequency of IDN provisioning and the potential
complexity for registrars if different implementations are adopted by
different registries, it makes sense to try to establish standardized
extensions for IDN provisioning.

In general, there are two main approaches to incorporating IDN
provisioning elements to EPP:
1. Extensions to Domain Mapping; or
2. New IDN Object Mapping.

The goal of this BOF is to see if there is enough interest from the
community to create a workgroup that would be chartered to create
documents on both:
1. Requirements of IDN provisioning
2. Standard Extensions for IDN-over-EPP

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

IDN BOF, Washington DC Notes

Nov 9, 2004


Howard Eland
Patrick Falstrom

Edmon Chung presentation: IDN over EPP (IDNPROV)

IDN/EPP Basics
IDN Submission (Punycode?, UTF-8?, ...)
Language Tags

IDN Registration/Background
Extend EPP ?
New IDN Object mapping ?
.pl example no extensions to EPP
.info extension to domain mapping
.tw idn object and variants

Extend EPP to make "idn" work

Prob Statement and Discussion
Does this work require a new WG within the IETF ?

Moving Forward

John Kleinson

Issues need work drivin by ICANN
Unable to get IANA to engage
Should we figure it out here and present to them or you come with a better idea
Risk to go ahead without IANA/ICANN input
Charge ahead ? and present solution ?
ICANN has not offered input into this problem as of yet

Start with a protocol extention and requirements

IDN is just one of the problems
Contact is another problem
EPP is not usable for IDN as it stands, needs changes to core EPP
ccTLD is not able to use EPP, esp Contact object and field separatino
Host and subordinate object, and relationship to domain is not always the case
Transfer of domain, ....

Redsign EPP not for here
Too late should have discussed when EPP was in WG
Get back to EPP IDN not redesign EPP

Diversity of solutions, may be diverse problems
Legal requirements, drive problems
Non interroperable extensions to EPP
Standardize epp extensions ? and does this help and issues around that

Refer to examples,
where is case to unify 1 solution in IDN extension
what benefit is there with a common solution
Who is the customer for this standardization ?

EPP tried to find a common domain registration and so why not IDN follow suit ?
Can we standardize IDN EXT ?

Multiple registration world will need common IDN, but not used as of yet

examples just a sample not a basis for common IDN

Ed Luis
Basic framework for EPP - Yes
Should that apply to extensions ? and is IDN one of them
More than one way may be better
Is this even possible

examples given are subsets and very close in relation, perhaps could find a common solution
Focus on mechanism for IDN that are outside of policy, but focus on facts like mapping

There are common elements to make up a basic extension, common feature set to standardize

Andy Newton
Problem policy not data model
Policy will get in the way of the extension, push work into the XML
What are all the policies and can we enumerate them all and is very complex

Server policy are enforced in the software but the XML will provision the common elements
Are there enough common elements
Mech of IDN is a meaning full addition
Policy is in the server not the protocol, common elements drives the need lang tag

Mike Young
IDN Ext may not suceed you can choose to opt in or out of this common idea
Time is now to implement

Too many different IDN EXT may do more harm than good
But, .. there must be a uniform aggreement and improve competitive env.
not IETF problem

URL schemes, etc, list of these types, http/ftp/... IANA registry of here is how we do lang tag ...

ICANN problem guidelines describe the Reg/Reg
Refer to RGP ext
Open to common IDN ext and post as proposal using ICANN guidance in ICANN context for ext

Complexity of IDN is more than RGP and needs WG
More input would help in the WG forum

Variants would make this more aware
Chinese example would be a perfect example as its a req.
There is a good working scope already

Collect problems issues on IDN EPP and EPP ? req for other epp problems in IDN world

You need to know what the problem is, what do we want to do

EPP already has req and they are avail
area directory, can not charter WG on just EPP as this is closed
need to be based on new work not standard EPP

Ed Luis
This work should go to RFC eventually whatever it is, but are there harmonious req for this
We need to get all the common req, it should be a WG if we have a common question
Many sources of req ICANN, ....

What are the common elements and this would be the first thing done in the WG

Ted Hardie
Wonder will this solve any of our problems
The common tools do they solve the problems
Worse off if we have a bunch of tools in a non common ext
We may get it wrong if we try to solve the entire problem set

ICANN, will not help and would not really be a help
ICANN should be deployed by users of IDN and get them to force IDN common items
When they make those standards we come back here and make a WG
Need real proof that we can really come up with a common toolkit and protocol

Whether we have something here are new requirements here not already discussed, to change the EPP protocol
Scott and Patrick think to do work on this we need to know what we need before we make a WG
New ideas not old ones already discussed and is there a problem to solve

Concerned with appearance of author EPP enforceing rules in this forum and consider it a joint decision not
just Scott.

Area director you are not ready for a HMM, do more work before you come here and have a written document set to
give an example of the short comming
ICANN might help you but you need to consult them first before this and a HMM
2nd BOF and come back again with more proof this is even needed
Find those common elements and bring them here not just we need "common idn framework"

ICANN will be talking about this in cape town, in a month and now would be a time to talk to them
Get the req and bring them to ICANN
ICANN looking at IDN committee and EPP


Needs beer to talk about this in more than one hand and first beer would be a good start.