[UA-discuss] [EXTERNAL] Re: Ideas for engagement with stakeholders in Germany
Jim DeLaHunt
list+uasg at jdlh.com
Sat Dec 7 12:31:14 UTC 2019
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 at icann.org> *On Behalf Of *Asmus
> Freytag
> *Sent:* Monday, November 25, 2019 11:03 AM
> *To:* ua-discuss at 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 at icann.org <mailto:ua-discuss at 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 at icann.org
> <mailto:ua-discuss-bounces at icann.org>>*On Behalf Of*Mark W.
> Datysgeld
> *Sent:*Sunday, November 24, 2019 1:13 PM
> *To:*ua-discuss at icann.org <mailto:ua-discuss at icann.org>;
> Rubens Kuhl <rubensk at nic.br <mailto:rubensk at nic.br>>;
> ua-discuss <ua-discuss at icann.org <mailto:ua-discuss at 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 at nic.br <mailto:rubensk at nic.br>> wrote:
>
>
>
>
> On 24 Nov 2019, at 00:22, Mark W. Datysgeld
> <mark at governanceprimer.com
> <mailto:mark at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20191207/eb1034b7/attachment.html>
More information about the UA-discuss
mailing list