 

 

 

 

Final Report on the Translation and Transliteration of Contact Information Policy Development Process

 

 

 

Status of This Document

This is the Final Report on Translation and Transliteration of Contact Information, prepared by the Working Group co-Chair Chris Dillon and ICANN staff.

 

 

 

Summary

This report is submitted to the GNSO Council for its consideration as a required step in this GNSO Policy Development Process on Translation and Transliteration of Contact Information. [1]

 

 

 

 


Table of Contents

 

1. Executive Summary ......................................................................................................................................................

2. Objectives and Next Steps .........................................................................................................................................

3. Mission and Scope .........................................................................................................................................................

4. Approach Taken by the Working Group ............................................................................................................

5. Deliberation and Recommendations ......................................................................................................................

6. Community Input ..........................................................................................................................................................

7. Background ........................................................................................................................................................................

8. Annex A - Charter .........................................................................................................................................................

Annex B – Comment Review Tool ...................................................................................................................................


1.     Executive Summary

1.1 Background

The Translation and Transliteration of Contact Information Policy Development Process (PDP) Working Group (the “Working Group”) is concerned with the way that contact information data – commonly referred to as ‘Whois’ – are collected and displayed within generic top-level domains (gTLDs). According to the Charter (see also Annex A), the Working Group “is tasked to provide the GNSO Council with a policy recommendation regarding the translation and transliteration of contact information. As part of its deliberations on this issue, the Working Group should, at a minimum, consider the following issues:

 

  • Whether it is desirable to translate contact information to a single common language or transliterate contact information to a single common script?
  • Who should decide who should bear the burden [of] translating contact information to a single common language or transliterating contact information to a single common script?”

 

1.2 Deliberations of the Working Group

The Translation and Transliteration of Contact Information (T&T) Working Group started its deliberations on 19 December 2013, when it decided to conduct its work through a combination of weekly conference calls and conversations on a publicly archived email list . The Working Group also met face-to-face during ICANN Meetings 49, 50, 51 and 52. Section 5 provides an overview of these deliberations.

 

1.3 Recommendations

Please note that the Working Group has provided additional background and information for most of these recommendations, which can be found in Section 5, covering also the Working Group’s deliberations and full-length recommendations .

 

Recommendation #1 The Working Group recommends that it is not desirable to make transformation of contact information mandatory. Any parties requiring transformation are free to do so on an ad hoc basis outside Whois or any replacement system, such as the Registration Data Access Protocol (RDAP). If not undertaken voluntarily by registrar/registry (see Recommendation #5), the burden of transformation lies with the requesting party.

 

Recommendation #2 Whilst noting that a Whois replacement system should be capable of receiving input in the form of non-ASCII script contact information, the Working Group recommends its data fields be stored and displayed in a way that allows for easy identification of what the different data entries represent and what language(s)/script(s) have been used by the registered name holder.

 

Recommendation #3 The Working Group recommends that the language(s) and script(s) supported for registrants to submit their contact information data may be chosen in accordance with gTLD-provider business models.

 

Recommendation #4 The Working Group recommends that, regardless of the language(s)/script(s) used, it is assured that the data fields are consistent to standards in the Registrar Accreditation Agreement (RAA), relevant Consensus Policy, Additional Whois Information Policy (AWIP) and any other applicable policies. It is also assured that entered contact information data are verified, in accordance with the aforementioned Policies and Agreements and the language/script used must be easily identifiable.

 

Recommendation #5 The Working Group recommends that if the transformation of contact information is performed, and if the Whois replacement system is capable of displaying more than one data set per registered name holder entry, these data should be presented as additional fields (in addition to the authoritative local script fields provided by the registrant) and that these fields be marked as transformed and their source(s) indicated.

 

Recommendation #6 The Working Group recommends that any Whois replacement system, for example RDAP, remains flexible so that contact information in new scripts/languages can be added and its linguistic/script capacity expanded for receiving, storing and displaying contact information data.

 

Recommendation #7 The Working Group recommends that these recommendations are coordinated with other Whois modifications where necessary and are implemented and/or applied as soon as a Whois replacement system that can receive, store and display non-ASCII characters, becomes operational.

 

Finding in relation to Charter question 2 Based on recommendations #1-#7, the question of who should decide who should bear the burden of translating or transliterating contact information to a single common script is moot.

 

1.4 Stakeholder Group / Constituency Statements and Initial Public Comment Period

A public comment forum was opened upon publication of the Preliminary Issue Report of this PDP – the public comment period ran from 8 January until 1 March 2012 and three (3) comments were received. The Working Group also requested all GNSO Stakeholder Groups and Constituencies, as well as other ICANN Support Organizations (SOs) and Advisory Committees (ACs), to submit their statements on the issues raised in the Charter.

Following the publication of the Initial Report , another public comment forum was opened from 16 December 2014 until 22 February 2015. 11 comments were submitted and the Working Group has recorded its responses and deliberations that stemmed from these comments in a Comment Review Tool that can be found in Annex B of this Final Report.

 

1.5 Conclusion and Next Steps

All 7 recommendations and the finding on Charter Question 2, as listed in Section 5 of this report, received full consensus support from the Working Group Members.


2.     Objectives and Next Steps

This Final Report on the Translation and Transliteration of Contact Information Policy Development Process (PDP) is prepared as required by the GNSO Policy Development Process as stated in the ICANN Bylaws, Annex A . This Final Report is based on the Initial Report of 15 December 2014 and has been updated to reflect the review and analysis of the public comments received by the Working Group in addition to further deliberations among the Working Group’s members. This Report has been submitted to the GNSO Council for its consideration. The Working Group’s recommendations are outlined in Chapter 5. If the GNSO Council approves the Final Report, ICANN staff will prepare a GNSO Council Report, which will accompany the Final Report to the ICANN Board. Following a public comment period, the ICANN Board will make the determination whether to approve the policy changes recommended by the Working Group in this Final Report.

3.    
Mission and Scope

The Translation and Transliteration of Contact Information Policy Development Process (PDP) Working Group is concerned with the way that contact information data – commonly referred to as ‘Whois’ – are collected and displayed within generic top-level domains (gTLDs). According to its Charter (see also Annex A), the Working Group “is tasked to provide the GNSO Council with a policy recommendation regarding the translation and transliteration of contact information. As part of its deliberations on this issue, the Working Group should, at a minimum, consider the following issues:

  • Whether it is desirable to translate contact information to a single common language or transliterate contact information to a single common script?
  • Who should decide who should bear the burden [of] translating contact information to a single common language or transliterating contact information to a single common script?”

 

In relation to the first question, the Charter notes “text requests and content returned by Domain Name Registration Data Services (such as WHOIS) are historically encoded using US-American Standard Code for Information Interchange (ASCII). This is a character-encoding scheme originally based on the English alphabet. While the WHOIS protocol does not specify US-ASCII as the exclusive character set for text requests and text content encoding, the current situation is that no standards or conventions exist for all WHOIS protocol implementations to signal support of character sets other than US-ASCII.”

 

The second question relates to the concern expressed by the Internationalized Registration Data Working Group (IRD-WG) in its report that there are costs associated with providing translation and transliteration of contact information. For example, if a policy development process (PDP) determined that the registrar must translate or transliterate contact information, this policy would place a cost burden on the registrar.

 

Finally, the Charter also encouraged the Working Group to consider the following issues related to its two core charter questions:

  • What exactly the benefits to the community are of translating and/or transliterating contact data, especially in light of the costs that may be connected to translation and/or transliteration?
  • Should translation and/or transliteration of contact data be mandatory for all gTLDs?
  • Should translation and/or transliteration of contact data be mandatory for all registrants or only those based in certain countries and/or using specific non-ASCII scripts?
  • What impact will translation/transliteration of contact data have on the WHOIS validation as set out under the 2013 Registrar Accreditation Agreement?
  • When should any new policy relating to translation and transliteration of contact information come into effect?

 

In addition, the Charter points out that: ‘[the] IRD-WG considered several alternatives to address translation and transliteration of contact information as follows:

  • The registrant submits the localized information as well the translated or transliterated information.
  • The registrant only submits the localized information, and the registrar translates and transliterates all internationalized contact information on behalf of the registrant.
  • The registrant only submits the localized information, and the registrars provide a point of contact at a service that could provide translation or transliteration upon request for a fee to be paid by the requester.
  • The registrant only submits the localized information, and the registry provides translation or transliteration.
  • The end users of the registration data translate and transliterate the contact information.

 

The PDP-WG will not be limited to considering the above alternatives, but will be encouraged to consider all possible alternatives [emphasis added].’


4.     Approach Taken by the Working Group

The Working Group convened its first meeting on 19 December 2013. It prepared a work plan , which has been reviewed on a regular basis, and revised when necessary. Also, Constituency and Stakeholder Group statements with regard to the Charter questions (see Annex A) were solicited. This request was also directed to other ICANN Supporting Organizations (SOs) and Advisory Committees (ACs) and a summary of responses can be seen in the public comment review tool . The Working Group prioritized discussing the community input received, to understand better the arguments brought forward by various stakeholders. This is also the reason that it decided to create a straw man proposal to drive forward the debate on whether or not it is desirable to translate/transliterate. This proposal provided a focal point to the Working Group’s discussion and was updated on a regular basis.

 

Following the publication of the Initial Report on 15 December 2014, a Public Comment period was opened from 16 December 2014 until 22 February 2015. 11 comments were received – all but three supporting the large majority of draft recommendations laid out in the Initial Report. The Working Group then spent considerable time to discuss the comments and to determine its response and approach with regard to this Final Report. Similar to the approach taken for the Initial Report, Working Group members decided to produce a Draft Final Report that would serve as a discussion document, incorporating comments received and elaborating on arguments and recommendations where appropriate. It was only the last version of the Final Report that was subjected to a consensus call and – it is that version upon which this Final Report is based.

 

4.1  Membership

 

Name

Affiliation *

Amr Elsadr  

NCUC

Anthony Oni  

NCUC

Ching Chiao

RySG

Chris Dillon (co-Chair)

NCSG

David Cake (Observer)

NCSG

Dennis Tan Tanaka

RySG

Edmon Chung

RySG

Emily Taylor

RrSG

Ephraim Percy Kenyanito

NCUC

Jennifer Chung

RySG

Jim Galvin

RySG

Jonathan Robinson (Observer)

RySG

Justine Chew

Individual

Mae Suchayapim Siriwat

GAC

Pascal Haddad

Individual

Patrick Lenihan  

NCUC

Peter Dernbach

IPC

Petter Rindforth

IPC

Pitinan Kooarmornpatana

GAC

Roger Carney

RrSG

Rudi Vansnick (co-Chair)

NPOC

Sara Bockey

RrSG

Sarmad Hussain [2]

SSAC

Ubolthip Sethakaset

Individual

Vinay Kumar Singh

Individual

Volker Greimann (Observer)

RrSG

Wanawit Ahkuputra

GAC

Wolf-Ulrich Knoben

ISPC

Yoav Keren

RrSG

Zhai Wen

RySG

Zhang Zuan

NCUC

 

*ALAC – At-Large Community

RrSG – Registrar Stakeholder Group

RySG – Registry Stakeholder Group

CBUC – Commercial and Business Users Constituency

NAF – National Arbitration Forum

NCUC – Non Commercial Users Constituency

NPOC – Not-for-Profit Operational Concerns Constituency

IPC – Intellectual Property Constituency

ISPCP – Internet Service and Connection Providers Constituency

NCSG – Non-Commercial Stakeholder Group

 

The Statements of Interest (SOI) for the Working Group members can be found at: https://community.icann.org/x/WDd-Ag

 

The attendance records can be found at: https://community.icann.org/x/VlF-Ag

 

The email archives can be found at: http://forum.icann.org/lists/gnso-contactinfo-pdp-wg/


5.     Deliberation and Recommendations

This section provides an overview of the deliberations of the Working Group. It is intended to serve as a record of the discussion and analysis of the Working Group, reflecting the arguments made and discussed in support of and in opposition to the recommendations that follow.

During its initial discussion, the Working Group identified a number of further issues and questions that are directly linked to the Charter questions, including relevant taxonomies. Details can be found on the Working Group’s wiki page: https://community.icann.org/x/WwmuAg .

The Working Group decided to define clearly what is meant by ‘contact information’, relying on the definition in the Final Issue Report on the Translation and Transliteration of Contact Information that is based on the definition in the Registrar Accreditation Agreement 2013: "In the context of these issues, ‘contact information’ is a subset of Domain Name Registration Data. It is the information that enables someone using a Domain Name Registration Data Directory Service (such as WHOIS) to contact the domain name registration holder. It includes the name, organization, and postal address of the registered name holder, technical contact, as well as administrative contact.” [3]

The Charter presented the Working Group with an overarching question: whether or not to recommend mandatory transformation of contact information into one single language/script. Due to the inherently binary nature of this Charter question, the goal of the Working Group has always been to answer this question first – providing the base for all other recommendations flowing from this Final Report. To understand the reasoning of the Working Group it is therefore paramount to understand fully that all arguments that were brought up – either by Working Group members or through public comments – were thoroughly discussed and assessed. The following section lays out in greater detail, which arguments, in favor of and in opposition to mandatory transformation, the Working Group considered.

5.1    Deliberation on the two main Charter questions

Charter Q1: Is it desirable to translate contact information to a single common language or transliterate contact information to a single common script?

 

A key issue that emerged early on in the Working Group’s discussion was the agreement that their recommendation should bear in mind that the main purpose of transformed [4] data is to allow those not familiar with the original script of a contact information entry, to contact the registrant. This means that the accuracy of contact information data that are entered and displayed is paramount. There was, however, some divergence in the Working Group about whether the need for accuracy is an argument in favour of transformation or not – and this is also reflected in the section below as well as the public comments received (see ‘Community Input’ below).

To demonstrate how the Working Group arrived at its recommendations, the following summary provides both the arguments in favour of and opposing mandatory transformation.

5.1.1           Working Group’s arguments supporting mandatory transformation of contact information in all generic top-level domains

Some of the issues raised by those supporting mandatory transformation include:

  • Mandatory transformation of all contact information into a single script would allow for a transparent, accessible and, arguably, more easily searchable [5] database. Currently all data returned from the Whois database in generic top level domains (gTLDs) are provided in ASCII and such uniformity renders it a very useful global resource. Having a database with a potentially unlimited number of scripts/languages might create logistical problems in the long run.
  • Transformation would to some extent facilitate communication among stakeholders not sharing the same language. Good communication inspires confidence in the Internet and makes bad practices more difficult. At this stage ASCII/English are the most common script/language choices. However, it should be noted that already today many users of the Internet do not share English as a common language or the Latin script as a common script. The number of such users will grow substantially as Internet access and use continue to expand across countries/continents and so the dominant use of English might deter the participation of those not confident in or familiar with it.
  • For law enforcement purposes, when Whois results are compared and cross-referenced, it may be easier to ascertain whether the same registrant is the domain holder for different names if the contact information are transformed according to standards.
  • Mandatory transformation would avoid possible flight by bad actors to the least translatable languages [6] .
  • The main burden (financial or otherwise) to provide data in ASCII should lie on the parties collecting and maintaining the information (i.e. registrar, registry, reseller) because the maintenance of an accessible registration database is their responsibility and should be part of doing business.
  • A mono-lingual / mono-script Whois database would enable the listing of all domain names registered by a specific entity (e.g., identifying all domain names registered to a recently merged company).
  • Transformation would facilitate identification of and response to fraudulent use of legitimate data for domain names belonging to another registrant (using Reverse Query on identity-valid data).

 

Please note that these arguments do not necessarily reflect the consensus view of the Working Group’s members. However, they inform the Working Group’s deliberations  - and summaries of the reactions to these arguments are reflected in the Public Comment Review tool (Annex B).

 

5.1.2 Working Group’s arguments opposing mandatory transformation of contact information in all generic top-level domains

Some of the issues raised by those opposing mandatory transformation include:

  • Accurate [7] transformation is very expensive and these recommendations could effectively shift the costs from those requiring the work to registrants, registrars, registries or other parties. Costs would make things disproportionately difficult for small players. Existing automated systems for transformation are inadequate. They do not provide results of sufficient quality for purposes requiring accuracy and cover fewer than 100 languages. Developing systems for languages not covered by transformation tools is slow and expensive, especially in the case of translation tools. For purposes for which accuracy is important, transformation work often needs to be done manually. [8] For example the translated ‘Bangkok’ is more useful internationally than the transliterated ‘krung thep’. However, the transliterated ‘beijing’ is much more useful than the translated ‘Northern Capital’. Automated systems would not be able to know when to translate and when to transliterate.
  • Another consequence of the financial burden of transforming contact information data would be that the expansion of the Internet and provision of its benefits became more difficult, especially in less developed regions that are already lagging behind in terms of Internet access and often don’t use Latin-based scripts.
  • It would be near impossible to achieve high levels of accuracy in transforming a very large number of scripts and languages – mostly of proper nouns – into a common script and language. For some languages standards do not exist; for those where there are standards, there may be more than one, for example, for Mandarin, Pinyin and Wade Giles.
  • Mandatory transformation would require validation of both the original and transformed contact information every time they change, a potentially costly duplication of effort. Responsibility for accuracy would rest on registrants who may not be qualified to check it. Consistent transformation of contact information data across millions of entries is very difficult to achieve, especially because of the continued globalization of the Internet with an increase in users whose languages are not based on the Latin script. Whois contact information should display what the registrant enters. Original data should be authoritative, verified and validated. Interpretation and transformation may add errors.
  • Mandatory transformation into one script could be problematic for or unfair to all those interested parties that do not speak/read/understand that one script. For example, whereas transformation from Mandarin script to a Latin script might be useful to, for example, law enforcement in countries that use Latin scripts, it would be ineffectual to law enforcement in other countries that do not read that Latin script.
  • A growing number of registered name holders do not use Latin script, meaning that they lack the language skills to be able to transform their contact information themselves. Therefore, transformation would have to take place at a later stage, through the registrar or the registry. Considering the number of domain names in all gTLDs this would lead to considerable costs not justified by benefits to others and be detrimental to accuracy and consistency – key factors for collecting registered name holders’ contact information data in the first place.
  • The usability of transformed data is questionable because registered name holders unfamiliar with Latin script would not be able to communicate in Latin script, even if their contact information was transformed and thus accessible to those using Latin script.
  • It would be more convenient to allow registration information data to be entered by the registered domain holders in their local script and the relevant data fields to be transformed [9] into Latin script by either the registrar or the registry. Such transformation by the registrar or registry would provide greater accuracy in facilitating those wishing to contact name holders to identify their email and/or postal address. A similar method is already in place for some of the country code top level domains (ccTLDs): whois_test

 

  • The burden (financial and otherwise) of accessing and understanding contact information is best placed on the side of the beneficiary of such data – i.e. the data requestor.
  • Requiring domain name holders to submit data in a script they are not familiar with (be it ASCII or any other) could potentially lead to contractual breaches beyond the registrants’ control as they would not be able to verify autonomously the transformed version of the data they submitted.

 

The arguments here mostly reflect the Working Group members’ consensus views, for a detailed summary of members’ views and reactions to these arguments, please see the Public Comment Review Tool (Annex B).

 

Charter Q2: Who should decide who should bear the burden [of] translating contact information to a single common language or transliterating contact information to a single common script?

 

The Working Group spent most of its time debating the first Charter question as the answer to this second Charter question is dependent on the outcome of the first. At this stage, the Working Group believes that if mandatory translation and/or transliteration were recommended, the burden of translation/transliteration would probably fall to the operating registrars who would be likely to pass on these additional costs to their registrants, although the Working Group did not come to a conclusion as to who should decide who should bear the said burden.

 

5.1.3           Issue of Cost

In its Charter, the Working Group was encouraged to discuss the issue of cost in the event of transforming contact information data into one single script. This section provides an overview of the discussion.

In general, those supporting mandatory transformation have argued that costs should be borne by those maintaining the data (registries, registrars, resellers); those that have opposed mandatory transformation have stated that any transformation costs should be borne by those requesting the (transformed) data.

It is clear that blanket transformation of information data would incur large costs – it is likely that any manual transformation [10] would cost a significant amount. Enquiries with ICANN’s translation department show that transformations under 100 words currently cost a flat fee of between 25 and 75 US$ - depending on the language/script from which the transformation is sought. Such blanket transformation, at a significant cost, would seem inappropriate also because only a small fraction of such contact information data is ever requested and an even smaller fraction would require transformation.

Comments from both Working Group members (during discussions) and stakeholders (through public comments) have pointed out that the costs for mandatory transformation are likely to be passed on to registrants and in addition, such costs would hit especially those registrants, registrars and registries in poorer regions, in which costs can be a very significant market entry barrier. The need for creating new data fields (for transformed data) and significantly overhauling the operational process (to allow for transforming data and then verifying them) would add to the financial burden of mandating transformation of contact information.

 

5.2    Rationale and Recommendations

 

5.2.1 Rationale

Reliable automated transliteration is not available for non-alphabetic scripts [11] and is unlikely to be available for a considerable time. See Study to evaluate available solutions for the submission and display of internationalized contact data / ICANN IRD Study Team for further information.

Many alphabetic scripts [12] and syllabaries [13] do not indicate all vowels or word boundaries, and so cannot be losslessly transliterated.

In all of these cases, manual transliteration will be required.

Transliteration of alphabetic scripts [14] would not indicate, for example, streets, roads, buildings etc., which would ideally be translated. The Working Group is unaware of up-coming sophisticated transformation tools which know when to transliterate and when to translate.

Manual transformation could solve some of the problems outlined above, but it is slow and expensive and should be conducted centrally to avoid consistency problems arising from transformation implemented in different ways by many actors.

As regards accessibility, data in their original form, as long as they are machine-readable, are more easily and consistently searchable.

 

5.2.2 Recommendations

Recommendation #1 The Working Group recommends that it is not desirable to make transformation of contact information mandatory. Any parties requiring transformation are free to do so on an ad hoc basis outside Whois  or any replacement system, such as the Registration Data Access Protocol (RDAP). If not undertaken voluntarily by  registrar/registry (see Recommendation #5), the burden of transformation lies with the requesting party.

Level of consensus: Full Consensus

 

Recommendation #2 Whilst noting that a Whois replacement system should be capable of receiving input in the form of non-ASCII script contact information, the Working Group recommends its data fields be stored and displayed in a way that allows for easy identification of what the different data entries represent and what language(s)/script(s) have been used by the registered name holder.

Level of consensus: Full Consensus

 

Recommendation #3 The Working Group recommends that the language(s) and script(s) supported for registrants to submit their contact information data may be chosen in accordance with gTLD-provider business models.

Level of consensus: Full Consensus

 

Recommendation #4 The Working Group recommends that, regardless of the language(s)/script(s) used, it is assured that the data fields are consistent to standards in the Registrar Accreditation Agreement (RAA), relevant L Policy, Additional Whois Information Policy (AWIP) and any other applicable policies. Entered contact information data are verified, in accordance with the aforementioned Policies and Agreements and the language/script used must be easily identifiable.

Level of consensus: Full Consensus

 

Recommendation #5 The Working Group recommends that if the transformation of contact information is performed, and if the Whois replacement system is capable of displaying more than one data set per registered name holder entry, these data should be presented as additional fields (in addition to the authoritative local script fields provided by the registrant) and that these fields be marked as transformed and their source(s) indicated.

Level of consensus: Full Consensus

 

Recommendation #6 The Working Group recommends that any Whois replacement system, for example RDAP, remains flexible so that contact information in new scripts/languages can be added and its linguistic/script capacity expanded for receiving, storing and displaying contact information data.

Level of consensus: Full Consensus

 

Recommendation #7 The Working Group recommends that these recommendations are coordinated with other Whois modifications where necessary and are implemented and/or applied as soon as a Whois replacement system that can receive, store and display non-ASCII characters, becomes operational.

Level of consensus: Full Consensus

 

Finding in relation to Charter question 2 : Based on recommendations #1-#7, the question of who should decide who should bear the burden of translating or transliterating contact information to a single common script is moot.

 

5.2.2.1 Level of Consensus for these Recommendations

Full Consensus

 

5.2.3 Suggestions for further policy work

During its meetings, the Working Group discussed issues surrounding its charter’s main questions. Those highlighted in the public comment review tool (see Annex B) are listed below with the number(s) of the relevant comments:

  • Should data in a Whois replacement system be machine-readable ? (Public Review Tool No. 46)
  • If transformation is ever carried out, transformation standards would be required to avoid discrepancies between the original and transformed data sets. (No. 7)
  • Should the language of non-Latin Whois data fields be indicated (" marked ")? If so, is there a better solution than tagging? (Nos. 27-29, 37)
  • Is the registrant’s consent required before a transformed version of Whois data is published in Whois? (Nos. 54-55)
  • Is a Whois verification required every time a transformed field is updated? (No. 56)
  • What are the responsibilities on registrants and registrars as regards contactablity ? (No. 32)

6.     Community Input

In accordance with the PDP Manual, the Working Group reached out to ICANN’s Supporting Organizations and Advisory Committees, as well as to the GNSO Stakeholder Groups and Constituencies to gage their input on the Charter questions. Community feedback is of particular importance to the work of this Working Group because of the binary nature of the over-arching charter question of whether or not to recommend mandatory transformation of contact information data. The call for input was sent out to the leadership of the SO/ACs and SG/Cs on 4 February 2014. [15] A reminder was sent out to all community groups on 3 March 2014 and the Working Group also encouraged community feedback at its presentation to the GNSO during the weekend session preceding ICANN 49 in Singapore and during its face-to-face meeting at the same event.

 

Overall, the Working Group received feedback from the GAC representatives of Thailand, China, and the European Commission (all representing communities that rely on non-Latin scripts) [16] , the Intellectual Property Constituency (IPC), the At-Large Advisory Committee (ALAC), and the Non-Commercial Stakeholder Group (NCSG). [17] A summary of the contributions can be found in the SO/AC and SG/C outreach review tool and the full-length submissions are published on the Working Group’s wiki page .

 

The Working Group reviewed and discussed the contributions received in great detail. As pointed out above, the binary nature of the charter questions meant that community feedback was particularly valued during the Working Group’s efforts so far. Where relevant and appropriate, information and suggestions derived from the various contributions were considered and have been included in ‘Deliberation and Recommendations’ above.

 

Following the publication of the Initial Report , a public comment forum was opened that attracted eleven submissions; a staff summary of which can be found here . Of these submissions eight were supportive of the draft recommendations and three opposed them, favoring instead mandatory transformation of all contact information. The Working Group spent several weeks assessing all comments and discussing any new issues that were raised; where appropriate they are included in this report. In addition, Annex B contains the Comment Review Tool that was used by Working Group members to document its discussion on the public comments.


7.     Background

Extract from the Final Issue Report

 

I n Apr i l 200 9 I CA NN s Secur it y an d S t ab i l it y Adv i so r y Co mm itt e e ( SSAC ) i ssue d SA C 037 , D i sp l ay and usage o f I n t e r na ti ona liz ed Reg i s tr a ti on Da t a : Suppo rt f o r cha r ac t e r s fr o m l oca l l anguages o r sc ri p t. I n t h i s docu m en t , t h e SSA C exa m i ne d ho w t h e us e o f cha r ac t e r s fr o m l oca l sc ri p t s a ff ec t s t h e I n t e r ne t us er expe ri enc e w it h r espec t t o do m a i n na m e r eg i s tr a ti o n da t a sub m i ss i on , usag e, an d d i sp l ay . Th e SSA C m ad e t h r e e r ec o mm enda t i on s :

 

1 . Tha t I CA NN s Boa r d o f D ir ec t o r s t as k t h e G N S O , Coun tr y Cod e N a m e s Suppo rti n g O r gan i za ti o n ( ccNS O ) , an d t h e SSA C t o f o r m a w o r k i n g g r ou p t o s t ud y t h e f eas i b ilit y an d su it ab ilit y o f i n tr oduc i n g d i sp l a y spec ifi ca ti on s o r s t anda r d s t o dea l w it h t h e i n t e r na ti ona liz a ti o n o f r eg i s tr a ti o n da t a.

2 . Tha t I CA N N hos t a w o r ksho p o n t h e i n t e r na ti ona li za ti o n o f r eg i s tr a ti o n da t a du ri n g t h e nex t I CA N N m ee ti n g (J un e 2009 , S y dne y ) .

3 . Tha t I CA N N shou l d con si de r t h e f eas i b ilit y o f hav i n g app li ca ti on s t ha t que r y r eg i s tr a ti o n da t a se r v i ce s i nco r po r a t e “s t anda r d i n t e r na t i ona l i z a t i o n f un c ti ona lit y .

 

I CA NN s Boar d o f D ir ec t or s ac t e d o n Reco mm enda ti o n 1 b y approv i n g a r eso l u ti o n ( 2009 . 06 . 26 . 18 ) r eques ti n g t ha t t h e GN S O an d t h e SSAC , i n consu lt a ti o n w it h s t a ff , conven e a w o r k i n g g r ou p t o s t ud y t h e f eas i b ilit y an d su it ab ilit y o f i n tr oduc i n g d i sp l a y spec ifi ca ti on s t o dea l w it h t h e i n t e r na ti ona liz a ti o n o f r eg i s tr a ti o n da t a . [18] Sub s equen tl y , t h e SSA C an d t h e GNS O f o r m e d t h e IRD-WG t o s t ud y t h e i ssue s r a i se d b y t h e I CA N N B oa r d .

 

I n N ove m be r 201 0 t h e IRD-WG p r oduce d a n I n t er i m Repor t r e ques ti n g co mm un it y i npu t o n seve r a l ques ti on s r e l a ti n g t o poss i b l e m ode l s f o r i n t e r na ti ona lizi n g D o m a i n N a m e Reg i s tr a ti o n D a t a . [19] O n 0 3 O c t obe r 201 1 t h e IRD-WG pos t e d a d r a f t F i na l Repo r t f o r a 45 - da y pub li c co mm en t pe ri od . [20] A ft e r con si de ri n g t h e pub li c co mm en t s r ece i ved , o n 0 7 M a y 2012 , t h e I R D WG sub m itt e d a F i na l Repo r t t o t h e G N S O Counc i l an d t h e SSA C f o r cons i de r a ti on . [21]

 

Th e SSA C app r ove d t h e F i na l Repo r t i n M a y 201 2 . A t it s m ee ti n g o n 2 7 J un e 201 2 (i n P r ague ) t h e G N S O Counc i l passe d a m o ti o n b y w h i c h i t app r ove d t he de li ve r y o f t h e F i na l Repo r t t o t h e Boa r d . [22] I n it s m o ti o n , t h e Counc i l a l s o ag r ee d t o r ev i e w t h e r eco mm enda ti on s i n t h e F i na l Repo r t an d t o p r ov i d e t o t he Boa r d it s adv i c e w it h r ega r d t o t ho s e r eco mm enda ti on s t ha t m a y hav e po l i c y i m p lic a t i ons .

 

SAC054: SSAC Report on the Domain Name Registration Model [23] was released in June 2012 and concerns information associated with a domain name from the creation of its registration till its expiration and proposes a structured and extensible, generic data model.

 

A t it s m ee ti n g o n 1 7 O c t obe r 2012 , t h e G N S O Counc i l app r ove d a m o ti o n accep ti n g t h e I R D - W G F i na l Repo r t r eco mm enda ti ons . [24] Th e m o ti o n i n c l ude d t h e f o ll o w i n g c l ause s t ha t r esu lt e d i n t h e deve l op m en t o f t h i s F i na l I ssu e R epo r t :

 

W HEREA S t h e G N S O Counc i l ha s r ev i e w e d t h e F i na l Repo r t an d cons i de r s t ha t w h il e expec ti n g t h e I CA N N Boa r d t o r espon d t o t h e SSAC - GNS O j o i n t l e tt e r , t h e Reco mm enda ti o n 2 , tr ans l a ti o n an d tr ans lit e r a ti o n o f c on t a c t i n f o r m a ti o n o f I RD , o f t h e F i na l Repo r t r equ ir e s ti m e l y ac ti o n a t t h e po lic y l eve l w h i c h i nvo l ve s co ll abo r a ti o n a m on g do m a i n na m e r eg i s tr an t , r eg i s tr a r , an d r eg i s tr y .

“RES O LVE D , t h e GN S O app r ove s t h e F i na l Repo r t an d r eque st s t h e I CA N N S t a f f t o p r epa r e t h e I R D Iss ue s Repo r t o n tr an sl a ti o n an d tr an slit e r a ti o n o f con t ac t i n f o r m a ti o n (I RD I R - Rec2 ) . Th e Iss u e Repo r t shou l d cons i de r 1) w he t he r i t i s des ir ab l e t o tr ans l a t e con t ac t i n f o r m a ti o n t o a s i ng l e c o mm o n l anguag e o r tr ans lit e r a t e con t ac t i n f o r m a ti o n t o a s i ng l e co mm o n sc ri p t ; 2 ) w h o shou l d bea r t h e bu r de n an d w h o i s i n t h e bes t pos iti o n t o add r es s t h es e i ssues ; an d 3 ) w he t he r t o s t a r t a po li c y deve l op m en t p r oces s ( P D P ) t o add r es s t hos e ques ti ons .

 

As noted above, the ‘contact information’ references in this Final Issue Report is a subset of Domain Name Registration Data. It is the information that enables someone using a Domain Name Registration Data Directory Service (such as the WHOIS) to contact the domain name registration holder. It includes the name, organization, and postal address of the registered name holder, technical contact as well as administrative contact. Domain Name Registration Data are accessible to the public via a directory service (also known as WHOIS service). This protocol is a client-server, query-response protocol. The RAA (RAA 3.3.1) specifies the data elements that must be provided by registrars (via Port 43 and via web-based services) in response to a query, but it does not require that data elements, such as contact information, must be translated or transliterated.

 

Th e I R D - W G de fi ne d D o m a i n N a m e Reg i s tr a ti o n D a t a a s i n f o r m a ti o n t hat r eg i s tr an t s p r ov i d e w he n r eg i s t e ri n g a do m a i n na m e an d t ha t r eg i s tr a r s o r r eg i s tri e s co ll ec t . Th e RA A ( RA A 3 . 3 . 1) spe c i f i e s t h e da t a e l e m en t s t ha t m us t b e p r ov i de d b y r eg i s tr a r s ( v i a Po r t 4 3 an d v i a w eb - base d se r v i ces , suc h a s W HO I S ) i n r espons e t o a que r y . ( Fo r cc TL D s , t h e ope r a t o r s o f t hes e TL D s se t po li c i e s f o r t h e r eques t an d d i sp l a y o f r e g i s tr a ti on i n f o r m a t i on . )

 

A s t h e SSA C no t e d i n SAC05 1 SSA C Repo r t o n W H O I S Ter m i no l og y an d S tr uc t u r e , “Th e t e r m W H O I S i s ove rl oaded , r e f e rri n g t o p r o t oco l s , se r v i ces , an d da t a t y pe s assoc i a t e d w it h I n t e r ne t na m i n g an d nu m be ri n g r esou r ces , i. e . , do m a i n na m es , I n t e r ne t P r o t oco l (I P ) add r esses , an d Au t ono m ou s Sys t e m N u m be r s ( AS N s ). [25] Th e Repo r t f u rt he r no t e s t ha t W H O I S ca n r e f e r t o an y o f t h e f o ll o w i n g :

  1. Th e i n f o r m a ti o n t ha t i s co ll ec t e d a t t h e ti m e o f r eg i s tr a ti o n o f a do m a i n na m e o r I P nu m be ri n g r esou r c e an d sub s equen tl y m ad e ava il ab l e v i a t h e W H O I S Se r v i ce , an d po t en ti a ll y upda t e d t h r oughou t t h e lif e o f th e r e sou r c e ;
  2. Th e W H O I S Pro t oco l it se lf , w h i c h i s de fi ne d i n RF C 391 2 ( w h i c h obso l e t e s RFC s 81 2 an d 954 ) ; or
  3. Th e W H O I S Se r v i ce s t ha t p r ov i d e pub li c acces s t o do m a i n na m e r e g i s tr a t i o n i n f o r m a ti o n t yp i ca ll y v i a app lic a ti on s t ha t i m p l e m en t t h e WHO I S p r o t oco l o r a w eb - base d i n t e r f a c e .

Th e SSA C r eco mm ende d i n it s r epo r t t ha t t h e t e r m s Do m a i n N a m e R e g i s tr a ti o n D a t a D ir ec t o r y Se r v i c e (r a t he r t ha n W HO I S ) shou l d b e use d w he n r e f e rri n g to t h e se r v i ce (s ) o ff e r e d b y r eg i s tri e s an d r eg i s tr a r s t o p r ov i d e acces s to ( po t en ti a ll y a subse t o f ) t h e Do m a i n N a m e Reg i s tr a ti o n Da t a .

 

T o ba l anc e t h e need s an d capab iliti e s o f t h e l oca l r eg i s tr an t w it h t h e nee d o f t h e ( po t en ti a l ) g l oba l use r o f t h i s da t a , on e o f t h e ke y ques ti on s t h e IRD-WG m e m be r s d i scusse d i s w he t he r a Do m a i n Na m e Reg i s tr a ti o n D a t a D i r e c t o r y Se r v i ce , suc h a s t h e W HO I S , shou l d suppo r t m u lti p l e r ep r esen t a ti on s o f t h e sa m e r eg i s tr a ti o n da t a i n d iff e r en t l anguage s o r sc r i p t s.

 

Th e I R D - W G no t e d t ha t m uc h o f t h e cu rr en tl y access i b l e do m a i n r e g i s tr a ti on da t a are encode d i n U S A m e ri ca n S t anda r d Cod e f o r I n f o r m a ti o n I n t e r c hang e ( U S - ASC II) . US - ASC I I i s a cha r ac t e r - encod i n g sche m e o ri g i na ll y base d o n t h e Latin script . Th i s l egac y cond iti o n i s conven i en t f o r W H O I S se r v i c e use r s w h o a r e su ffi c i en tl y f a m ili a r w it h l angu a ge s t ha t ca n b e d i sp l aye d i n U S - AS C II .

 

H o w eve r , US ASC I I da t a a r e l es s use f u l t o t h e co mm un it y o f D o m a i n N a m e Reg istr a ti o n D a t a D ir ec t o ry Se r v i c e u s e r s w h o a r e on l y f a m ili a r w it h l an g uages t ha t r equ ir e cha r ac t e r se t suppo r t o t he r t ha n U S ASC II . I t i s i m po rt an t t o no t e t ha t t h i s co mm un it y i s li ke l y t o con ti nu e to g r o w . Thu s ac c o mm oda t i n g t h e sub m i ss i o n an d d i sp l a y o f i n t e r na ti ona li ze d r eg i s tr a ti o n da t a i s see n a s a n i m po r tan t evo l u ti ona r y s t e p f o r D o m a i n N a m e Reg i s tr a ti o n D a t a D i r e c t o r y Se r v i ce s s uc h a s t h e W H O I S .

 

I n gene r a l , t h e I RD - W G r ecogn i ze d t ha t i n t e r na ti ona li ze d con t ac t da t a ca n b e tr an sl a t e d o r tr an slit e r a t e d i n t o t h e m u s t b e p r esen t r ep r esen t a ti on . By m us t b e p r esen t t h e IRD-WG m ean t t ha t con t ac t da t a m us t b e m ad e ava il ab l e i n a co mm o n sc ri p t o r l anguage . I n t h i s con t ex t , t r ans l a ti o n i s t h e p r oces s o f convey i n g t h e m ean i n g o f so m e passag e o f t ex t i n on e l anguage , s o t ha t i t ca n b e exp r esse d equ i va l en tl y i n ano t he r l anguage . T r ans lit e r a ti o n i s t h e p r oces s o f r ep r esen ti n g t h e cha r ac t e r s o f a n a l phabe ti ca l o r sy ll ab i c sys t e m o f w riti n g b y t h e cha r ac t e r s o f a conve r s i o n a l phabe t . I f tr ans lit e r a ti o n w e r e des ir ed , t he n t h e m us t b e p r esen t sc ri p t w ou l d b e t h e La ti n sc ri p t . I f tr ans l a t i o n w e r e des ir ed , t he n t h e m u s t b e p r esen t l anguag e w ou l d b e Eng li sh.

 

Th e IRD-WG cons i de r e d fi v e m ode l s t o add r es s t h e tr ans l a ti o n an d tr ans lit e r a ti o n o f do m a i n na m e r eg i s tr a ti o n da t a con t ac t i n f o r m a ti on , bu t i t w a s unab l e t o r eac h con s en s u s o n a s i ng l e m ode l . [26] H o w eve r , i t r ecogn i ze d t ha t t h e tr ans l a ti o n an d tr ans lit e r a ti o n o f con t ac t i n f o r m a ti o n ha d po li c y i m p li c a ti ons , an d t hu s it s F i na l Repo r t con t a i ne d t h e f o ll o w i n g r ec o mm enda t i on :

Reco mm enda ti o n 2 : Th e G N S O counc i l an d t h e SSA C shou l d r eques t a co mm o n I ssu e Repo r t o n tr ans l a ti o n an d tr ans lit e r a ti o n o f con t a ct i n f o r m a ti on . Th e I ssu e Repo r t shou l d cons i de r w he t he r i t i s des ir ab l e t o tr ans l a t e con t ac t i n f o r m a ti o n t o a s i ng l e co mm o n l anguag e o r tr ans lit e r a t e con t ac t i n f o r m a ti o n t o a s i ng l e co mm o n sc ri p t . I t shou l d a l s o cons i de r w h o shou l d bea r t h e bu r de n an d w h o i s i n t h e bes t pos iti o n t o add r es s t hese i ssues . Th e I ssu e Repo r t shou l d cons i de r po lic y ques ti on s r a i se d i n t h is docu m en t an d shou l d a l s o r eco mm en d w he t he r t o s t a r t a po li c y deve l op m en t p r oces s ( P D P ) .

 

Th e A ffir m a ti o n o f Co mm it m en t s s i gne d o n 3 0 Sep t e m be r 200 9 be t w ee n I CA N N an d t h e U S D epa rt m en t o f Co mm e r c e con t a i n s spec ifi c p r ov i s i on s f o r p e ri od i c r ev i e w o f f ou r ke y I CA N N ob j ec ti ves , i nc l ud in g W H O I S Po li cy . [27] Th e W H O I S Po li c y Rev i e w Tea m co m p l e t e d it s r ev i e w an d pub li she d it s F i na l Repo r t o n 11 M a y 2012 . [28] I n it s F i na l Repor t t h e Rev i e w Tea m echoe d t h e IRD-WG b y c a lli n g f o r a W o r k i n g G r ou p t o b e f o r m e d ( Reco mm enda ti on s 1 2 an d 13 ) t o de v e l o p i n t e r na ti ona liz e d do m a i n na m e r eg i s tr a ti o n r equ ir e m en t s t ha t w ou l d i nc l ud e a da t a m ode l t ha t w ou l d add r ess , ( any ) r equ ir e m en t s f o r t h e tr ans l a ti o n o r tr ans lit e r a ti o n o f t h e r eg i s tr a ti o n da t a . I n add iti on , t h e SSA C f u rt h e r e m phas iz e d t h e IRD-WG’ s r eco mm enda ti o n i n SAC055 : W H O I S : B li n d M e n an d a n E l ephan t ( SSA C Co mm en t o n t h e W HO I S Po li c y Rev i e w Tea m F i na l Re po r t ) . [29] I n t h e Repo r t t h e SSA C ag r ee d w it h t h e r eco mm enda ti on s o f t h e Rev i e w Tea m o n tr an sl a ti on /tr an slit e r a ti o n o f r eg i s tr a ti o n da t a an d ca ll e d o n t h e I CA N N Boa r d o f D ir ec t o r s t o adop t Reco mm enda ti o n 2 i n t h e IRD-WG’ s F i na l Repo rt . Th e SSA C a ls o st a t e d t ha t t h e I C A N N Boa r d shou l d pas s a r eso l u ti o n c l ea rl y s t a ti n g t h e c riti ca lit y o f t h e deve l op m en t o f a r eg i s tr a ti o n da t a po li c y de fi n i n g t he pu r po s e o f do m a i n na m e r eg i s tr a ti o n da t a .

 

O n 0 8 N ove m be r 201 2 t h e I CA N N Boa r d o f D ir ec t o r s adopted seve r a l r eso l u ti on s ( 2012 . 11 . 08 . 0 1 - 2012 . 11 . 08 . 02 ) r e l a ti n g t o W H O I S , i n r espons e t o t h e r eco mm enda ti on s i t r ece i ve d fr o m t h e W HO I S Po li c y R e v i e w Tea m an d t h e SSA C desc ri be d above . [30] I n par ti cu l ar , t h e Boar d d ir ec t e d t h e CE O t o:

 

l aunc h a ne w e ff o r t t o r ede fi n e t h e pu r pos e o f co ll ec ti ng , m a i n t a i n i n g an d p r ov i d i n g acces s t o gTL D r eg i s tr a ti o n da t a , an d con si de r sa f egua r d s f or p r o t ec ti n g da t a , a s a f ounda ti o n f o r ne w gTL D po li c y an d c on t r a c t ua l nego ti a ti on s , a s app r op ri a t e ( a s de t a il e d i n t h e 1 N ove m be r 201 2 B oa r d pape r en titl ed , “Ac ti o n P l a n t o Add r es s W HO I S Po li c y Rev i e w Tea m Re po r t Reco mm enda ti on s I CA N N Boar d Sub m i ss i o n N u m be r 201 2 - 11 - 0 1 ) , an d hereb y d ir ec t s p r epa r a ti o n o f a n I ssu e Repo r t o n t h e pu r pos e o f co ll ec ti n g an d m a i n t a i n i n g gTL D r eg i s tr a ti o n da t a , an d o n so l u ti on s t o i m p r ov e accu r ac y an d acces s t o gTL D r eg i s tr a ti o n da t a , a s pa r t o f a B oa r d - i n iti a t e d GN S O po lic y deve l op m en t p r o c ess ; [31]

 

Th e Boa r d s Ac ti o n P l a n env i s i on s t h e poss i b ilit y o f a P D P o n t h e i ssu e o f translation an d tr ans lit e r a ti o n o f con t ac t i n f o r m a ti o n a s f o ll o w s : Th e Boa r d d ir ec t s t h e CE O t o hav e S t a ff : 1 ) t as k a w o r k i n g g r ou p t o de t e r m i n e t h e app r op ri a t e i n t e r na ti ona li ze d do m a in na m e r e g i s tr a ti on da t a r equ ir e m en t s , eva l ua ti n g an y r e l evan t r eco mm enda ti on s fr o m t he SSA C o r GN SO ;
2 ) p r oduc e a da t a m ode l t ha t i nc l ude s ( an y ) r equ ir e m en t s f o r t h e tr ans l a ti o n o r tr ans lit e r a ti o n o f t h e r eg i s tr a ti o n da t a , t ak i n g i n t o accoun t t h e r esu lt s o f an y P D P i n iti a t e d b y t h e G N S O o n tr an sl a ti on / tr an slit e r a ti on , an d t h e s t anda r d i ze d r ep l a c e m e nt p r o t oco l unde r deve l op m en t i n t h e I ETF s W eb-base d Ex t en si b l e I n t e r ne t Registration Data (WEIRDS) Working Group.

 

Th e Ac ti o n P l a n f u rt he r t ask s t h e CE O t o c r e a t e a n Expe r t W o r k i n g G r ou p o n gTL D D ir ec t o r y Serv i ce s t o : c r ea t e m a t e ri a l t o l aunc h GN S O po li c y w o r k an d i n f o r m con tr a c t ua l nego ti a ti on s , a s app r op ri a t e . W o r k i n g g r ou p ou t pu t i s expec t e d w it h i n 9 0 day s an d w il l i dea ll y i nc l ud e a s tr a w - m a n m ode l f o r m ana gi n g g TL D r eg i s tr a ti o n da t a . Th e w o r k i n g g r oup s ou t pu t f o r m t h e bas i s f o r a n I ssue s Repor t t o acco m pan y Boar d - i n iti a t ed , exped it e d GN S O po lic y w o r k t ha t i s expec t e d t o r esu l t i n consensu s po li c y t ha t , a t a m i n i m u m , add r esse s t h e pu r pos e o f co ll ec ti ng , m a i nta i n i n g an d m ak i n g ava il ab l e gTL D r eg i s tr a ti o n da t a , an d r e l a t e d accu r acy , da t a p r o t ec ti on , an d acces s i ssues . O n 1 3 Dece m be r 201 3 t h e I CA N N CE O announce d t h e f o r m a ti o n o f t h e Expe r t W o r k i n g G r oup. O n 1 4 Feb r ua r y 201 3 I CA N N announce d t h e s e l ec ti o n o f t h e m e m be r s o f t h e Expe r t W o r k i n g G r ou p o n gTL D D ir ec t o r y Se r v i c es . [32]


8.     Annex A - Charter

 

WG Name:

Translation and Transliteration of Contact Information PDP Working Group

Section I:  Working Group Identification

Chartering Organization(s):

Generic Names Supporting Organization (GNSO) Council

Charter Approval Date:

20 November 2013

Name of WG Chair:

TBD

Name(s) of Appointed Liaison(s):

Ching Chiao

 

WG Workspace URL:

https://community.icann.org/display/tatcipdp/Translation+and+Transliteration+of+Contact+Information+PDP+Home

WG Mailing List:

TBD

GNSO Council Resolution:

Title:

Motion to Approve the Charter for the Translation and Transliteration of Contact Information PDP Working Group

Ref # & Link:

http://gnso.icann.org/en/council/resolutions#201311

Important Document Links:

Section II:  Mission, Purpose, and Deliverables

Mission & Scope:

Background

On 17 October 2012 the GNSO Council requested an Issue Report to address the three issues that were identified by the IRD-WG:

  • Whether it is desirable to translate contact information to a single common language or transliterate contact information to a single common script.
  • Who should decide who should bear the burden translating contact information to a single common language or transliterating contact information to a single common script. This question relates to the concern expressed by the Internationalized Registration Data Working Group (IRD-WG) in its report that there are costs associated with providing translation and transliteration of contact information.  For example, if a policy development process (PDP) determined that the registrar must translate or transliterate contact information, this policy would place a cost burden on the registrar. 
  • Whether to start a PDP to address these questions .`

The Final Issue Report on translation and transliteration of contact information was submitted to the GNSO Council on 21 March 2013 and on 13 June 2013 the GNSO Council approved the initiation of a PDP on the translation and transliteration of contact information.

Mission and Scope

The PDP Working Group is tasked to provide the GNSO Council with a policy recommendation regarding the translation and transliteration of contact information. This recommendation also will be considered by a separate Expert Working Group that is tasked with determining the appropriate Internationalized Domain Name registration data requirements and data model for Registration Data Directory Services (such as WHOIS).  As part of its deliberations on this issue, the PDP WG should, at a minimum, consider the following issues as detailed in the Final Issue Report:

  • Whether it is desirable to translate contact information to a single common language or transliterate contact information to a single common script.
  • Who should decide who should bear the burden translating contact information to a single common language or transliterating contact information to a single common script. This question relates to the concern expressed by the Internationalized Registration Data Working Group (IRD-WG) in its report that there are costs associated with providing translation and transliteration of contact information.  For example, if a policy development process (PDP) determined that the registrar must translate or transliterate contact information, this policy would place a cost burden on the registrar. 

With respect to the first issue above, it should be noted that text requests and content returned by Domain Name Registration Data Services (such as WHOIS) are historically encoded using US-American Standard Code for Information Interchange (ASCII). This is a character-encoding scheme originally based on the English alphabet.  While the WHOIS protocol does not specify US-ASCII as the exclusive character set for text requests and text content encoding, the current situation is that no standards or conventions exist for all WHOIS protocol implementations to signal support of character sets other than US-ASCII.

In the context of these issues, “contact information” is a subset of Domain Name Registration Data.  It is the information that enables someone using a Domain Name Registration Data Directory Service (such as WHOIS) to contact the domain name registration holder.  It includes the name, organization, and postal address of the registered name holder, technical contact, as well as administrative contact.  Domain Name Registration Data is accessible to the public via a Directory Service (also known as the WHOIS service). The Registrar Accreditation Agreement (RAA 3.3.1) specifies the data elements that must be provided by registrars (via Port 43 and via web-based services) in response to a query, but it does not require that data elements, such as contact information, must be translated or transliterated.

With respect to the two issues identified above concerning the translation and transliteration of contact information, the following additional background may be useful.  On the first issue, whether it is desirable to translate contact information to a single common language or transliterate contact information to a single common script, the IRD-WG noted that, “[t]o balance the needs and capabilities of the local registrant with the need of the (potential) global user of this data, one of the key questions … is whether DNRD-DS  [Domain Name Registration Data Directory Services] should support multiple representations of the same registration data in different languages or scripts.”  In particular, the IRD-WG members discussed whether it is desirable to adopt a “must be present” representation of contact data, in conjunction with local script support for the convenience of local users.  By “must be present” the IRD-WG meant that contact data must be made available in a common script.

In general, the IRD-WG recognized that, “the internationalized contact data can be translated or transliterated into the ‘must be present’ representation. As noted above, in this context, Translation is the process of conveying the meaning of some passage of text in one language, so that it can be expressed equivalently in another language. Transliteration is the process of representing the characters of an alphabetical or syllabic system of writing by the characters of a conversion alphabet.”  Based on this definition, and consistent with the current state of domain name registration data, the IRD-WG noted that if transliteration were desired, then the “must be present” script would be the Latin script. If translation were desired, then the “must be present” language would be English.

The IRD-WG did note that many language translation systems are inexact and cannot be applied repeatedly to translate from one language to another. Thus the IRD-WG noted that there will likely be problems with both consistency and accuracy, such as:

  • Translation/transliteration may vary significantly across languages using the same script.
  • Two people may translate/transliterate differently even within a language and the same person may translate/transliterate differently at different times for the same language.
  • How would a registrar determine which particular spellings to use for a particular registrant?  How would a registrant ever verify the correctness of a translation or transliteration, even if presented such data by the registrar or by a third organization that does the translation/transliteration?

Furthermore, the IRD-WG noted that for a given script, there may exist multiple systems for transliteration into Latin scripts. In the case of Chinese, the multiple transliteration systems are not only quite different from each other, but most of the systems use particular Latin characters to represent phonemes that are quite different from the most common phoneme-character pairings in European languages.

Also, it is unclear whether translation or transliteration would serve the needs of the users of contact data. For example it is unclear that translating the name of the registrant and city would be useful. Would one have to translate "Los Angeles" into " City of the Angels" and translate “Beijing” into "Northern Capital"?  The PDP should explore whether such translations facilitate or hinder the ability to contact the registrant.

Finally, as part of its discussion on this first question the WG should also consider discussing the following questions:

  • What exactly the benefits to the community are of translating and/or transliterating contact data, especially in light of the costs that may be connected to translation and/or transliteration?
  • Should translation and/or transliteration of contact data be mandatory for all gTLDs?
  • Should translation and/or transliteration of contact data be mandatory for all registrants or only those based in certain countries and/or using specific non-ASCII scripts?
  • What impact will translation/transliteration of contact data have on the WHOIS validation as set out under the 2013 Registrar Accreditation Agreement?
  • When should any new policy relating to translation and transliteration of contact information come into effect?

To help to determine whether translation and/or transliteration should be mandatory, and to help the Working Group to consider to the costs of translation and/or transliteration, the Working Group may wish to develop a matrix elaborating a ruling and costs in each possible case for countries and non-ASCII scripts.  The second issue, who should decide who should bear the burden translating contact information to a single common language or transliterating contact information to a single common script, relates to the concern expressed by the IRD-WG in its report that there are costs associated with providing translation and transliteration of contact information.  For example, if a PDP determined that the registrar must translate or transliterate contact information, this policy would place a cost burden on the registrar.  The IRD-WG considered several alternatives to address translation and transliteration of contact information as follows: 

  • The registrant submits the localized information as well the translated or transliterated information.
  • The registrant only submits the localized information, and the registrar translates and transliterates all internationalized contact information on behalf of the registrant.
  • The registrant only submits the localized information, and the registrars provide a point of contact at a service that could provide translation or transliteration upon request for a fee to be paid by the requester.
  • The registrant only submits the localized information, and the registry provides translation or transliteration.
  • The end users of the registration data translate and transliterate the contact information.

The PDP-WG will not be limited to considering the above alternatives, but will be encouraged to consider all possible alternatives.  The PDP-WG also may consult with ICANN Legal staff when considering alternatives.  In addition, the PDP-WG should review the work of other PDPs and WGs relating to IDNs and WHOIS.  These include the following PDPs and WGs: gTLD Data Registration Data Services , Thick WHOIS , WHOIS Survey WG , IRD-WG , the IDN Variant TLDs Issues Project , Technical Evolution of WHOIS Service , and the Expert Working Group on gTLD Directory Services .

 

As part of its deliberation on who should decide who should bear that cost of translation and/or transliteration, WG members might also want to discuss who they believe should bear the cost, bearing in mind, however, the limits in scope set in the Initial Report on this issue.

During their deliberations the members of the IRD-WG recognized that many registrants will need to access domain names in their local scripts and languages, which is the one of the primary reasons for the expansion of internationalized domain names.  Therefore, the IRD-WG determined that it is unreasonable to assume all registrants – wherever they happen to be located – will be able to enter the registration data in scripts or languages other than their local script or language.

The PDP WG is also expected to consider any information and advice provided by other ICANN Supporting Organizations and Advisory Committees on this topic. The WG is strongly encouraged to reach out to these groups for collaboration at an early stage of its deliberations, to ensure that their concerns and positions are considered in a timely manner.

Finally, the Working Group is expected to review/check relevant recommendations that may arise from the Expert Working Group on gTLD Directory Service if/when those become available and determine possible linkage to the issues at hand.

Objectives & Goals:

To develop, at a minimum, an Initial Report and a Final Report regarding translation and transliteration of contact information to be delivered to the GNSO Council, following the processes described in Annex A of the ICANN Bylaws and the GNSO PDP Manual.

Deliverables & Timeframes:

The WG shall respect the timelines and deliverables as outlined in Annex A of the ICANN Bylaws and the PDP Manual. As per the GNSO Working Group Guidelines, the WG shall develop a work plan that outlines the necessary steps and expected timing in order to achieve the milestones of the PDP as set out in Annex A of the ICANN Bylaws and the PDP Manual and submit this to the GNSO Council.

Section III:  Formation, Staffing, and Organization

Membership Criteria:

The Working Group will be open to all interested in participating. Individuals with experience in translation and transliteration of languages and scripts will be encouraged to join, as well as those with experience in internationalized domain names (IDNs).  New members who join after certain parts of work has been completed are expected to review previous documents and meeting transcripts.  

Group Formation, Dependencies, & Dissolution:

This WG shall be a standard GNSO PDP Working Group. The GNSO Secretariat should circulate a ‘Call For Volunteers’ as widely as possible in order to ensure broad representation and participation in the Working Group, including:

-                 Publication of announcement on relevant ICANN web sites including but not limited to the GNSO and other Supporting Organizations and Advisory Committee web pages; and

-                 Distribution of the announcement to GNSO Stakeholder Groups, Constituencies and other ICANN Supporting Organizations and Advisory Committees

Working Group Roles, Functions, & Duties:

The ICANN Staff assigned to the WG will fully support the work of the Working Group as requested by the Chair including meeting support, document drafting, editing and distribution and other substantive contributions when deemed appropriate.
Staff assignments to the Working Group:

            GNSO Secretariat

            2 ICANN policy staff members (Julie Hedlund and Lars Hoffmann)

The standard WG roles, functions & duties shall be applicable as specified in Section 2.2 of the Working Group Guidelines.

Statements of Interest (SOI) Guidelines:

Each member of the Working Group is required to submit an SOI in accordance with Section 5 of the GNSO Operating Procedures.

Section IV:  Rules of Engagement

Decision-Making Methodologies:

The Chair will be responsible for designating each position as having one of the following designations:

  • Full consensus - when no one in the group speaks against the recommendation in its last readings.  This is also sometimes referred to as Unanimous Consensus.
  • Consensus - a position where only a small minority disagrees, but most agree. [Note: For those that are unfamiliar with ICANN usage, you may associate the definition of ‘Consensus’ with other definitions and terms of art such as rough consensus or near consensus. It should be noted, however, that in the case of a GNSO PDP originated Working Group, all reports, especially Final Reports, must restrict themselves to the term ‘Consensus’ as this may have legal implications.]
  • Strong support but significant opposition - a position where, while most of the group supports a recommendation, there are a significant number of those who do not support it.
  • Divergence (also referred to as No Consensus ) - a position where there isn't strong support for any particular position, but many different points of view.  Sometimes this is due to irreconcilable differences of opinion and sometimes it is due to the fact that no one has a particularly strong or convincing viewpoint, but the members of the group agree that it is worth listing the issue in the report nonetheless.
  • Minority View - refers to a proposal where a small number of people support the recommendation.  This can happen in response to a Consensus , Strong support but significant opposition , and No Consensus; or, it can happen in cases where there is neither support nor opposition to a suggestion made by a small number of individuals.

 

In cases of Consensus , Strong support but significant opposition , and No Consensus , an effort should be made to document that variance in viewpoint and to present any Minority View recommendations that may have been made.  Documentation of Minority View recommendations normally depends on text offered by the proponent(s).  In all cases of Divergence, the WG Chair should encourage the submission of minority viewpoint(s).

 

The recommended method for discovering the consensus level designation on recommendations should work as follows:

  1. After the group has discussed an issue long enough for all issues to have been raised, understood and discussed, the Chair, or Co-Chairs, make an evaluation of the designation and publish it for the group to review.
  2. After the group has discussed the Chair's estimation of designation, the Chair, or Co-Chairs, should reevaluate and publish an updated evaluation.
  3. Steps (i) and (ii) should continue until the Chair/Co-Chairs make an evaluation that is accepted by the group.
  4. In rare case, a Chair may decide that the use of polls is reasonable. Some of the reasons for this might be:
    • A decision needs to be made within a time frame that does not allow for the natural process of iteration and settling on a designation to occur.
    • It becomes obvious after several iterations that it is impossible to arrive at a designation. This will happen most often when trying to discriminate between Consensus and Strong support but Significant Opposition or between Strong support but Significant Opposition and Divergence.

 

Care should be taken in using polls that they do not become votes.  A liability with the use of polls is that, in situations where there is Divergence or Strong Opposition , there are often disagreements about the meanings of the poll questions or of the poll results.

 

Based upon the WG's needs, the Chair may direct that WG participants do not have to have their name explicitly associated with any Full Consensus or Consensus view/position.  However, in all other cases and in those cases where a group member represents the minority viewpoint, their name must be explicitly linked, especially in those cases where polls where taken.

 

Consensus calls should always involve the entire Working Group and, for this reason, should take place on the designated mailing list to ensure that all Working Group members have the opportunity to fully participate in the consensus process.  It is the role of the Chair to designate which level of consensus is reached and announce this designation to the Working Group. Member(s) of the Working Group should be able to challenge the designation of the Chair as part of the Working Group discussion.  However, if disagreement persists, members of the WG may use the process set forth below to challenge the designation.

 

If several participants (see Note 1 below) in a WG disagree with the designation given to a position by the Chair or any other consensus call, they may follow these steps sequentially:

  1. Send email to the Chair, copying the WG explaining why the decision is believed to be in error.
  2. If the Chair still disagrees with the complainants, the Chair will forward the appeal to the CO liaison(s).  The Chair must explain his or her reasoning in the response to the complainants and in the submission to the liaison. If the liaison(s) supports the Chair's position, the liaison(s) will provide their response to the complainants.  The liaison(s) must explain their reasoning in the response.  If the CO liaison disagrees with the Chair, the liaison will forward the appeal to the CO.  Should the complainants disagree with the liaison support of the Chair’s determination, the complainants may appeal to the Chair of the CO or their designated representative.  If the CO agrees with the complainants’ position, the CO should recommend remedial action to the Chair.
  3. In the event of any appeal, the CO will attach a statement of the appeal to the WG and/or Board report. This statement should include all of the documentation from all steps in the appeals process and should include a statement from the CO (see Note 2 below).

 

Note 1 :  Any Working Group member may raise an issue for reconsideration; however, a formal appeal will require that that a single member demonstrates a sufficient amount of support before a formal appeal process can be invoked. In those cases where a single Working Group member is seeking reconsideration, the member will advise the Chair and/or Liaison of their issue and the Chair and/or Liaison will work with the dissenting member to investigate the issue and to determine if there is sufficient support for the reconsideration to initial a formal appeal process.

 

Note 2 :  It should be noted that ICANN also has other conflict resolution mechanisms available that could be considered in case any of the parties are dissatisfied with the outcome of this process.

 

Status Reporting:

As requested by the GNSO Council, taking into account the recommendation of the Council liaison to this group.

Problem/Issue Escalation & Resolution Processes:

The WG will adhere to ICANN’s Expected Standards of Behavior as documented in Section F of the ICANN Accountability and Transparency Frameworks and Principles, January 2008.

 

If a WG member feels that these standards are being abused, the affected party should appeal first to the Chair and Liaison and, if unsatisfactorily resolved, to the Chair of the Chartering Organization or their designated representative.  It is important to emphasize that expressed disagreement is not, by itself, grounds for abusive behavior.  It should also be taken into account that as a result of cultural differences and language barriers, statements may appear disrespectful or inappropriate to some but are not necessarily intended as such.  However, it is expected that WG members make every effort to respect the principles outlined in ICANN’s Expected Standards of Behavior as referenced above.

 

The Chair, in consultation with the Chartering Organization liaison(s), is empowered to restrict the participation of someone who seriously disrupts the Working Group.  Any such restriction will be reviewed by the Chartering Organization.  Generally, the participant should first be warned privately, and then warned publicly before such a restriction is put into place. In extreme circumstances, this requirement may be bypassed.

 

Any WG member that believes that his/her contributions are being systematically ignored or discounted or wants to appeal a decision of the WG or CO should first discuss the circumstances with the WG Chair.  In the event that the matter cannot be resolved satisfactorily, the WG member should request an opportunity to discuss the situation with the Chair of the Chartering Organization or their designated representative.

 

In addition, if any member of the WG is of the opinion that someone is not performing their role according to the criteria outlined in this Charter, the same appeals process may be invoked.

Closure & Working Group Self-Assessment:

The WG will close upon the delivery of the Final Report, unless assigned additional tasks or follow-up by the GNSO Council.

Section V:  Charter Document History

Version

Date

Description

1.0

19 September 2013

Final version submitted by the DT to the GNSO Council for consideration

Staff Contact:

Julie Hedlund

Email:

Policy-staff@icann.org

 


Annex B – Comment Review Tool

Translation and Transliteration of Contact Information PDP Working Group

 

For complete overview of comments received, please see http://forum.icann.org/lists/comments-transliteration-contact-initial-16dec14/

 

#

Comment

 

Who / Where

WG Response

Do you agree with response?

Preliminary Recommendation (Prelim-Rec) #1: The Working Group could recommend that it is not desirable to make transformation of contact information mandatory. Any parties requiring transformation are free to do it ad hoc outside the Domain Name Relay Daemon.

  1.  

KeySystems supports the RrSG statement. In addition, they suggest that there should be no requirement to translate or transliterate contact information to single common script. The burden of accession and understanding contact information is best placed on the side of the beneficiary of such data, i.e. the data requestor

Key Systems

Need to verify the language and assure that our remit is really only the issues of whether registration data should be transformed – anything else is beyond our charter.

”Acquiring” is a better word than “accession”.

  1.  

Supportive of this recommendation. Translation/Transliterating into English is ‘nuts’ and offensive.

Michele Neylon

No action necessary; already addressed in Initial Report.

  1.  

Strongly support this recommendation.

Introducing a mandatory requirement to transform WHOIS data into one or more commonly used languages would not support the goal of linguistic diversity, but would introduce costs, complexity and risk which outweigh the perceived benefits.

RrSG [33]

No action necessary; already addressed in Initial Report.

  1.  

IPC opposes this recommendation and strongly supports mandatory translation and/or transliteration of contact information in all generic top level domains.

Having registration data in an unlimited number of scripts is troublesome.

IPC

In fact the number of scripts is not unlimited; it is limited by the number of scripts being used in registrations.

 

  1.  

ARI actively supports recommendation #1

Donna Austin (ARI Registry Services)

No action necessary.

  1.  

Strongly oppose this recommendation

Mandatory transformation to globally accessible and searchable languages is necessary to the continued development of a secure and trusted internet

BC

Data in their original form – if/when machine-readable – are easier and more consistently searchable. Transformation is limited to registration data submitted by registrants, so verifying accuracy of registration data is paramount; not transformation of the same.

The argument here to oppose the recommendation is necessary to the continued development of a secure and trusted Internet for a specific sub-set of Internet users using Whois lookup services and who are familiar with the language/script in which contact data will be transformed. Other registrants and contracted parties will be disparately burdened.

It is important to bear in mind that the scope of transformation that is considered by this PDP is limited to registration data as submitted by registrants.

  1.  

Transformation does not have to be mandatory ; there should be a provision for [contact information] to be maintained in two forms: a mandatory ‘canonical’ form in the original language, and an optional ‘transformed’ form after transformation – the latter should be a close approximation to the original that can be parsed, understood and used by other communities.

ALAC

If there were two different forms there could be an issue of discrepancies between the two data sets.

Optional transformation must be subject to a common standard established by the stakeholders and not merely left to registrants in order to avoid discrepancies.

This is recommended for consideration by another PDP.

  1.  

Registrars should provide Registrants with the option of entering both forms while creating new entries or editing exiting ones

ALAC

The contact data in the local language/script would be authoritative and verified (possibly validated). Providing an option for a second non-authoritative data set is not necessarily useful.

  1.  

Support the recommendation against mandatory transformation of contact information – as anything else would disproportionally burden small players and underserved regions

dotShabaka (Registry Operator)

No action necessary.

  1.  

Does not support this recommendation.

FICPI

 

  1.  

NCSG endorses this recommendation.

NCSG

 

Prelim-Rec #2: The Working Group could recommend that any new Registration Directory Service (RDS) databases contemplated by ICANN should be capable of receiving input in the form of non-Latin script contact information. However, all data fields of such a new database should be tagged in ASCII to allow easy identification of what the different data entries represent and what language/script has been used by the registered name holder.

  1.  

Tagging contact data to identify the script or language should be optional.

Key Systems

No action necessary

  1.  

Registrants should be able to enter contact data in their own language and to do so will enhance the overall accuracy of the distributed WHOIS database.

RrSG / RySG

Agreement with this point

 

  1.  

As long as transformation is mandatory the IPC has no objection. If transformation is not mandatory data information should be displayed as selectable text and not as an image .

IPC

The Working Group agrees with the second sentence of this statement.

 

  1.  

ARI actively supports recommendation #2.

Donna Austin (ARI Registry Services)

No action necessary.

  1.  

BC supports this recommendation.

BC

No action necessary.

  1.  

Data fields should be in searchable text not images.

BC

The Working Group agrees and this will be emphasized again in the Final Report.

  1.  

All ICANN databases, forms, and documents should provide for capturing, displaying, storing and maintaining both of the forms .

ALAC

Very wide-ranging comment – but potentially only related to the two forms they propose earlier. See response no.7.

  1.  

dotShabaka (Registry Operator) supports this recommendation.

dotShabaka (Registry Operator)

No action necessary.

  1.  

NCSG endorses this recommendation.

NCSG

No action necessary.

  1.  

The recommendation be amended to read: ‘The WG could recommend that any new Registration Directory Service (RDS) WHOIS database, now and in the future , ….

NCSG

Make sure that we think that our work is limited to registration data – not all Whois. But the Working Group agrees that our work should not depend on the EWG outcome.

Prelim-Rec #3: The Working Group could recommend that registered name holders enter their contact information data in the language or script appropriate for the language that the registrar operates in .

  1.  

Key System does not support this Preliminary Recommendation as most registrars operate internationally. The language the registrar operates under may therefore not be appropriate to serve customers elsewhere. This recommendation would hinder competition between registrars and hinder free transferability of domains. If ‘operate under’ were changed to ‘supported by’ Key Systems would support this Recommendation.

Registrants should be able to fill in the registration data in their language or script, provided such script is supported by the sponsoring registrar.

Key Systems

Agree with the suggestion to change “operates under” to “supported by”.

 

Action: Wording should be changed to ‘supported by’.

 

  1.  

IPC supports this if transformation is mandatory. Otherwise transformation should happen if the submitted data is not in Latin characters of a UN language

 

Agree with the suggestion that transformation, if any, should happen only if the submitted data are not in Latin characters.

  1.  

BC supports this recommendation provided the transformation to ASCII is mandatory – we suggest that t he language of the Registrar’s Term of Service be used to determine the appropriate language

 

The Working Group notes the BC’s input. This issue will be addressed in the final report.

  1.  

dotShabaka (Registry Operator) recommends further community discussion to understand better how the PDP’s effort and the effort of other WHOIS related will fit together

dotShabaka (Registry Operator)

The Working Group agrees – this will be addressed in the Final Report. This is recommended for consideration by another PDP.

  1.  

NCSG endorses this recommendation

NCSG

 

Prelim-Rec #4: The Working Group could recommend that the registrar and registry assure that the data fields are consistent, that the entered contact information data are verified (in accordance with the Registrar Accreditation Agreement (RAA)) and that the data fields are correctly tagged to facilitate transformation if it is ever needed.

  1.  

This should be strictly optional as neither registrars nor registrants can be expected to know the tag to every given data set.

Key Systems

A requirement for marking data fields is out of scope for this PDP. This is recommended for consideration by another PDP.

  1.  

The IPC suggests this recommendation to be amended to read: ‘ The WG recommends that the registrar and registry assure that the data fields are consistent, that the entered contact information data are verified (in accordance with the RAA) and that the data fields are correctly tagged to facilitate the mandatory transformation.’

IPC

WG agrees that whether transformation is mandatory or not, the data need to be marked in some way, possibly tagged, to be clear which script is used. There may be more than one language in the data.

This is recommended for consideration by another PDP.

  1.  

BC supports mandatory transformation but otherwise supports the recommendations that the registrar and registry assure that the fields are consistent, the data is verified, and that data fields are correctly tagged to facilitate transformation.

BC

See response to no. 28.

  1.  

NCSG endorses this recommendation

NCSG

No action necessary.

Prelim-Rec #5: The Working Group could recommend that if registrars wish to perform transformation of contact information, these data should be presented as additional fields (in addition to the local script provided by the registrant), to allow for maximum accuracy.

  1.  

Key Systems agrees with this Recommendation

Key Systems

No action necessary.

  1.  

WHOIS data should be treated similar to the postal addressing system, where transformation is strictly optional. Ultimately it is the responsibility of the sender to ensure that the recipient can be reached if a different script is used than the one used locally

RrSG

This is recommended for consideration by another PDP.

The Working Group emphasizes that the registrant/registrar is responsible to be contactable by submitting correct data.

  1.  

The IPC suggests that this recommendation be amended to read: ‘ The WG recommends registrars’ mandatory transformation of contact information shall be presented as additional fields (in addition to the local script provided by the registrant), to allow for maximum accuracy .

IPC

That there should be two sets of fields for any transformation is recommended for consideration by another PDP. As regards accuracy, see no.13 above.

 

  1.  

BC supports mandatory transformation but otherwise supports the recommendation that the transformed data be presented in additional fields.

BC

See response no. 33.

 

  1.  

NCSG endorses this recommendation.

NCSG

No action necessary.

Prelim-Rec #6: The Working Group could recommend that the field names of the Domain Name Relay Daemon be translated into as many languages as possible.

  1.  

The IPC has no objection to this recommendation; however also see our introductory comments, and comments regarding Recommendation #1 [note from staff: these comment are collated in this document under ‘questions/comments below].

The IPC points out that since the WG’s charter is to determine ‘who should bear the burden’ of transformation, it stands to reason that the WG should specify a recommendation of ‘who should bear the burden’ of translating these fields, once clarified what they are.

IPC

The WG’s charter says, as a secondary question, “Who should decide who should bear the burden [of] translating contact information to a single common language or transliterating contact information to a single common script”. In other words, the responsibility for deciding who should bear the burden of transformation does not lie with this working group.

 

  1.  

The BC does not object to this recommendation but we would point out that translation of field names into ‘as many languages as possible’ is a vague operational standard and will impose additional costs on the entities displaying field names for user entries.

BC

That the Whois replacement system would allow for the easy addition of field names in additional languages is recommended for consideration by another PDP.

Data should be identifiable by a non-expert; how this should be done is a matter for another PDP and implementation.

  1.  

dotShabaka (Registry Operator) recommends further community discussion to understand better how the PDP’s effort and the effort of other WHOIS related will fit together

dotShabaka (Registry Operator)

See response no. 25.

 

  1.  

NCSG endorses this recommendation

NCSG

See response no. 37.

Prelim-Rec #7: Based on recommendations #1-#6, the question of who should bear the burden of translating or transliterating contact information to a single common script is moot.

  1.  

The main burden should lie on the parties collecting and maintaining the information (i.e. registrar, registry, reseller)

IPC

The WG is of the opinion that the burden could also include ‘liability’ not just ‘cost’ – WG also points out that the remit of the group is to determine who decides who bears the burden (should the WG recommend mandatory transformation).

Would these costs be proportional to operational profits?

  1.  

The burden should lie with the beneficiary , i.e. the requestor of information.

KeySystems

See response no. 40.

 

  1.  

The BC supports mandatory transformation and does therefore not consider the issue moot. We believe the cost should be treated as part of the regular cost of doing business for the parties collecting and maintaining the information, r egistries, registrars and re-sellers.

BC

The WG questions whether the “regular cost of doing business” would be proportional to operational income/profits, especially in light of its opinion that the overall burden could also include ‘liability’, not just ‘cost’ and if transformation were recommended to be mandatory.

This PDP should determine who decides who should carry the burden, but not decide to place it on contracted parties collecting and maintaining the information, or any other stakeholder.

  1.  

NCSG endorses this recommendation.

NCSG

No action necessary.

  1.  

Transforming all records despite the fact that only a fraction thereof will ever be requested by a requestor would result in a significant cost-benefit imbalance.

Key Systems

See responses no. 40 & 42.

  1.  

Costs should be born by registries/registrars/resellers .

FICPI

See comment no. 40.

Arguments and Questions brought to the WG

  1.  

Contact-ability of registrants is always guaranteed by the presence of the email address data.

Key Systems

That copying and pasting of machine readable data is recommended for consideration by another PDP. One issue is that holders don’t always respond to communications (and not just for language reasons), although they have a contractual obligation to provide and update correct contact data.

  1.  

All requestors who do not share the common script or language (if this was mandated) will have to perform translation/transliteration; therefore, transforming into one script/language that is not the one of the requestor seems inappropriate.

Key Systems

Argument already reflected in Initial Report.

  1.  

Translating proper nouns is impractical if not impossible

Michele Neylon

Comment already considered and reflected in Initial Report on p.13.
See also response no. 50.

  1.  

Report would benefit from addressing the question of ‘cost-benefit’ evaluation of transforming contact data such as:

-         Mandatory transformation would require additional data fields that would need to be added to each registry database and supported by every accredited registrar – especially problematic in underserved regions

-         Proportion of domain name subject to a law enforcement query or brand protection intervention is extremely low, approximately 0.1%; UDRP intervention is even lower .

-         Registrations are localized and transliteration would be superfluous

Transformation/translation would not be proportionate to the expected benefit

RrSG/RySG

Many members agreed – some disagreed with these statements.

 

  1.  

Will there be rules or standards governing translation of non-ASCII characters so that it can be done programmatically? Will a common system be used or are we all just relying on free services like Google Translate?

RrSG/RySG

Google Translate is only effective for certain languages not for all – proper nouns are also a substantial reason why it is difficult to rely on existing automated transformation tools.
It may be possible to use the EEE-PPAT database (ECOOM-EUROSTAT-EPO PATSTAT Person Augmented Table) in order to harmonize names and even Company names.

Any standard that is mandated by a policy may create liability on a registrant who unknowingly does not adhere to it. Furthermore, in many cases, it may be appropriate to disregard the standard, particularly when transformation of proper nouns is the issue.

These are suggestions only useful in the event of a recommendation for mandatory transformation and do not affect the decision to transform mandatorily or not.

  1.  

I f translation cannot be automated and human judgment is required, who is responsible for doing it?

RrSG/RySG

The remit of this working group is who should decide who should bear the burden.

  1.  

If the registrant is responsible for providing translated data, what if they do not know what it should be?

RrSG/RySG

Agreed that this is a problem – also related to the issue of ‘ownership’ – who owns the data and has the authority to agree to/confirm transformations.

  1.  

What if a third-party disputes the accuracy of a transliteration?

RrSG/RySG

This also relates to ‘ownership’; see response no. 52 above, also response no. 40 & 42.

  1.  

Is the registrant’s consent required before a transliteration is published in the WHOIS and can they withhold consent?

RrSG/RySG

If a transliteration standard is followed, it is unlikely that discrepancies would be large enough for this issue to arise.

This is recommended for consideration by another PDP.

  1.  

What if a registrant wants to change an “approved” transliteration?

RrSG/RySG

This is recommended for consideration by another PDP. If transliteration standards are consistently implemented, any such changes should be minimal.

In the case of many languages, there will not be an approved transliteration for the foreseeable future.

  1.  

Is a WHOIS verification required every time one of these transliterated fields are updated?

RrSG/RySG

No; the working group suggests that the original form is authoritative and the one to be verified.

This is recommended for consideration by another PDP.

  1.  

Where does the requirement for data transformation end? Could Chinese law enforcement agents require a contracted party to translate/transliterate existing English contact details into Mandarin? Or, what if the original registration was in a third language/script, for example Russian Cyrillic? Would that translation skip English and go directly to Chinese?  What is the service provider supported neither of these languages?

RrSG/RySG

This argument was already presented in the Initial Report.

 

  1.  

Compliance should consider budgetary impact of the human resources needed to review translated WHOIS data

RrSG/RySG

Agreed. Costs could be substantial if the whole database (except for ASCII entries) were to be transformed.

  1.  

Only 5% of the world are native English speakers; transforming into US ASCII would not benefit searchers that are not familiar with Latin script.

RrSG/RySG

Similar argument made in Initial Report.

 

  1.  

Next billion internet users will not be familiar with Latin script – making.

RrSG/RySG

See response no. 59.

  1.  

Transformation will not make searchability easier as transformation of the same name/word might result in separate transformation processes.

RrSG/RySG

Many agreed and it relates to the problem of consistent (as well as accurate) transformation, especially when consistency of transformation of the same registrant’s data is required across different registrars.

  1.  

Flight of bad actors is weak argument as there are very few bad actors (but many domain names) as people tend to host locally and thus transformation will be of very limited use since ‘least translatable’ would assume that the searcher and the registrant speak different languages/use different scripts.

RrSG/RySG

The low number of bad actors is the current situation; theoretically it could change.

 

  1.  

#1 and #6 refers to Domain Name Relay Daemon – define or discard.

IPC

WG will use the term ‘Whois contact information’.

  1.  

IPC finds it counterproductive to evaluate the feasibility of data translation and transliteration together , in part because this combination gives rise to the argument that ‘automated systems would not be able to know when to translate and when to transliterate’ – in the vast majority of cases transliteration is most important to fulfill its function of enhancing transparency and accountability in the DNS; Bangkok is noted as an exception.

IPC

Some argued that transparency is not enhanced (or not sufficiently enhanced) by transforming into ASCII (see also response no. 6 and 65). Similar argument made in Initial Report.

Bangkok is not the only exception and the fact that foreign language equivalents of “road” and “street” would ideally be translated is also an issue.

  1.  

Mandatory transformation of all contact information would allow for a more transparent, accessible and arguably more easily searchable database.

IPC

No action necessary already addressed in Initial Report and will be re-emphasized in Final Report.

 

  1.  

Currently WHOIS is in US-ASCII for vast majority of gTLDs, making WHOIS a useful global resource by enabling the greatest number of registration data users to read the data. The alternative, having data in an unlimited number of scripts, is troubling.

IPC

See response no. 37.

 

  1.  

A global WHOIS search, providing access to data in as uniform a fashion as possible is necessary for the data registration service to achieve its goal of providing transparency and accountability for the DNS .

IPC

Some agreed with this; others felt that data in several original languages may be uniform if they are verified and accessible.

 

  1.  

The more global the impact, the more important it is for data to be accessible in globally searchable languages. Example: EU Trademarks registered in 12 languages; International Trademark Registrations (covering 92 territories) use three languages (English, French, Spanish).

IPC

Some voiced their concern that Whois contact data are not the same as trademarks and thus cannot be compared. Some pointed out that this is still an interesting example that merits further reflections.

 

  1.  

Given the global nature and use of the WHOIS – it is important to have WHOIS data transformed into the most common languages/scripts.

IPC

Seems to suggest a very large – potentially un-attainable – need to transform into a number of different languages/scripts. Potential conflicts over ‘most common’?

  1.  

Internationally readable WHOIS would benefit the following purposes of various users:

-           Enable due diligence searches by various business internet users (such as brand holders and agents)

-           Enable to determine all domain names registered by a specific entity, for example, as a part of a legal search to identify all domain names registered to a recently merged company; or an internal search to identify domain names registered by subsidiaries .

-           Enable brand owners to contact registrant who is using a domain name that is being investigated for IP infringement (especially in international disputes)

-           Facilitate identification of and response to fraudulent use of legitimate data (e.g. address) for domain names belonging to another registrant by using Reverse Query on identity-valid data

-           Enable IP owners to conduct historical research about a domain name registration (WhoWas) during IP infringement research

Enable individual internet users, including consumers, to confirm that any given web site connected to a specific domain name is held by a real company and not a fictitious one that masks its identity by using a unique script or languages.

IPC

Searches in original language more likely to result in consistent/reliable results. For the last point, see response no. 62.

A lack of mandatory transformation does not disable (as opposed to “enable”) contactability. It only tasks the Whois lookup user with the burden of transformation.

 

  1.  

IPC agrees with the arguments listed in Initial Report supporting mandatory transformation.

IPC

No action necessary.

  1.  

IPC appreciates that concerns about mandatory transformation are related to costs but they believe that there are ways to provide solutions without increasing costs for registrants and/or end users.

IPC

The costs are likely to be high if accurate and consistent data are required. Such data are unlikely to be provided by free transformation tools or voluntary services involving many people’s different transformations.

Burden involving issues of compliance and liability are also relevant here, not just costs.

Increasing costs on contracted parties (i.e. not only registrants and end users) is also an issue. This will likely also be reflected in the costs burdened on registrants, and create other problems on start-up registrars in developing nations.

  1.  

One solution could be for ICANN to designate each country’s GAC to coordinate locally to standardize the conversion from local language to English for each country.

IPC

The GAC (or another central body) is encouraged to coordinate voluntary conversion. However, it is beyond the scope of this WG to recommend bindingly that the GAC or another organization perform such a task mandatorily.

  1.  

Another solution could be to require:

-           WHOIS information to be in the language of the registrar and

Mandatory transformation if it is not in Latin characters or one of the six UN languages.

IPC

See response no.22.

  1.  

Another options (based on EWG) is to require the script used for registration data to either be that of the TLD itself or else US-ASCII – this approach would reduce (though not eliminate) the need for translation or transliteration, as all pertinent data would already be in US-ASCII – expect that of IDN gTLDs.

IPC

See response no.22.

  1.  

IPC points out that the Initial Report makes no reference to the fact that current ICANN stance that ‘Registries and Registrars are encouraged to only use US-ASCII encoding and character repertoire for WHOIS port 43 output’.

IPC

This should be addressed in the Final Report.

 

  1.  

ICANN issued an advisory stating that WHOIS must be in ASCII (September 2014) – how did the WG consider this statement and if not, why not?

IPC

This was addressed by the WG in its meetings and should be mentioned in the Final Report.

 

  1.  

Without mandatory transformation, bad actors will flight to least translatable languages.

BC

Verification needs to occur regardless of script used in registering contact information.

 

  1.  

Absent a requirement some would choose not to voluntarily provide data in the globally accessible format, given those seeking to hide their identity the opportunity to exploit the system.

BC

See response no.6. ‘Globally accessible format’ depends on where you are based and what your script/language knowledge is. Machine readability is important in this context.

  1.  

Transformation and validation of contact information should be taken up through collaborative efforts of Registrars and the larger ICANN community . In order to minimize costs, such transformation should be done using a combination of automated tools, crowd-sourced community efforts where possible, and encouraging Registrants to enhance their own credibility by providing information in English as well.

ALAC

See response no. 72.

  1.  

The detriments listed in the Initial Report – especially potential additional burdens on underserved regions – far outweigh any potential benefits.

dotShabaka (Registry Operator)

Most WG members agree.

 

  1.  

How does the work of this WG fit into the wider efforts related to WHOIS.

dotShabaka (Registry Operator)

This needs to be added in Final Report.

 

  1.  

dotShabaka (Registry Operator) aims to bring an end-to-end Arabic experience to the domain name space – thus is would be very disappointing if WHOIS remains the only component of the domain name registration process that continues to require knowledge of English/ASCII.

dotShabaka (Registry Operator)

Most WG members agree.

 

  1.  

With 380m Arabic speakers it is unacceptable that registrants from ‘non-ASCII’ regions are mandated to transform their contact information – it would also pose an entry barrier to non-English speakers.

dotShabaka (Registry Operator)

Most WG members agree.

 

  1.  

Strongly supports the arguments put forward in favour of mandatory transformation in the Initial Report.

FICPI

No action necessary.

  1.  

While arguments supporting mandatory transformation are based on legal and ‘easy-to-search-for’ arguments, the arguments opposing only focus on costs and the difficulty with regard to the large number of users with contact information in non-ASCII scripts

FICPI

This comment is discussed on p.72 of the current issue of the Final Report. Feasibility and consistency are also important issues.

 

  1.  

The increasing internationalization of the Internet, beside creating new business opportunities for domain name holders, induces responsibilities for registrants, registries and registrars to maintain reliable and internationally readable WHOIS information.

FICPI

Original data are reliable. As long as they are machine-readable search and other functions may be performed.

 

  1.  

Registration of domain names should be provided in different scripts and languages.

NCSG

Most WG members agree.

 

  1.  

NCSG does not believe that transformation is desirable nor truly feasible.

NCSG

Most WG members agree.

 

  1.  

Requiring domain name holders not proficient in English/ASCII to submit data in a script they are not familiar with could potentially lead to contractual breaches beyond registrants’ control.

NCSG

Most WG members agree.

 

  1.  

Cost of transformation is potentially hugely disproportionate to the need for providing mandatory transformation.

NCSG

Most WG members agree.

 

  1.  

Mandatory transformation would see a shift in costs away from those requiring it [transformation] to those who do not [registrars/registrants] – with potential negative impact on underserved regions.

NCSG

Most WG members agree. It is up to the provider of the data to make sure that they are understandable, but comprehensibility should not be equated with ASCII.

  1.  

Registrars in under-served regions would suffer a far greater cost than those operating in regions with Latin-based scripts / registrants familiar with Latin script – again disadvantage for regions currently underserved by ICANN/DNS industry.

NCSG

Most WG members agree. The Working Group noted that ICANN has a responsibility to support these regions.

 

  1.  

Registrar are potentially unable to validate information data.

NCSG

Most WG members agree.

  1.  

Searching in the original script will be far more reliable than searching in transformed data – since consistency will almost be impossible to achieve.

NCSG

Most WG members agree.

 

 

 


[1] This Final Report will be translated into all official UN languages. Please note that only the original English version is authoritative.

[2] Sarmad Hussain participated in the preparation of this report as a Working Group member prior to assuming his current position as IDN Program Senior Manager at ICANN.

[4] ‘Transformed’ is used throughout this report to mean ‘translated and/or transliterated’; similarly ‘transformation’ means ‘translation and/or transliteration’.

[5] The AGB defines "searchable" on p.113:

A Searchable Whois service: Whois service includes web-based search capabilities by domain name, registrant name, postal address, contact names, registrar IDs, and Internet Protocol addresses without arbitrary limit. Boolean search capabilities may be offered. The service shall include appropriate precautions to avoid abuse of this feature (e.g., limiting access to legitimate authorized users), and the application demonstrates compliance with any applicable privacy laws or policies.

[6] However, it should be noted that transformation tools may not exist for such languages and so transformation would need to be manual until they did. It would be difficult to limit languages to e.g. only the UN ones or some other subset.

[7] “Accuracy” as used in the "Study to Evaluate Available Solutions for the Submission and Display of Internationalized Contact Data" June 2, 2014:

“There are at least three kinds of use the transformed contact data in the DNRD may have in another language or script (based on the level of accuracy of the transformation):

1. Requiring accurate transformation (e.g. valid in a court of law, matching information in a passport, matching information in legal incorporation, etc.)

2. Requiring consistent transformation (allowing use of such information to match other information provided in another context, e.g. to match address information of a registrant on a Google map, etc.)

3. Requiring ad hoc transformation (allowing informal or casual version of the information in another language to provide more general accessibility)”

Both accuracy and consistency would suffer if a large number of actors, for example, registrants, were transforming contact information.

[8] See: Study to evaluate available solutions for the submission and display of internationalized contact data for further information: https://www.icann.org/en/system/files/files/transform-dnrd-02jun14-en.pdf

[9] Transformation” on its own is used to refer to contact information, not fields, in this report. A future system could provide field names in, for example, the six UN languages and a consistent central depository of field names in additional languages for those registrars et al. that require them for display for various markets.

[10] Manual referring to transformation by a human as opposed to a machine transformation (such as Bing, Google Translate or other services).

[11] e.g. Chinese and Japanese

[12] e.g. Arabic and Hebrew

[13] e.g. Hindi and other Indian scripts

[14] e.g. Cyrillic and Greek

[16] Within the EU, Greece and Bulgaria use Greek and Cyrillic scripts respectively.

[17] The Working Group also received a contribution from the International Federation of Intellectual Property Lawyers (FICPI). However, as this first call for community feedback was not a public comment but rather an outreach to SO/ACs and SG/C, the contribution was acknowledged but not given the same weight as other submissions. The Working Group encouraged FICPI to contribute to the public comment period and they did indeed make a contribution.

[18] Se e ICA N N Boar d Resolutions , 2 6 Jun e 2009 , D ispla y an d U sag e o f Internationalize d Registratio n D ata ”: http:// www .icann . org/en/ m inutes/reso l utions - 26jun09.ht m #6

[19] Se e Interi m Repor t o f th e Internationalize d Registratio n D at a W orkin g G rou p at : http://gnso.icann.org/ i ssues/ i rd/ i r d - w g - f i nal - report - 15nov10 en.pdf .

[20] Se e D raf t F i na l Repor t o f th e Internationalize d Registratio n D at a W orkin g G rou p at :   http://gnso.icann.org/issues/ird/ird-draft-final-report-03oct11-en.pdf .

[21] Se e F i na l Repor t o f th e Internationalize d Registratio n Dat a W orkin g G rou p at : h ttp://gnso . icann . org/en/issues/ird/fina l- report‐ird - w g - 07 m ay12 - en.pdf .

[23] https://www.icann.org/groups/ssac/documents/sac-054-en

[25] Se e SAC051 : SSA C Repor t o n WHO I S Ter m inolog y an d Structur e at http:// www .icann . org/en/groups/ssac/docu m ents/sac 051 - en.pdf .

[26] Se e Anne x A : D ifferen t M odel s Propose d i n th e I n ternationalize d Registratio n Dat a W orkin g G rou p Fina l Report

[29] Se e SAC055 : Blin d M e n an d a n Elephan t (SSA C Co mm en t o n th e WHO I S Polic y Revie w Tea m F i na l Report ) a t http:// www .icann.org/en/groups/ssac/docu m ents/sac‐055‐en.pdf .

[31] Se e th e Actio n Pla n t o Addres s WHO I S Polic y Revie w Tea m Repor t Reco mm endation s at : http:// www .icann . org/en/groups/board/docu m ents/briefing‐ m aterials‐1 - 08nov12 - en.pdf .

[32] See the EWG homepage for all information, including membership, Initial Report, Status Report, and Final Report: https://community.icann.org/x/VQZlAg .

[33] RySG supports all comments submitted by the RrSG
https://community.icann.org/pages/worddav/preview.action?fileName=Final+Report+T%26T.docx&pageId=53779599
community.icann.org
crawl=CC-MAIN-2020-10
988904
application/http; msgtype=response
sha1:DWOXOQXIYRZGAJSRKAJY3IDNHYNKZOTR
<urn:uuid:fb23d889-e2c5-4554-859b-97574ccdc09d>
2020-02-28T12:08:50Z
192.0.32.27
text/html
sha1:LCSQNZU6OX7YA3MASMJLXVBKFJ4CRIHM
<urn:uuid:4c84605b-64d1-4308-a925-84886832008d>
https://community.icann.org/pages/worddav/preview.action?fileName=Final+Report+T%26T.docx&pageId=53779599
response
<urn:uuid:6eb48908-57a4-4c13-ac6d-1b5f2be84a84>
isPartOf: CC-MAIN-2020-10
publisher: Common Crawl
description: Wide crawl of the web for February 2020
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-243.ec2.internal
software: Apache Nutch 1.16 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/