Ideas for engagement with stakeholders in Germany
Hello everyone, I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement. *Special characters:* Eszett (ß) and Umlaut (ü) have fallback options by default: * Eszett becomes "ss". * Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. * Umlaut characters (ä, ö, ü) become "ae", "oe", "ue". *gTLDs* * Fallback: the popular cityTLD for "Köln" is run under ".koeln" and ".cologne" to avoid the Umlaut. * ".berlin" is a popular gTLD and is in active use for varied purposes, including local businesses. * Other relevant gTLDs: ".hamburg", ".bayern", ".ruhr", ".nrw" and ".saarland". Hopefully this can help us engage better. Safe journeys to all of those traveling to the IGF! Regards, -- Mark W. Datysgeld from Governance Primer [www.markwd.website] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES)
On 24 Nov 2019, at 00:22, Mark W. Datysgeld <mark@governanceprimer.com> wrote:
Hello everyone,
I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement.
Special characters: Eszett (ß) and Umlaut (ü) have fallback options by default:
Eszett becomes "ss". Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. Umlaut characters (ä, ö, ü) become "ae", "oe", "ue".
Long live the Umlaut! Rubens Kühl
I see Rubens might have a vested interest in this one. :D -- Mark W. Datysgeld from Governance Primer [www.markwd.website] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES) On November 24, 2019 5:19:51 AM GMT+01:00, Rubens Kuhl <rubensk@nic.br> wrote:
On 24 Nov 2019, at 00:22, Mark W. Datysgeld <mark@governanceprimer.com> wrote:
Hello everyone,
I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement.
Special characters: Eszett (ß) and Umlaut (ü) have fallback options by default:
Eszett becomes "ss". Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. Umlaut characters (ä, ö, ü) become "ae", "oe", "ue".
Long live the Umlaut!
Rubens Kühl
Rubens, what is your opinion regarding variants policy? Should registrants be obliged to register all variants at the 2nd level to avoid confusion? From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Mark W. Datysgeld Sent: Sunday, November 24, 2019 1:13 PM To: ua-discuss@icann.org; Rubens Kuhl <rubensk@nic.br>; ua-discuss <ua-discuss@icann.org> Subject: [EXTERNAL] Re: [UA-discuss] Ideas for engagement with stakeholders in Germany I see Rubens might have a vested interest in this one. :D -- Mark W. Datysgeld from Governance Primer [www.markwd.website] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES) On November 24, 2019 5:19:51 AM GMT+01:00, Rubens Kuhl <rubensk@nic.br<mailto:rubensk@nic.br>> wrote: On 24 Nov 2019, at 00:22, Mark W. Datysgeld <mark@governanceprimer.com<mailto:mark@governanceprimer.com>> wrote: Hello everyone, I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement. Special characters: Eszett (ß) and Umlaut (ü) have fallback options by default: * Eszett becomes "ss". * Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. * Umlaut characters (ä, ö, ü) become "ae", "oe", "ue". Long live the Umlaut! Rubens Kühl
Hello Mark, the topic is quite complex one (from the operational and legal perspective), we should not invent rights not existing in the real world (and we should not forget abut rights of the Registrants). Potentially some variants of the same word might be in the hands of different rightful registrants, and who is going to decide which one wins? Sincerely Yours, Maxim Alzoba Special projects manager, International Relations Department, FAITID Current UTC offset: +3.00 (.Moscow)
On 25 Nov 2019, at 11:05, Mark Svancarek (CELA) via UA-discuss <ua-discuss@icann.org> wrote:
Rubens, what is your opinion regarding variants policy? Should registrants be obliged to register all variants at the 2nd level to avoid confusion?
From: UA-discuss <ua-discuss-bounces@icann.org <mailto:ua-discuss-bounces@icann.org>> On Behalf Of Mark W. Datysgeld Sent: Sunday, November 24, 2019 1:13 PM To: ua-discuss@icann.org <mailto:ua-discuss@icann.org>; Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>>; ua-discuss <ua-discuss@icann.org <mailto:ua-discuss@icann.org>> Subject: [EXTERNAL] Re: [UA-discuss] Ideas for engagement with stakeholders in Germany
I see Rubens might have a vested interest in this one. :D -- Mark W. Datysgeld from Governance Primer [www.markwd.website <http://www.markwd.website/>] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES)
On November 24, 2019 5:19:51 AM GMT+01:00, Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>> wrote:
On 24 Nov 2019, at 00:22, Mark W. Datysgeld <mark@governanceprimer.com <mailto:mark@governanceprimer.com>> wrote:
Hello everyone, I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement.
Special characters: Eszett (ß) and Umlaut (ü) have fallback options by default: Eszett becomes "ss". Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. Umlaut characters (ä, ö, ü) become "ae", "oe", "ue".
Long live the Umlaut!
Rubens Kühl
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On 11/25/2019 4:22 AM, Maxim Alzoba wrote:
Hello Mark,
the topic is quite complex one (from the operational and legal perspective), we should not invent rights not existing in the real world (and we should not forget abut rights of the Registrants).
Potentially some variants of the same word might be in the hands of different rightful registrants, and who is going to decide which one wins?
With variants you have the following issues: (1) if they are imposed after the fact, you'll need to have some policy for grandfathering That's why, for the root zone, we categorically ruled out, for example, any variants (even implied by transitivity) between ASCII code points. And we test all proposed LGRs against delegated TLDs. (2) if they are allocatable, you have issues with multiplicity. A longer label may have several code points with variants, which naively would lead to huge multiplicities. That's why, in the root zone, we go to some lengths defining allocatable (code point) variants so that allocatable variant labels are limited to a very small number; usually by requiring all variants to be of the same type (e.g. all traditional/all simplified for Chinese). (3) if they are allocatable, you have issues with predictability. Not all applicants want all possible allocatable variants actually delegated. That's why, in the root zone, we've tried to limit allocatable variants to contexts where both users and applicants clearly understand their scope (e.g. Chinese simplified and traditional). (4) if they are blocked variants, they need to be full equivalents, not merely similar Otherwise, transitivity will kill you. Any variant of a code point needs to also be a variant of all the other variants for that code point (transitivity). If variants are merely similar, you quickly get "variants" between dissimilar code points. That's why, in the root zone, we are limiting variants to cases where code points are accepted as fully equivalent. (5) if you base variant definition on a limited sample of languages, you'll be surprised What works in a limited context may create issues if you plan on allowing labels in other scripts or other languages in the same zone. That's why, in the root zone, we investigated over 200 writing systems for the Latin script, for example. (6) if you don't define certain allocatable variants, you'll run into usability issues Typically the case where users of different regions share a script (and/or language) but regional conventions conflict. For example the case in Arabic, where local keyboards may have a look-alike character, so if you can't offer both versions of your label, you cannot reach some communities. That's why, in the root zone, we have allocatable variant definitions for Arabic, Chinese, and for the case of sharp-s/ss, for example. (7) if you don't have blocked variants, you can't take obvious issues "off the table" There are a surprising number of letters (or for the second level, also digits) that have exact (intentional) look-alikes in Unicode. (They are considered different for other reasons than appearance, for example they belong to different scripts, have different case pairings, etc). These cases are quite obvious equivalences and can, and should be taken off the table, up front and mechanically. That's why, in the root zone, we ensure that such cases become blocked variants. Now, why were we discussing this again? A./
Sincerely Yours,
Maxim Alzoba Special projects manager, International Relations Department, FAITID
Current UTC offset: +3.00 (.Moscow)
On 25 Nov 2019, at 11:05, Mark Svancarek (CELA) via UA-discuss <ua-discuss@icann.org <mailto:ua-discuss@icann.org>> wrote:
Rubens, what is your opinion regarding variants policy? Should registrants be obliged to register all variants at the 2^nd level to avoid confusion? *From:*UA-discuss <ua-discuss-bounces@icann.org <mailto:ua-discuss-bounces@icann.org>>*On Behalf Of*Mark W. Datysgeld *Sent:*Sunday, November 24, 2019 1:13 PM *To:*ua-discuss@icann.org <mailto:ua-discuss@icann.org>; Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>>; ua-discuss <ua-discuss@icann.org <mailto:ua-discuss@icann.org>> *Subject:*[EXTERNAL] Re: [UA-discuss] Ideas for engagement with stakeholders in Germany
I see Rubens might have a vested interest in this one. :D -- Mark W. Datysgeld from Governance Primer [www.markwd.website <http://www.markwd.website/>] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES)
On November 24, 2019 5:19:51 AM GMT+01:00, Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>> wrote:
On 24 Nov 2019, at 00:22, Mark W. Datysgeld <mark@governanceprimer.com <mailto:mark@governanceprimer.com>> wrote: Hello everyone, I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement. *Special characters:*Eszett (ß) and Umlaut (ü) have fallback options by default:
* Eszett becomes "ss". * Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. * Umlaut characters (ä, ö, ü) become "ae", "oe", "ue".
Long live the Umlaut! Rubens Kühl
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
This is an interesting message that would be useful to have on the web. Wikipedia? From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Asmus Freytag Sent: Monday, November 25, 2019 11:03 AM To: ua-discuss@icann.org Subject: Re: [UA-discuss] [EXTERNAL] Re: Ideas for engagement with stakeholders in Germany On 11/25/2019 4:22 AM, Maxim Alzoba wrote: Hello Mark, the topic is quite complex one (from the operational and legal perspective), we should not invent rights not existing in the real world (and we should not forget abut rights of the Registrants). Potentially some variants of the same word might be in the hands of different rightful registrants, and who is going to decide which one wins? With variants you have the following issues: (1) if they are imposed after the fact, you'll need to have some policy for grandfathering That's why, for the root zone, we categorically ruled out, for example, any variants (even implied by transitivity) between ASCII code points. And we test all proposed LGRs against delegated TLDs. (2) if they are allocatable, you have issues with multiplicity. A longer label may have several code points with variants, which naively would lead to huge multiplicities. That's why, in the root zone, we go to some lengths defining allocatable (code point) variants so that allocatable variant labels are limited to a very small number; usually by requiring all variants to be of the same type (e.g. all traditional/all simplified for Chinese). (3) if they are allocatable, you have issues with predictability. Not all applicants want all possible allocatable variants actually delegated. That's why, in the root zone, we've tried to limit allocatable variants to contexts where both users and applicants clearly understand their scope (e.g. Chinese simplified and traditional). (4) if they are blocked variants, they need to be full equivalents, not merely similar Otherwise, transitivity will kill you. Any variant of a code point needs to also be a variant of all the other variants for that code point (transitivity). If variants are merely similar, you quickly get "variants" between dissimilar code points. That's why, in the root zone, we are limiting variants to cases where code points are accepted as fully equivalent. (5) if you base variant definition on a limited sample of languages, you'll be surprised What works in a limited context may create issues if you plan on allowing labels in other scripts or other languages in the same zone. That's why, in the root zone, we investigated over 200 writing systems for the Latin script, for example. (6) if you don't define certain allocatable variants, you'll run into usability issues Typically the case where users of different regions share a script (and/or language) but regional conventions conflict. For example the case in Arabic, where local keyboards may have a look-alike character, so if you can't offer both versions of your label, you cannot reach some communities. That's why, in the root zone, we have allocatable variant definitions for Arabic, Chinese, and for the case of sharp-s/ss, for example. (7) if you don't have blocked variants, you can't take obvious issues "off the table" There are a surprising number of letters (or for the second level, also digits) that have exact (intentional) look-alikes in Unicode. (They are considered different for other reasons than appearance, for example they belong to different scripts, have different case pairings, etc). These cases are quite obvious equivalences and can, and should be taken off the table, up front and mechanically. That's why, in the root zone, we ensure that such cases become blocked variants. Now, why were we discussing this again? A./ Sincerely Yours, Maxim Alzoba Special projects manager, International Relations Department, FAITID Current UTC offset: +3.00 (.Moscow) On 25 Nov 2019, at 11:05, Mark Svancarek (CELA) via UA-discuss <ua-discuss@icann.org <mailto:ua-discuss@icann.org> > wrote: Rubens, what is your opinion regarding variants policy? Should registrants be obliged to register all variants at the 2nd level to avoid confusion? From: UA-discuss < <mailto:ua-discuss-bounces@icann.org> ua-discuss-bounces@icann.org> On Behalf Of Mark W. Datysgeld Sent: Sunday, November 24, 2019 1:13 PM To: <mailto:ua-discuss@icann.org> ua-discuss@icann.org; Rubens Kuhl < <mailto:rubensk@nic.br> rubensk@nic.br>; ua-discuss < <mailto:ua-discuss@icann.org> ua-discuss@icann.org> Subject: [EXTERNAL] Re: [UA-discuss] Ideas for engagement with stakeholders in Germany I see Rubens might have a vested interest in this one. :D -- Mark W. Datysgeld from Governance Primer [ <http://www.markwd.website/> www.markwd.website] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES) On November 24, 2019 5:19:51 AM GMT+01:00, Rubens Kuhl < <mailto:rubensk@nic.br> rubensk@nic.br> wrote: On 24 Nov 2019, at 00:22, Mark W. Datysgeld < <mailto:mark@governanceprimer.com> mark@governanceprimer.com> wrote: Hello everyone, I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement. Special characters: Eszett (ß) and Umlaut (ü) have fallback options by default: * Eszett becomes "ss". * Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. * Umlaut characters (ä, ö, ü) become "ae", "oe", "ue". Long live the Umlaut! Rubens Kühl _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( <https://www.icann.org/privacy/policy> https://www.icann.org/privacy/policy) and the website Terms of Service ( <https://www.icann.org/privacy/tos> https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
I agree that this is an interesting message that would be useful to have on the web. But rather than Wikipedia as a first place to publish it, I think it's better to publish it as a white paper or blog post or something of that sort, where it will be a reliable source. Then someone can edit it into Wikipedia, citing the reliable source. And, if there is disagreement among Wikipedia editors about the contribution, the information is still available on the web. —Jim DeLaHunt On 2019-12-07 05:38, Larry Masinter wrote:
This is an interesting message that would be useful to have on the web.
Wikipedia?
*From:*UA-discuss <ua-discuss-bounces@icann.org> *On Behalf Of *Asmus Freytag *Sent:* Monday, November 25, 2019 11:03 AM *To:* ua-discuss@icann.org *Subject:* Re: [UA-discuss] [EXTERNAL] Re: Ideas for engagement with stakeholders in Germany
On 11/25/2019 4:22 AM, Maxim Alzoba wrote:
Hello Mark,
the topic is quite complex one (from the operational and legal perspective),
we should not invent rights not existing in the real world (and we should not forget abut rights of the Registrants).
Potentially some variants of the same word might be in the hands of different rightful registrants, and who is going to decide
which one wins?
With variants you have the following issues:
(1) if they are imposed after the fact, you'll need to have some policy for grandfathering
That's why, for the root zone, we categorically ruled out, for example, any variants (even implied by transitivity) between ASCII code points. And we test all proposed LGRs against delegated TLDs.
(2) if they are allocatable, you have issues with multiplicity.
A longer label may have several code points with variants, which naively would lead to huge multiplicities. That's why, in the root zone, we go to some lengths defining allocatable (code point) variants so that allocatable variant labels are limited to a very small number; usually by requiring all variants to be of the same type (e.g. all traditional/all simplified for Chinese).
(3) if they are allocatable, you have issues with predictability.
Not all applicants want all possible allocatable variants actually delegated. That's why, in the root zone, we've tried to limit allocatable variants to contexts where both users and applicants clearly understand their scope (e.g. Chinese simplified and traditional).
(4) if they are blocked variants, they need to be full equivalents, not merely similar
Otherwise, transitivity will kill you. Any variant of a code point needs to also be a variant of all the other variants for that code point (transitivity). If variants are merely similar, you quickly get "variants" between dissimilar code points. That's why, in the root zone, we are limiting variants to cases where code points are accepted as fully equivalent.
(5) if you base variant definition on a limited sample of languages, you'll be surprised
What works in a limited context may create issues if you plan on allowing labels in other scripts or other languages in the same zone. That's why, in the root zone, we investigated over 200 writing systems for the Latin script, for example.
(6) if you don't define certain allocatable variants, you'll run into usability issues
Typically the case where users of different regions share a script (and/or language) but regional conventions conflict. For example the case in Arabic, where local keyboards may have a look-alike character, so if you can't offer both versions of your label, you cannot reach some communities. That's why, in the root zone, we have allocatable variant definitions for Arabic, Chinese, and for the case of sharp-s/ss, for example.
(7) if you don't have blocked variants, you can't take obvious issues "off the table"
There are a surprising number of letters (or for the second level, also digits) that have exact (intentional) look-alikes in Unicode. (They are considered different for other reasons than appearance, for example they belong to different scripts, have different case pairings, etc). These cases are quite obvious equivalences and can, and should be taken off the table, up front and mechanically. That's why, in the root zone, we ensure that such cases become blocked variants.
Now, why were we discussing this again?
A./
Sincerely Yours,
Maxim Alzoba Special projects manager, International Relations Department, FAITID
Current UTC offset: +3.00 (.Moscow)
On 25 Nov 2019, at 11:05, Mark Svancarek (CELA) via UA-discuss <ua-discuss@icann.org <mailto:ua-discuss@icann.org>> wrote:
Rubens, what is your opinion regarding variants policy? Should registrants be obliged to register all variants at the 2^nd level to avoid confusion?
*From:*UA-discuss <ua-discuss-bounces@icann.org <mailto:ua-discuss-bounces@icann.org>>*On Behalf Of*Mark W. Datysgeld *Sent:*Sunday, November 24, 2019 1:13 PM *To:*ua-discuss@icann.org <mailto:ua-discuss@icann.org>; Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>>; ua-discuss <ua-discuss@icann.org <mailto:ua-discuss@icann.org>> *Subject:*[EXTERNAL] Re: [UA-discuss] Ideas for engagement with stakeholders in Germany
I see Rubens might have a vested interest in this one. :D -- Mark W. Datysgeld from Governance Primer [www.markwd.website <http://www.markwd.website/>] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES)
On November 24, 2019 5:19:51 AM GMT+01:00, Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>> wrote:
On 24 Nov 2019, at 00:22, Mark W. Datysgeld <mark@governanceprimer.com <mailto:mark@governanceprimer.com>> wrote:
Hello everyone,
I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement.
*Special characters:*Eszett (ß) and Umlaut (ü) have fallback options by default:
* Eszett becomes "ss". * Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. * Umlaut characters (ä, ö, ü) become "ae", "oe", "ue".
Long live the Umlaut!
Rubens Kühl
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- --Jim DeLaHunt, jdlh@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant 355-1027 Davie St, Vancouver BC V6E 4L2, Canada Canada mobile +1-604-376-8953
Mark, Since we were talking about Latin script, my opinion is that there are no variants except for ß/ss. In some cases it's just something written wrong (like pao instead of pão, which means bread in Portuguese) in order to accommodate ASCII-only systems or traditions, and in some cases two different words like pé (foot) and pê (letter P). So, what it really happens is visual similarity, and to the extent possible, policies preventing that are welcome but not mandatory, and when they exist, they might exist in a variety of scopes. For instance, in .br there is such a policy prevent both accent versions and hyphens. What I don't see a need, different from ICANN IDN Framework for gTLDs, is to control the whole lifecycle of the domain. Preventing domain creating is all that is needed IMHO. There is currently an scoping effort in both GNSO and ccNSO, and those efforts might trigger PDPs in both SOs to deal with the subject. Stay tuned... Rubens
On 25 Nov 2019, at 05:05, Mark Svancarek (CELA) <marksv@microsoft.com> wrote:
Rubens, what is your opinion regarding variants policy? Should registrants be obliged to register all variants at the 2nd level to avoid confusion?
From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Mark W. Datysgeld Sent: Sunday, November 24, 2019 1:13 PM To: ua-discuss@icann.org; Rubens Kuhl <rubensk@nic.br>; ua-discuss <ua-discuss@icann.org> Subject: [EXTERNAL] Re: [UA-discuss] Ideas for engagement with stakeholders in Germany
I see Rubens might have a vested interest in this one. :D -- Mark W. Datysgeld from Governance Primer [www.markwd.website] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES)
On November 24, 2019 5:19:51 AM GMT+01:00, Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>> wrote:
On 24 Nov 2019, at 00:22, Mark W. Datysgeld <mark@governanceprimer.com <mailto:mark@governanceprimer.com>> wrote:
Hello everyone, I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement.
Special characters: Eszett (ß) and Umlaut (ü) have fallback options by default: Eszett becomes "ss". Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. Umlaut characters (ä, ö, ü) become "ae", "oe", "ue".
Long live the Umlaut!
Rubens Kühl
Sorry, I should pay more attention before replying to email. I was thinking about variants from ascii to other (“ss” and eszett). Sorry for being random! From: Rubens Kuhl <rubensk@nic.br> Sent: Monday, November 25, 2019 3:33 PM To: Mark Svancarek (CELA) <marksv@microsoft.com> Cc: Mark W. Datysgeld <mark@governanceprimer.com>; ua-discuss@icann.org Subject: Re: [EXTERNAL] [UA-discuss] Ideas for engagement with stakeholders in Germany Mark, Since we were talking about Latin script, my opinion is that there are no variants except for ß/ss. In some cases it's just something written wrong (like pao instead of pão, which means bread in Portuguese) in order to accommodate ASCII-only systems or traditions, and in some cases two different words like pé (foot) and pê (letter P). So, what it really happens is visual similarity, and to the extent possible, policies preventing that are welcome but not mandatory, and when they exist, they might exist in a variety of scopes. For instance, in .br there is such a policy prevent both accent versions and hyphens. What I don't see a need, different from ICANN IDN Framework for gTLDs, is to control the whole lifecycle of the domain. Preventing domain creating is all that is needed IMHO. There is currently an scoping effort in both GNSO and ccNSO, and those efforts might trigger PDPs in both SOs to deal with the subject. Stay tuned... Rubens On 25 Nov 2019, at 05:05, Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> wrote: Rubens, what is your opinion regarding variants policy? Should registrants be obliged to register all variants at the 2nd level to avoid confusion? From: UA-discuss <ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org>> On Behalf Of Mark W. Datysgeld Sent: Sunday, November 24, 2019 1:13 PM To: ua-discuss@icann.org<mailto:ua-discuss@icann.org>; Rubens Kuhl <rubensk@nic.br<mailto:rubensk@nic.br>>; ua-discuss <ua-discuss@icann.org<mailto:ua-discuss@icann.org>> Subject: [EXTERNAL] Re: [UA-discuss] Ideas for engagement with stakeholders in Germany I see Rubens might have a vested interest in this one. :D -- Mark W. Datysgeld from Governance Primer [www.markwd.website<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.markwd....>] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES) On November 24, 2019 5:19:51 AM GMT+01:00, Rubens Kuhl <rubensk@nic.br<mailto:rubensk@nic.br>> wrote: On 24 Nov 2019, at 00:22, Mark W. Datysgeld <mark@governanceprimer.com<mailto:mark@governanceprimer.com>> wrote: Hello everyone, I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement. Special characters: Eszett (ß) and Umlaut (ü) have fallback options by default: * Eszett becomes "ss". * Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. * Umlaut characters (ä, ö, ü) become "ae", "oe", "ue". Long live the Umlaut! Rubens Kühl
Dear Mark, This brings another topic to my mind. Just for curiosity, do you know what is the situation in the code tables for the characters that in some languages that use the “latin” script are the combination of two separate characters - a bit like the "scharfes S” that you talk about? I am thinking, for instance, about the “rr” or “ll” (that in spanish are different from two consecutive “l” or “r”), or the “ij” (that in dutch is not an “i” followed by a “j”, although it is written that way). Cheers, Roberto On 24.11.2019, at 04:22, Mark W. Datysgeld <mark@governanceprimer.com<mailto:mark@governanceprimer.com>> wrote: Hello everyone, I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement. Special characters: Eszett (ß) and Umlaut (ü) have fallback options by default: * Eszett becomes "ss". * Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. * Umlaut characters (ä, ö, ü) become "ae", "oe", "ue". gTLDs * Fallback: the popular cityTLD for "Köln" is run under ".koeln" and ".cologne" to avoid the Umlaut. * ".berlin" is a popular gTLD and is in active use for varied purposes, including local businesses. * Other relevant gTLDs: ".hamburg", ".bayern", ".ruhr", ".nrw" and ".saarland". Hopefully this can help us engage better. Safe journeys to all of those traveling to the IGF! Regards, -- Mark W. Datysgeld from Governance Primer [www.markwd.website<http://www.markwd.website/>] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES) _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
What is the context of this discussion of Latin characters? Is it to discuss recommended practice or to describe actual practice? Actual practice is not easy to determine, because even where Idntables were filed by registries (in the IANA repository), they don't often provide the complete story. (Other policies apply as well). Nevertheless, at least some registries apply minimal restrictions. For the Root Zone, the Latin Generation Panel is working on a proposed set of Label Generation Rules. It's key features are: (1) precomposed letters are limited to those in use in everyday modern orthographies (2) combining marks are limited to the actual combinations used in the same orthographies (3) because NFC, there's no duplication between (1) and (2). (4) the sharp s is allowed, but made a variant of "ss". Due to the fact that Swiss, when writing German will only use "ss"; the variant is allocatable if "ß" is registered, allowing one entity to control both variants. That takes care of issues around fall-back use. (5) i with and without dot may be defined as variants (6) many cross-script variants are defined to safely allow Greek, Cyrillic and Armenian labels to coexist with Latin ones in the Root. (7) the Catalan middle dot is not allowed. (8) Ducth ij and any other cases of single code points for digraph letters are not allowed. Something like that approach could serve as a basis for "best practice" prescriptions for other zones, if that's something that is relevant in the UA context. However, the UASG would not seem the appropriate venue to duplicate the full analysis of the Latin script undertaken by the Latin Generation Panel. That panel spent several years on this project and analyzed over 200 orthographies. A./ PS: a public version of the proposed Latin Root Zone LGR is expected early next year for those of you who would like to review that document and its conclusions. On 11/24/2019 10:19 AM, Roberto Gaetano wrote:
Dear Mark, This brings another topic to my mind. Just for curiosity, do you know what is the situation in the code tables for the characters that in some languages that use the “latin” script are the combination of two separate characters - a bit like the "scharfes S” that you talk about? I am thinking, for instance, about the “rr” or “ll” (that in spanish are different from two consecutive “l” or “r”), or the “ij” (that in dutch is not an “i” followed by a “j”, although it is written that way). Cheers, Roberto
On 24.11.2019, at 04:22, Mark W. Datysgeld <mark@governanceprimer.com <mailto:mark@governanceprimer.com>> wrote:
Hello everyone,
I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement.
*Special characters:* Eszett (ß) and Umlaut (ü) have fallback options by default:
* Eszett becomes "ss". * Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. * Umlaut characters (ä, ö, ü) become "ae", "oe", "ue".
*gTLDs*
* Fallback: the popular cityTLD for "Köln" is run under ".koeln" and ".cologne" to avoid the Umlaut. * ".berlin" is a popular gTLD and is in active use for varied purposes, including local businesses. * Other relevant gTLDs: ".hamburg", ".bayern", ".ruhr", ".nrw" and ".saarland".
Hopefully this can help us engage better. Safe journeys to all of those traveling to the IGF!
Regards,
-- Mark W. Datysgeld from Governance Primer [www.markwd.website] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES)
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Asmus Just to make sure that I am not misunderstood, my intention was not to raise issues for UASG, but to ask some questions for my own education. I understand that I can find more information in the work of the Latin Generation Panel - can you please point me to the place where I can connect with that? Thanks, Roberto On 24.11.2019, at 21:52, Asmus Freytag <asmusf@ix.netcom.com<mailto:asmusf@ix.netcom.com>> wrote: What is the context of this discussion of Latin characters? Is it to discuss recommended practice or to describe actual practice? Actual practice is not easy to determine, because even where Idntables were filed by registries (in the IANA repository), they don't often provide the complete story. (Other policies apply as well). Nevertheless, at least some registries apply minimal restrictions. For the Root Zone, the Latin Generation Panel is working on a proposed set of Label Generation Rules. It's key features are: (1) precomposed letters are limited to those in use in everyday modern orthographies (2) combining marks are limited to the actual combinations used in the same orthographies (3) because NFC, there's no duplication between (1) and (2). (4) the sharp s is allowed, but made a variant of "ss". Due to the fact that Swiss, when writing German will only use "ss"; the variant is allocatable if "ß" is registered, allowing one entity to control both variants. That takes care of issues around fall-back use. (5) i with and without dot may be defined as variants (6) many cross-script variants are defined to safely allow Greek, Cyrillic and Armenian labels to coexist with Latin ones in the Root. (7) the Catalan middle dot is not allowed. (8) Ducth ij and any other cases of single code points for digraph letters are not allowed. Something like that approach could serve as a basis for "best practice" prescriptions for other zones, if that's something that is relevant in the UA context. However, the UASG would not seem the appropriate venue to duplicate the full analysis of the Latin script undertaken by the Latin Generation Panel. That panel spent several years on this project and analyzed over 200 orthographies. A./ PS: a public version of the proposed Latin Root Zone LGR is expected early next year for those of you who would like to review that document and its conclusions. On 11/24/2019 10:19 AM, Roberto Gaetano wrote: Dear Mark, This brings another topic to my mind. Just for curiosity, do you know what is the situation in the code tables for the characters that in some languages that use the “latin” script are the combination of two separate characters - a bit like the "scharfes S” that you talk about? I am thinking, for instance, about the “rr” or “ll” (that in spanish are different from two consecutive “l” or “r”), or the “ij” (that in dutch is not an “i” followed by a “j”, although it is written that way). Cheers, Roberto On 24.11.2019, at 04:22, Mark W. Datysgeld <mark@governanceprimer.com<mailto:mark@governanceprimer.com>> wrote: Hello everyone, I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement. Special characters: Eszett (ß) and Umlaut (ü) have fallback options by default: * Eszett becomes "ss". * Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. * Umlaut characters (ä, ö, ü) become "ae", "oe", "ue". gTLDs * Fallback: the popular cityTLD for "Köln" is run under ".koeln" and ".cologne" to avoid the Umlaut. * ".berlin" is a popular gTLD and is in active use for varied purposes, including local businesses. * Other relevant gTLDs: ".hamburg", ".bayern", ".ruhr", ".nrw" and ".saarland". Hopefully this can help us engage better. Safe journeys to all of those traveling to the IGF! Regards, -- Mark W. Datysgeld from Governance Primer [www.markwd.website<http://www.markwd.website/>] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES) _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On 11/24/2019 1:27 PM, Roberto Gaetano wrote:
Hi Asmus Just to make sure that I am not misunderstood, my intention was not to raise issues for UASG, but to ask some questions for my own education. I understand that I can find more information in the work of the Latin Generation Panel - can you please point me to the place where I can connect with that?
Roberto, that's a useful clarification. If you are interested in the work of the Generation Panels, it's part of the Root Zone LGR project which is maintained on the ICANN website as part of the IDN project. The place to start is https://icann.org/idn And then look around for the root zone LGR project, generation panels etc. As I mentioned, the current status is a work in progress (it was discussed at the ICANN66 meeting); the first public draft is expected next year. In the meantime, anyone is, of course free to contact the generation panel or to offer to contribute. A./
Thanks, Roberto
On 24.11.2019, at 21:52, Asmus Freytag <asmusf@ix.netcom.com <mailto:asmusf@ix.netcom.com>> wrote:
What is the context of this discussion of Latin characters?
Is it to discuss recommended practice or to describe actual practice?
Actual practice is not easy to determine, because even where Idntables were filed by registries (in the IANA repository), they don't often provide the complete story. (Other policies apply as well). Nevertheless, at least some registries apply minimal restrictions.
For the Root Zone, the Latin Generation Panel is working on a proposed set of Label Generation Rules. It's key features are:
(1) precomposed letters are limited to those in use in everyday modern orthographies (2) combining marks are limited to the actual combinations used in the same orthographies (3) because NFC, there's no duplication between (1) and (2).
(4) the sharp s is allowed, but made a variant of "ss". Due to the fact that Swiss, when writing German will only use "ss"; the variant is allocatable if "ß" is registered, allowing one entity to control both variants. That takes care of issues around fall-back use.
(5) i with and without dot may be defined as variants
(6) many cross-script variants are defined to safely allow Greek, Cyrillic and Armenian labels to coexist with Latin ones in the Root.
(7) the Catalan middle dot is not allowed.
(8) Ducth ij and any other cases of single code points for digraph letters are not allowed.
Something like that approach could serve as a basis for "best practice" prescriptions for other zones, if that's something that is relevant in the UA context.
However, the UASG would not seem the appropriate venue to duplicate the full analysis of the Latin script undertaken by the Latin Generation Panel. That panel spent several years on this project and analyzed over 200 orthographies.
A./
PS: a public version of the proposed Latin Root Zone LGR is expected early next year for those of you who would like to review that document and its conclusions.
On 11/24/2019 10:19 AM, Roberto Gaetano wrote:
Dear Mark, This brings another topic to my mind. Just for curiosity, do you know what is the situation in the code tables for the characters that in some languages that use the “latin” script are the combination of two separate characters - a bit like the "scharfes S” that you talk about? I am thinking, for instance, about the “rr” or “ll” (that in spanish are different from two consecutive “l” or “r”), or the “ij” (that in dutch is not an “i” followed by a “j”, although it is written that way). Cheers, Roberto
On 24.11.2019, at 04:22, Mark W. Datysgeld <mark@governanceprimer.com <mailto:mark@governanceprimer.com>> wrote:
Hello everyone,
I exchanged a few messages with Lars earlier this year, and would like to present below some points he raised that should be useful both for the IGF next week and looking towards ICANN meeting C next year, being tailored towards German stakeholders. In my view, we can aim to always try gathering such regional insights moving forward to optimize our engagement.
*Special characters:* Eszett (ß) and Umlaut (ü) have fallback options by default:
* Eszett becomes "ss". * Capital Eszett (ẞ) has only recently been introduced officially to the language, meaning that anything in capital letters used to be written using "SS" even on the press. * Umlaut characters (ä, ö, ü) become "ae", "oe", "ue".
*gTLDs*
* Fallback: the popular cityTLD for "Köln" is run under ".koeln" and ".cologne" to avoid the Umlaut. * ".berlin" is a popular gTLD and is in active use for varied purposes, including local businesses. * Other relevant gTLDs: ".hamburg", ".bayern", ".ruhr", ".nrw" and ".saarland".
Hopefully this can help us engage better. Safe journeys to all of those traveling to the IGF!
Regards,
-- Mark W. Datysgeld from Governance Primer [www.markwd.website] In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES)
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (9)
-
Asmus Freytag -
Asmus Freytag (c)
-
Jim DeLaHunt -
Larry Masinter -
Mark Svancarek (CELA) -
Mark W. Datysgeld -
Maxim Alzoba -
Roberto Gaetano -
Rubens Kuhl