Skip to main content
Resources

Inter-Registrar Transfer Policy Part B Policy Development Process – Recommendation 8 Concerning Standardizing and Clarifying WHOIS Status Messages

Comment/Reply Periods (*) Important Information Links
Comment Open: 21 February 2012
Comment Close: 25 March 2012
Close Time (UTC): 23:59 UTC Public Comment Announcement
Reply Open: Cancelled – No Comments To Submit Your Comments (Forum Closed)
Reply Close:   View Comments Submitted
Close Time (UTC):   Report of Public Comments
Brief Overview
Originating Organization: ICANN Board
Categories/Tags: Policy Processes, ICANN Board/Bylaws, Contracted Party Agreements
Purpose (Brief): Public notice is hereby provided of the proposed change related to the Inter-Registrar Transfer Policy to standardize and clarify WHOIS status messages that is considered for adoption as well as an opportunity to comment on the adoption of the proposed policy change, prior to ICANN Board consideration.
Current Status: Following adoption by the Generic Names Supporting Organization (GNSO) Council of IRTP Part B Recommendation #8 and the related staff proposal, a public comment forum is now opened as required by the ICANN Bylaws prior to ICANN Board consideration.
Next Steps: Following the closing of the public comment period, the ICANN Board will consider the comments received in conjunction with its consideration of the proposed change to the IRTP.
Staff Contact: Marika Konings Email: policy-staff@icann.org
Detailed Information
Section I: Description, Explanation, and Purpose

The Inter-Registrar Transfer Policy (IRTP) Part B presented its recommendations to the GNSO Council last year. For one of those recommendation, #8 ("The WG recommends standardizing and clarifying WHOIS status messages regarding Registrar Lock status. The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Based on discussions with technical experts, the WG does not expect that such a standardization and clarification of WHOIS status messages would require significant investment or changes at the registry/registrar level."), the GNSO Council requested ICANN staff to provide a proposal. In consultation with the IRTP Part B Working Group, ICANN Staff prepared a proposal that, together with the IRTP Part B recommendation, has now been approved by the GNSO Council.

The ICANN Staff proposal [PDF, 290 KB] agrees that the standardization and clarification of WHOIS status messages does not require significant investment or changes at the registry/registrar level. As outlined in the IRTP Part B Final Report, it is possible to associate each EPP status value with a message that explains the meaning of the respective status value. Registrars would be required to display a link to information on each status code directly next to the status in the output, for example: "Status: ClientLock http://www.internic.net/status/html/clientlock". This link would then direct to an ICANN controlled web page where the relevant status code information as described in the ‘EPP Status Codes, what do they mean and why should I know?’1 is posted. ICANN will also post translations of the status information. The web page can make use of localization information from the browser the user is using to display the web page in the related language. The requirement for registries and registrars to provide this link and ensure uniformity in the message displayed could be implemented as a standalone ‘WHOIS Status Information Policy’ or as an addition to the IRTP. In order to avoid potential blocking or stripping out of URLs from WHOIS output for valid reasons, registrars would be required to not remove Internic.net hyperlinks (or particularly the Internic.net status hyperlink) from their WHOIS output. In addition to the link, registrars would be required to include in the WHOIS output a note that would state "For more information on WHOIS status codes, please visit Internic.net” where the link to the information would be posted.

You are invited to submit comments until 25 March 2012 before final consideration by the ICANN Board.

Section II: Background

The Inter-Registrar Transfer Policy (IRTP) aims to provide a straightforward procedure for domain name holders to transfer their names from one ICANN-accredited registrar to another should they wish to do so. The policy also provides standardized requirements for registrar handling of such transfer requests from domain name holders. The policy is an existing community consensus policy that was implemented in late 2004 and is now being reviewed by the GNSO.

The IRTP Part B Policy Development Process (PDP) was the second in a series of five PDPs that address areas for improvements in the existing Inter-Registrar Transfer Policy. The GNSO IRTP Part B Policy Development Process Working Group was tasked to address five issues focusing on issues related to domain hijacking, the urgent return of an inappropriately transferred name and "lock status". The WG delivered its Final Report to the GNSO Council on 31 May 2011. The GNSO Council acted on a number of the recommendations at its meeting on 22 June 2011. In relation to recommendation #8, a proposal from staff was requested. Following consultations with the IRTP Part B Working Group and a public comment forum on the Staff Proposal, the ICANN Staff proposal was submitted to the GNSO Council on 3 January 2012. On 10 January 2012, the IPC provided its comments to ICANN staff proposal (as described in http://gnso.icann.org/mailing-lists/archives/council/msg12555.html). Based on the review of the IPC Proposal, ICANN staff provided an updated proposal (as described in http://gnso.icann.org/mailing-lists/archives/council/msg12600.html) which was approved, together with the IRTP Part B Recommendation #8 at its meeting on 16 February 2012. As required by the ICANN Bylaws, public notice is hereby provided of the policy that is considered for adoption as well as an opportunity to comment on the adoption of the proposed policy, prior to consideration by the ICANN Board of these recommendations.

Section III: Document and Resource Links
Section IV: Additional Information
None

(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.

1The IRTP Part B Working Group, with the support of ICANN Staff developed this document, which provides an overview of EPP Status Codes and what they mean (see Annex F of the IRTP Part B Final Report [PDF, 972 KB] – EPP Status Codes, what do they mean and why should I know?).

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."