[TF-AIDN] Fwd: [Ext] Re: minutes of the call (11-06-2020)

Sun Jul 5 18:24:09 CEST 2020

Dear All,

We have received a feedback from Dr. Sarmad.

Please read through...

---------- Forwarded message ---------
From: Sarmad Hussain <sarmad.hussain at icann.org>
Date: Fri, Jul 3, 2020 at 12:43 PM
Subject: Re: [Ext] Re: [TF-AIDN] minutes of the call (11-06-2020)
To: Nabil Benamar <benamar73 at gmail.com>
Cc: Fahd Batayneh <fahd.batayneh at icann.org>

Dear Nabil,

I hope this mail finds you in good health.

Please find attached the updated second level LGR for the review and
feedback of TF-AIDN. This incorporates the changes discussed.

Kindly review and share any further feedback you may have.

Regards,

Sarmad

*From: *Sarmad Hussain <sarmad.hussain at icann.org>
*Date: *Thursday, June 18, 2020 at 4:16 PM
*To: *Nabil Benamar <benamar73 at gmail.com>
*Cc: *Fahd Batayneh <fahd.batayneh at icann.org>
*Subject: *Re: [Ext] Re: [TF-AIDN] minutes of the call (11-06-2020)

Dear Nabil,

Thank you for the detailed discussion on the possible way forward, which
you have captured in your email to TF-AIDN below already, i.e. we change
the disposition names to optionally-allocatable and optionally-activated
(which will by mapped to blocked and allocatable respectively by default).
A registry may decide to make it more liberal.  I have attached the version
I shared before and a “liberal” version (see the filename) for you to
compare the different in allocatable (+ activated) variants generated by
two different solutions.  With only a few Alefs in a label, the liberal
version creates many more allocatable (+activated) variants.

You can test these using the online lgr tool at lgrtool.icann.org as I
demonstrated.  You can also consult its user guide
<https://www.icann.org/en/system/files/files/lgr-toolset-user-guide-23oct18-en.pdf>
if needed.

Please let me know if you have any questions.

Regards,

Sarmad

*From: *Nabil Benamar <benamar73 at gmail.com>
*Date: *Thursday, June 18, 2020 at 4:03 PM
*To: *"Ali M. AlHoshaiyan" <ahoshaiyan at citc.gov.sa>
*Cc: *"TF-AIDN (tf-aidn at meswg.org)" <tf-aidn at meswg.org>, Sarmad Hussain <
sarmad.hussain at icann.org>, Raed Al-Fayez <rfayez at citc.gov.sa>, Abdulaziz
Al-Zoman <azoman at citc.gov.sa>, "Hesham M. AlHammad" <hhammad at citc.gov.sa>
*Subject: *[Ext] Re: [TF-AIDN] minutes of the call (11-06-2020)

Daer Ali,

I would like to thank you for your detailed feedback.

The example of the spelling of the word (احمد)  illustrates clearly the
issue we have with the current LGR2 rules. Both solutions that you
proposed can be applied and fix the issues. However, they remain
separate processes.

Implementing the rules of  optionally-allocatable and optionally-activated
may not limit the number of allocatable variants we may have, but it gives
a particular registry the freedom to add, modify, adapt existing LGR2 rules
to meet his requirements and needs. LGR2 may be implemented differently in
registry servers.

The *general LGR2* , as a reference model, "should" be a bit conservative
to limit the number of allocatable variants, and to meet the SSAC
requirements.

Updating an RFC is a process within IETF and not within ICANN. Then, if we
want to change the current RFC (making it deprecated) and suggesting a new
one, we need to suggest such a thing to the right WG within IETF. This is
something we can do, as TF-AIDNs members,  but it will take time to come up
with a new RFC knowing how the IETF works. I have recently published RFC
8691 [tools.ietf.org]
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8691&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KTETvEaGPwPcawI-QmNa-kiv-ZBvdgyyLm-mxd028M4&m=dQq-LMIoUqJqJYChkDFDh4P8Q17V8g3OcJL461h_LG4&s=D3qkIsJL9YcBqYCyE4iVmMpLuJ10vYTa6id0P6Dydds&e=>
which took 7 years to go from draft to an RFC !!!

I think that we can adopt the first solution you suggested and in parallel,
and as a separate thread, poste our request in the IETF mailing list.

Best regards

Nabil Benamar

-------------------

نبيل بنعمرو

On Tue, Jun 16, 2020 at 10:36 AM Ali M. AlHoshaiyan <ahoshaiyan at citc.gov.sa>
wrote:

Dear Dr. Sarmad,
Dear TF-AIDN members,

As you may know that the Arabic language is quite  complex and diverse
language that needs its own special treatment., We, as technical experts
and specialists, should make the science and technologies serve the
language to make life easier to end users rather than twist the technology
to serve the technologies.  Innovation and creativity should allow us to
reach our goal without jeopardizing language usages. Necessity is the
mother of all inventions, and LGR was an invention that solves many
problems that we have faced.

We at SaudiNIC believe that the proposed solution is not practical and will
confuse a lot of registries and whoever decides to use the Second Level LGR
in their work (i.e. software developers etc…). Those people are not
language experts and will use the XML files as is, since it’s meant to be
read by machines and not humans, this is going to hurt and limit the
benefits of IDNs. IDNs are supposed to make the internet accessible to more
people around the world, by helping those that cannot read nor write
English.

We are supposed to help people and make their life easier, not make
something that will limit them and make their life harder, and by blocking
essential variants in the Arabic language people could make mistakes that
they can never recover from. As example, let us assume that a registry uses
this proposed version of the LGR and allowed a user to register (احمد)
which is a common way to write that name but it is not the correct way, and
then the user have realized their mistake by not registering the
appropriate spelling for Ahmed in Arabic which is (أحمد) with HAMZA ABOVE.
The user now has two possible solutions. The first solution is to register
the second form but this is actually not possible since it cannot be
registered due to the LGR rules. The second solution is for the user to be
fully aware of the IDNs and all XML tables and rules (which we consider as
an implementation detail that should have made his life easier in the first
place) then ask the registry to change the LGR to allow such variants.
Additionally, a registry operator that is not an expert in the language
will have to come back to ICANN or TF-AIDN who blocked these variants in
the first place. The user now is stuck with an unfixable mistake.

The Arabic world is large and diverse and certain words are written
differently especially when it comes to ALEF. Some write it (أنترنت), some
write it (انترنت) and some use (انترنت) and (إنترنت) interchangeably.

Unfortunately, the proposed solution (the use of allocatable-extended and
activated-extended) does not provide a real solution but rather introduced
a new label with the same block action.

There are 2 ways to tackle to problem: either restore the previous
dispositions proposed by TF-AIDN especially the activated disposition; or
update the RFC to add a new and official dispositions named
optionally-allocatable and optionally-activated. For example, the latter
clearly states that this variant is optional for registries and software
developers to allocate or activate respectively.

We at SaudiNIC believe that technology should serve people and help them to
make their life easier. Therefore, we strongly recommend to go with the
first solution since it is the easiest and straightforward. If that is not
possible then we strongly recommend the second solution where the relevant
RFC should be updated by adding a new disposition that clearly states the
optional variant and allow anyone to activate them at their well.

SaudiNIC has been in the business since 1995 as a registry and a software
development firm, and from experience we know that the community will take
whatever out there and use it without investigating it, they just want to
get their job done, and we are afraid that the standard for these variants
will be blocked for all people. Take for example the public suffix list, it
is used by every software vendor, and most of them unfortunately use it
without judging it or investigating its inner workings, the same could and
will happen to the Arabic language Second Level LGR.

So please, we are asking that we do the right thing and allow those
variants and not regret this in the future then find it harder to fix just
like what happened to DNS in the first place, it supported ASCII only and
led to implement the IDN solution on the Application Layer, and until this
very day is not implemented correctly by software developers. Change is
hard in the future, as is the case with DNS, people hardcode everything in
their software, and no one have time to correct old versions or upgrade to
new versions in fear that they will break something (take for example a lot
of companies still are running mainframes and Windows 2000 server until
this very day), and this is something ICANN itself is fighting in the
Universal Acceptance.

Please consider doing the right thing.

Thank you,
Ali Alhoshaiyan

From: <tf-aidn-bounces at meswg.org> on behalf of Nabil Benamar <
benamar73 at gmail.com>
Date: Monday, June 15, 2020 at 9:07 AM
To: "TF-AIDN (tf-aidn at meswg.org)" <tf-aidn at meswg.org>
Subject: [TF-AIDN] minutes of the call (11-06-2020)

Salam Dear TF-AIDNs members ,

I hope you are all doing well.

The TF-AIDNs members had a meeting on 11-06-2020 where we discussed the
following points:

  1.  Whether we should adopt the solution proposed by Dr. Sarmad to reduce
the number of allocatable variants.
  2.  Or, investigate further on the feasibility and easiness of the Master
Key based solution proposed by CITC.

Please, send your comments as soon as you can so that we get back to ICANN
without further delays.

Thank you all for your commitment.

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.meswg.org/pipermail/tf-aidn/attachments/20200705/9f1aebbb/attachment-0002.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.meswg.org/pipermail/tf-aidn/attachments/20200705/9f1aebbb/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lgr-second-level-arabic-language-24jun20-en.xml
Type: text/xml
Size: 57075 bytes
Desc: not available
URL: <http://lists.meswg.org/pipermail/tf-aidn/attachments/20200705/9f1aebbb/attachment-0001.xml>