Page History
...
There’s an impression that the T/T PDP did not create ANY new obligations on contracted parties. This is only partially accurate. It does create new obligations, but only in the specific circumstances mentioned above.
Answer (Roger Carney, GoDaddy and former T/T PDP WG member): I do not believe Recommendation 2 states, suggests or implies “…that all registration data must be tagged with a language/script tag following the adoption of the policy…”. During discussions in the PDP I purposefully avoided (as much as I could) using the term “tagging (tag/tagged)”. This term seems to have originated from the IRD WG and I did not think it was useful/appropriate to bring up implementation proposals in the PDP. I think Question 1 as written above is interpreting the text/meaning of Recommendation 2 somewhat different than I did when agreeing with the Recommendation in the PDP. The text in the final report is “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.” This recommendation does not require or even suggest/recommend that any additional data fields be created. We also need to remember that RDAP does not store nor does it display data, as such I don’t believe this recommendation intended RDAP to be considered as a replacement WHOIS system in this context.
Answer (w/ name and affiliation):
...
Question 1a: The IRD WG—a Non-Consensus Policy Working Group—recommended that “Unless explicitly stated otherwise, all data elements should be tagged with the language(s) and script(s) in use, and this information should always be available with the data element”. Does use of “should” instead of “must” in this recommendation indicate that tagging data elements with the language(s) and script(s) in use is not an absolute requirement? Under what circumstances did the IRD WG envision that it may be necessary or desirable to explicitly state otherwise?
Answer (Roger Carney, GoDaddy and former T/T PDP WG member): Judging intent of “should”/”must” is a bit tough for me as I was just a loose observer of this IRD WG. But as this language is from a non-consensus policy working group that the T/T PDP WG reviewed and considered (as asked to do so by the GNSO and Board), it’s exact form and probably intent was not carried on by the T/T PDP WG. In comparing T/T Recommendation 2 to this IRD recommendation you can see that they are close in meaning but I think purposefully not exact (i.e. “tagging” and “always be available” were not carried through).
Answer (w/ name and affiliation):
...
Answer (Lars Hoffman, ICANN org, T/T PDP observer): In my recollection, the PDP WG, aware of the IRD formulation, did not want to contradict or change the recommendation of IRD. Their intention, to the best of my memory, was to have all languages ‘identified’ – there is no two-letter ISO standard for ‘suhali’, ‘urdu’, or ‘arabic’ – so the language field should be tagged, in latin script, by the registrar identifying the language. The idea, if I remember correctly, was that registrants would self-identify their language through a drop-down menu, if they cannot do so (because they can’t identify their language in latin script), the registrar would need to identify the script for the RDS record.
Answer (Roger Carney, GoDaddy and former T/T PDP WG member): I don’t recall if there was specific recognition of “conditionality” of this recommendation in the PDP. As mentioned above and during several prior meetings, I considered all of the IRD recommendations “conditional.” The analysis and recommendations from the IRD were very useful but I (and I think many members of the T/T PDP) used it as input not facts or requirements.
Answer (w/ name and affiliation):
Answer (w/ name and affiliation):
...
Answer (Lars Hoffman, ICANN org, T/T PDP observer): To the best of my recollection, the reason was that Arabic is a language and a script. My recollection was that, principally, it should be the language that is tagged. Because the script info might not be sufficient if you do not speak the language. – I believe that was mainly a concern of the IPC. Again, to the best of my memory.
Answer (Roger Carney, GoDaddy and former T/T PDP WG member): I think the intent was “whatever is needed” for identification.
Answer (w/ name and affiliation):
...
Answer (Lars Hoffman, ICANN org, T/T PDP observer): To the best of my memory, the PDP WG wanted to allow for non-latin scripts to be useable in the WHOIS system as soon as possible. RDAP seemed the most logical vehicle for that. However, the PDP WG did not believe they had the authority in their scope to recommend the adoption of RDAP. So, the consensus was: if RDAP is implemented, that is great and we can proceed with our recommendations. If RDAP does not get implemented then we need to come up with another system that must be able to handle all scripts.
Answer (Roger Carney, GoDaddy and former T/T PDP WG member): When the PDP was working on this language, I recognized that the current WHOIS system, with some modifications, including the RDAP component, may be able to support these recommendations, but not seeing how or when these modifications would be introduced I assumed these recommendations would be used as input into the Next Generation RDS PDP. As everyone has heard me say multiple times I never considered RDAP as a WHOIS replacement system and the text in multiple recommendations does confirm this (i.e. RDAP does not collect, store or display data, it is a communications protocol). More generally and overriding, my intent in the PDP was that these recommendations were holistic in nature. All of these recommendations would be considered together and were only applicable if a registry/registrar chose to translate/transliterate and that there was a system in place for collecting, storing, retrieving and displaying of originally collected data and applicable transformations of that data.
Answer (w/ name and affiliation):
...
In practical terms, the PDP WG thought that if US-based registrar X wants to sell domain names in Sri Lanka, it can do so offering only Latin-based registration. However, the PDP WG thought, that US-based registrar Y might then seize on that opportunity and offer registration in Sinhalese and Tamil (and hire people that can verify registration data in those languages) – and thus the demand for registrar Y’s services would grow much more quickly than for registrar X; leading, over time, to a situation where the market, rather than ICANN policy, determines which scripts are offered to registrants to use to register their domain names.
Answer (Roger Carney, GoDaddy and former T/T PDP WG member): First, I think we should (re)educate contracted parties that US-ASCII is not the only output allowed. The Advisory from 27APR2015 clearly recommends use of US-ASCII but does allow non-US-ASCII if it is encoded in UTF-8 (section I.3). With this knowledge and as I stated above I think that these recommendations should be treated holistically.
Answer (w/ name and affiliation):
...
