At-Large Workspace: Recommendations for Managing IDN Variant Top-Level Domains
AttachmentsPublic Comment Close | Statement | Status | Assignee(s) | Call for | Call for | Vote Open | Vote Close | Date of Submission | Staff Contact and Email | Statement Number |
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
Hide the information below, please click here
FINAL VERSION SUBMITTED (IF RATIFIED)
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.
DRAFT SUBMITTED FOR DISCUSSION
The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).
Comments
So the issue would also be what is the difference : YrjöLäns or YrjoLans. In essence it would be good to have the proper language used but also creates an issue for users. But if we are to proceed it would be to ensure we train people to understand the changes. Meaning we need to go on a sensitisation work to ensure people start understanding the new changes. It is a good thing for the original use but may not be an easy take for others.
Thanks for the comments Kris. Agree on both points.
Thanks for the draft and I am support for main discussion points. Under questions, Additional Recommendations R10. In my view IDN Variant TLDs doesn't require special treatment from other TLDs. The original statement more make sense for me.
"Unless adjusted due to recommendation 9 above or other reasons identified and agreed by the community , because each IDN variant TLD is also
another TLD, all existing TLD policies and procedures for allocation and delegation remain applicable for IDN variant TLDs as well. "
Thanks for your comemnt, Eranga.
The reason why the draft proposes special treatment for IDN top level domains is because it is possible that many individuals, communities and not-for-profits that may want use IDN TLDs may not have access to finance nor to trained personnel. Applicant support is of course part of a different PDP, and is mentioned here in passing.
Please let us know if there are any specific reasons why you feel financial or non-financial support is not required for IDN TLDs.
Thanks for clarification. I do agree. May be a good idea to elaborate R10 little more with fact present above (ex: lack of trained personnel).
I fully support the core discussion points raised. The stability and a confusion free IDN is very important. The core examples signify the real potential issues. There is a need to ensure this stability. If we don't find a stable way of variant it wold definitely be an issue. Further to the quebec example we are coming close to the dummies email issue. Those with no internet understanding of domain names always say is your email address with a capital alphabet or small caps.
The IDN variants should not be causing more issues to that stability and principle. If we come up with an unrealisable variant then people could also have issues potentially with email addresses or domains. We may also be facing strict issues such as this example as well: kris.seeburn@Domain.com vs kris.seeburn@domain.com or even Kris.Seeburn@domain.com / Kris.Seeburn@Domain.com there are some variants that we need not confuse or play too much with. The DNS as well may create more confusion / stability/ reliability as well. So we may start having spanish / portugueese words as well as japanese words as we go. They may definitely help in language terms but close words may definitely be an issue.
It definitely creates more opportunities but we may definitely need to ensure some level of standardisation. Perhaps we may need to adopt standards such as relational databases do.
But overall yes we need to ensure how we move along those lines.