[arabic-vip] ZWNJ (earlier: [vip] Overarching principles used in Devanagari team report)

[Abdulaziz Al-Zoman]

Dear Dr. Siavash 

> -----Original Message-----
> From: Siavash Shahshahani [mailto:shahshah at irnic.ir]
> Sent: Sunday, September 25, 2011 7:36 PM
> To: Abdulaziz Al-Zoman
> Cc: Dr.Sarmad Hussain; arabic-vip at icann.org
> Subject: Re: [arabic-vip] ZWNJ (earlier: [vip] Overarching principles used
> in Devanagari team report)
> 
> Dear Dr. Al-Zoman,
> I've seen your statements about ZWNJ and noted the wholesale changes and
> deletions you are proposing for the final document. I wished you had had a
> chance to participate more fully in the latest rounds of discussions that
> led to this document. It is truly a tribute to Sarmad's infinite patience
> and fairness as well as to  hundreds of hours of work by him and others
> that this document is seeing the light of the day. Certainly some
> fine-tuning and corrections may be in order, but such drastic deletions and
> changes as you're proposing is tantamount to rejecting this very
> commendable effort. I sincerely believe that a little discussion can
> alleviate your present misgivings, and you will join the rest of us in
> celebrating the end of the first phase of this endeavor.

I have followed and participated in the group meetings and mailing lists 
from the start. However, as we approached the middle of the month of 
Ramadhan, I have already informed the group that I will be away until 
almost the f-2-f meeting which I wanted to attend but the timing was 
not suitable for me. Regardless, I was following the group progress 
through my colleague Raed who fully participated in all the meetings. 

This is the 2nd draft of the final report sent to the group.

As all can recall, I have commented in the 1st draft of the report before Eid. 
And this is the 2nd draft (that I have seen in the mailing list) after 
the f2f meeting.

... so please consider the changes and modification that I have suggested 
as my contribution for the improvement of the final document.
I'm quite sure that all of us want to deliver a quality work and not just mere 
finish the task. The report should represent the result of the 
discussions and consensus. 


> I'll make just two
> comments to address your major concerns:
> 1. This document is NOT solely concerned with putting TLDs in the root. It
> is true that much of the discussion on the structure of variants
> concentrated on the top level, but that's because the top level domain
> structure is the part directly under ICANN's purview and there is a new
> gTLD delegation process coming up for which ICANN must have clear and
> immediate guidelines. On the other hand, gTLD delegation process is more
> than just putting a string in the root. There are, e.g., legal aspects to
> the gTLD process such as dispute resolution for which ICANN has shouldered
> responsibility. It is imperative that the dispute resolution regime under
> which new gTLDs are to operate be defined beforehand; you cannot dismiss
> that effort by fiat. You may believe, as I do, that very little
> modification is needed in the present UDRP to make it operable for IDN
> gTLDs, but this has to be demonstrated through a thorough examination of
> possible problems that variants and other aspects of IDN may engender. Same
> goes for several other topics you had expressed a  wish to eliminate.

I think it is a good practice and needed to stick to the objective of the assignment.
The ICANN assignment clearly stated that: 
(see http://www.icann.org/en/announcements/announcement-20apr11-en.htm)
      "...identifying what needs to be done with the evaluation, 
      possible delegation, allocation and operation of IDN 
      gTLDs containing variant characters, as part of the 
      new gTLD process in order to facilitate the development
      of workable approaches to the deployment of gTLDs
      containing variant characters IDNs" 

      Project Scope 
        There are several identified issues with the delegation
        of IDN variant TLDs. Excluding a variant of the TLD 
        may disenfranchise communities that use the characters
        in the excluded TLD strings, while allowing the delegation
        of variants without carefully considering its impact could
        lead to inconsistent user experience as well as security
        and stability issues. 
 
        The expected user experience if using delegated IDN variant
        TLDs as compared to using the related base label TLD may
        vary from case to case. In general, to ensure the success
        delegation of IDN variant TLDs, the following tasks needs
        to be completed:  
 
      Project Tasks: 
        1. Create a commonly understood glossary of terms and 
           ensure that such terms are accurate and vetted with
           appropriate technical and linguistic communities and
           are used consistently throughout the project to
           improve the dialogue among participants 
        2. Identify the set of challenges of working with 
           IDN variant TLDs that are based on (a) linguistic accuracy,
           (b) technical feasibility and accuracy, (c) usability, (d)
           accessibility, and (e) security and stability 
 
      The IDN Variant Issues Project focuses on question (1) and (2)." 

> 2. I believe the fear experienced by some about the use of ZWNJ is highly
> illusory.

It is Not illusory ... it is a fact. ZWNJ is a control character that is invisible.
The Arab users cannot see it, cannot type it, cannot understand and 
comprehend it. So it represent a risk to the Arab user community. 

John C Klensin has said:
"So, while permitting ZWNJ (and ZWJ) in top-level domain names
seems attractive, it is not safe -- much less safe than
permitting the PVALID characters that are always displayed.
Striking the balance between safety and the desire to be able to
include all mnemonics based on any language in the world will
always be a difficult choice and, ultimately, a policy one, but,
as long as the community believes that security, stability, and
predictable behavior take precedence over the use of any given
character in any given script, decisions that exclude
problematic characters from the root will continue to be
justified"

> Suppose you see a string on a bill-board or in the airport
> containing a ZWNJ. It may confuse you as an Arab because you don't use ZWNJ
> and we've all been taught that empty space is not allowed in a domain
> string. But how does this threaten the security and stability of the
> Internet? You will certainly not be led to reaching a wrong address,
> because typing the empty space will not get you anywhere. And why should
> you bother? You won't probably need that address anyway. If the company
> with that domain address wants to reach the Arab audience, it will take
> care of adopting a domain reachable by Arab keyboards.

Yes it bother me that Arab users cannot type such addresses and hence
will not be able to reach these addresses. 

Suppose that an Arab traveler is in Tahran's airport and he/she needs
to access these addressee (in Arabic IDN which includes ZWNJ)
due to some important maters (e.g., related to Visa, passport, traveling, 
changing flight route, etc) that are provided by local companies, he/she would 
not be able to do so.

> Please note that we
> eliminated the confusion that may arise in the use of ZWNJ in conjunction
> with the three characters U+0637-8 and U+069F. You don't really want to
> disenfranchise some 300 million people who use the Arabic script WITH ZWNJ?
> I think Behnam's example of the confusion between < بیا > and < یبا >
> should be more threatening. Both are perfectly legitimate strings on any
> Arabic-script keyboard.
> I hope this little friendly explanation will help.
> Best regards,
> Siavash
> 
> On Sun, 25 Sep 2011 10:04:46 +0000, Abdulaziz Al-Zoman
> <azoman at citc.gov.sa>
> wrote:
> > Dear Dr. Sarmad and all,
> >
> > You stated that " Again, the choices being proposed accommodate the
> needs
> > of all language communities, where Arabic language community may decide
> not
> > to activate the variants with ZWNJ and the communities of other
> languages
> > may decide to activate them. "
> >
> > It is foreseen that new gTLD registries would not be attached to single
> > community. There will be multiple international companies that will
> provide
> > Arabic Script TLDs. They will serve the whole script communities.
> >
> > Therefore, if ZWNJ is allowed in a TLD then it is not the choice of the
> > language community to activate or not activate the variants with ZWNJ.
> >
> >
> > -----------------------------
> > عبدالعزيز بن حمد الزومان
> > Abdulaziz H. Al-Zoman
> >
> > From: sarmad.hussain at kics.edu.pk [mailto:sarmad.hussain at kics.edu.pk] On
> > Behalf Of Dr.Sarmad Hussain
> > Sent: Sunday, September 25, 2011 11:12 AM
> > To: Abdulaziz Al-Zoman
> > Cc: arabic-vip at icann.org
> > Subject: Re: [arabic-vip] ZWNJ (earlier: [vip] Overarching principles
> used
> > in Devanagari team report)
> >
> > Dear Dr. Al-Zoman and All,
> >
> > What you would suggest would be an option 4.  However, option 3 is
> > intended as it is articulated (different from option 4).
> >
> > Options 1-3 are suggested to cover the breadth of needs (including those
> > for Farsi, Kurdish, Urdu and many other languages being used online
> using
> > the Arabic scrip).
> >
> > ZWNJ is already prohibited in contexts it is invisible.  It is
> indirectly
> > visible in all the contexts being suggested due to shaping alternation.
> >
> > Again, the choices being proposed accommodate the needs of all language
> > communities, where Arabic language community may decide not to activate
> the
> > variants with ZWNJ and the communities of other languages may decide to
> > activate them.
> >
> > As per the activation, in our F2F meeting, we discussed that the variant
> > label set could be pre-determined through the Arabic script TLD label
> > generation policy but which subset of these variants is activated is
> > requested by the applicant (others, please correct me if this is not the
> > correct understanding).
> >
> >
> >
> > regards,
> > Sarmad
> >
> >
> > On Sun, Sep 25, 2011 at 12:28 AM, Abdulaziz Al-Zoman
> > <azoman at citc.gov.sa<mailto:azoman at citc.gov.sa>> wrote:
> > Thanks for the clarification …
> >
> > What I'm with is the option that:
> >         What you type is what you see.
> >
> > When a user see a label in an airport, for example written in Arabic
> > script,  he/she would like to type it as it appears in the add. ZWNJ/ZWJ
> > are transparent to the users they cannot be seen and cannot be typed by
> the
> > (Arab users). It looks like a space (which is not permitted in domain
> > names). Hence, if the add displays a domain with a TLD which includes
> ZWNJ,
> > (Arab) users will get confused and will not be able to reach that domain
> > name.
> >
> > So, the option 3 should not include the ZWNJ in the fundamental TLD nor
> in
> > the activated/delegated variants of the TLD.
> >
> > -----------------------------
> > عبدالعزيز بن حمد الزومان
> > Abdulaziz H. Al-Zoman
> >
> > From: sarmad.hussain at kics.edu.pk<mailto:sarmad.hussain at kics.edu.pk>
> > [mailto:sarmad.hussain at kics.edu.pk<mailto:sarmad.hussain at kics.edu.pk>]
> On
> > Behalf Of Dr.Sarmad Hussain
> >
> > Sent: Sunday, September 25, 2011 9:40 AM
> > To: Abdulaziz Al-Zoman
> > Cc: arabic-vip at icann.org<mailto:arabic-vip at icann.org>
> >
> > Subject: Re: [arabic-vip] ZWNJ (earlier: [vip] Overarching principles
> used
> > in Devanagari team report)
> >
> > Dear Dr. Al-Zoman and All,
> >
> > Just to further clarify my own email (not responding to Dr. Al-zoman's
> > mail below), please note that even in option 3 it is being suggested
> that
> > ZWNJ can be allowed in the variant to fundamental label (up to the user
> to
> > activate or reserve it).  Just wanting to make that explicit.
> >
> > regards,
> > Sarmad
> >
> >
> >
> >
> > On Sat, Sep 24, 2011 at 11:25 PM, Abdulaziz Al-Zoman
> > <azoman at citc.gov.sa<mailto:azoman at citc.gov.sa>> wrote:
> > 1 and 2 is not valid options for a normal Arab user at all … when he
> sees
> > a label which includes ZWNJ … he/she will think that is a space … the
> other
> > form (without ZWNJ) is NOT similar to the original one with ZWNJ … hence
> > he/she cannot reach that domain name
> >
> > Hence, there is only one option, unfortunately, which is 3.
> >
> > -----------------------------
> > عبدالعزيز بن حمد الزومان
> > Abdulaziz H. Al-Zoman
> >
> > From: arabic-vip-bounces at icann.org<mailto:arabic-vip-bounces at icann.org>
> >
> [mailto:arabic-vip-bounces at icann.org<mailto:arabic-vip-bounces at icann.org>]
> > On Behalf Of Dr.Sarmad Hussain
> > Sent: Sunday, September 25, 2011 9:11 AM
> >
> > To: arabic-vip at icann.org<mailto:arabic-vip at icann.org>
> > Subject: Re: [arabic-vip] ZWNJ (earlier: [vip] Overarching principles
> used
> > in Devanagari team report)
> >
> > Dear All,
> >
> > Thank you for your condolences privately and on this list.
> >
> >
> > We have seen the opinions on ZWNJ on this list both in support of and
> > against having it enabled for TLDs.
> >
> > Firstly, let me reiterate that these arguments clearly brings it out as
> an
> > issue (will try to summarize all arguments in its favor and against in
> our
> > final document, but not doing it here as (even if we may not agree) all
> of
> > us understand the arguments being made in each case).
> >
> > However, I would want to go beyond and suggest a possible
> recommendation,
> > which (to me) can actually address both sides of argument
> simultaneously:
> >
> > 1. If we recommend that ZWNJ is allowed, however the string with it is
> > considered a variant of the string without it, that addresses KB,
> > confusability and security issues (but gives the users the choice and
> > flexibility based on their language)
> >
> > 2. If we want to be more conservative, we can suggest that if ZWNJ is
> > allocated, then the variant without it must also be allocated
> >
> > 3.  If we wan to be even more conservative, we can also suggest that the
> > label with ZWNJ cannot be a fundamental label
> >
> >
> > Could this address the issue?  If yes, should we stop at 1? 2? or must
> > also have 3?
> >
> > You are kindly requested to consider both sides of the arguments
> > sympathetically as you respond.
> >
> >
> > regards,
> > Sarmad
> >
> >
> >
> >
> > On Sat, Sep 24, 2011 at 9:58 PM, Abdulaziz Al-Zoman
> > <azoman at citc.gov.sa<mailto:azoman at citc.gov.sa>> wrote:
> > Dear all,
> >
> > I do agree with what Andrew has said:".. the mere
> > fact that someone sometimes uses a string as part of their language is
> > in no way an argument that such a string should be permitted as a
> > label at any part of the DNS, never mind in the root"
> > Hence, digits, space, and ZWNJ are not allowed just because they will
> > cause more harms than benefits. Here we are dealing with the TLDs at the
> > root level hence we should give security, stability and usability the
> > highest priority.
> >
> > Therefore, I did recommend (previously) not to support the space in the
> > TLD and now I strongly with NOT to support ZWNJ/ZWJ at the root TLD
> level.
> >
> > Just a note:
> > The ZWNJ/ZWJ as a concept is not know at all by the Arabic speaking
> > community even not be the ARAB IT Specialists:
> > - They (the Arab users) do not know their (i.e., ZWNJ/ZWJ) behavior.
> > - They never heard about them.
> > - They never type them.
> > - It is not in the keyboard.
> > - They do not know how to type them.
> > - and most importantly ... they cannot see them.
> >
> >
> > -----------------------------
> > عبدالعزيز بن حمد الزومان
> > Abdulaziz H. Al-Zoman
> >
> > -----Original Message-----
> > From: arabic-vip-bounces at icann.org<mailto:arabic-vip-bounces at icann.org>
> >
> [mailto:arabic-vip-bounces at icann.org<mailto:arabic-vip-bounces at icann.org>]
> > On Behalf Of Andrew Sullivan
> > Sent: Sunday, September 25, 2011 4:07 AM
> > To: arabic-vip at icann.org<mailto:arabic-vip at icann.org>
> > Subject: Re: [arabic-vip] ZWNJ (earlier: [vip] Overarching principles
> used
> > in Devanagari team report)
> > On Sat, Sep 24, 2011 at 11:09:41AM +0000, Raed Al-Fayez wrote:
> >
> >> So I think if the group is going to support ZWNJ and/or ZWJ in
> >> TLDs(because it may be needed by other languages) then we should
> >> also ask to support/reconsider the support of the space in TLDs and
> >> even more in all Internet Standards (IDNA RFC, DOMAIN RFC
> >> ..etc). Also if the group is going to support them in the TLD then
> >> we should add a warning that they may cause a risk and ICANN should
> >> study this topic carefully.
> >
> > Just to be clear: what you are requesting there is that the team
> > recommending throwing out restrictions in RFC 952 (and consequently,
> > depending on your reading, RFC 1035), and also restrictions built into
> > IDNA2008 (RFC 5890-5894).  This amounts to a requirement that every
> > machine on the entire Internet needs to be upgraded before the change
> > could take place.  Are you sure that's something you want to ask for?
> >
> >> Personally I think enabling the numbers in TLD is also important
> >> because we are not sure that other language may use them in their
> >> writing system (I hear that Jawi language do so).
> >
> > I have suggested before, but I will suggest here again, that the mere
> > fact that someone sometimes uses a string as part of their language is
> > in no way an argument that such a string should be permitted as a
> > label at any part of the DNS, never mind in the root.  Irish names in
> > English and French all over the place both use the apostophe, U+0027.
> > That is not an argument that we should start allowing that character
> > in to DNS labels (even though, in a strict sense, it is already a
> > perfectly legal character).  The reason digits aren't permitted at the
> > top level is simple: they're potentially confused by end system
> > software as IP addresses.  (Dotted quad is not the only way to
> > represent IP addresses, note.)
> >
> > Best regards,
> >
> > A
> >
> > --
> > Andrew Sullivan
> > ajs at anvilwalrusden.com<mailto:ajs at anvilwalrusden.com>
> >
> ----------------------------------------------------------------------------
> -------
> > Disclaimer:
> > This message and its attachment, if any, are confidential and may
> contain
> > legally
> > privileged information. If you are not the intended recipient, please
> > contact the
> > sender immediately and delete this message and its attachment, if any,
> > from your
> > system. You should not copy this message or disclose its contents to any
> > other
> > person or use it for any purpose. Statements and opinions expressed in
> > this e-mail
> > are those of the sender, and do not necessarily reflect those of the
> > Communications
> > and Information Technology Commission (CITC). CITC accepts no liability
> > for damage
> > caused by this email.