This document specifies a set of Label Generation Rules (LGR) for the Arabic script for the second level domain or domains identified above. The starting point for the development of this LGR can be found in the related Root Zone LGR [RZ-LGR-Arab]. The format of this file follows [RFC 7940]. This LGR is adapted from the “Reference LGR for the Second Level for the Arabic Script” [Ref-LGR-und-Arab], for details, see Change History below.
For details and additional background on the Arabic script, see TF-AIDN, “Proposal for Arabic Script Root Zone LGR”, Version 3.4, 18 November 2015 [Proposal-Arabic]. Additional work was done by a TF-AIDN group to create extensions appropriate to the second level and these are incorporated in this LGR. (See “Methodology” below).
The document contains certain provisions for customization. (See “Customizing actions for International Reachability” below.)
The repertoire includes the 128 code points for letters used by languages that are actively written in the Arabic script. The repertoire is a subset of [Unicode 11.0.0]. For details, see Section 3.2 in [Proposal-Arabic]. (The proposal cited has been adopted for the Arabic script portion of the Root Zone LGR.)
For the second level, the repertoire has been augmented with the HYPHEN-MINUS, and three sets of decimal digits:
for a total of 159 repertoire elements.
The repertoire excludes code points for which TF-AIDN was unable to find sufficient evidence of use (see Appendix F in [Proposal-Arabic]).
This LGR does not include combining marks or code point sequences. All combining marks have been excluded for these reasons:
Repertoire Listing: Each code point or range is tagged with the script or scripts with which the code point is used and one or more other character categories. For each repertoire element, one or more references document sufficient justification for inclusion in the repertoire; see the “References” below. Comments identify the principal languages or orthographies using the code point. Languages are given with their [EGIDS] level.
Note: use of standard Arabic code points by other languages is not marked.
Because this LGR contains only a subset of PVALID code points, the Bidi rules expressed in Section 2 of RFC 5893 [160] (Bidi Rule) can be simplified to two constraints:
The variants defined in this LGR are limited to those required for use in zones not shared with any other script. However, because it does not share cross-script variants with other script LGRs, this LGR can be mixed easily with other LGRs in the same zone.
For details on the methodology used to assign in-script variants for letters, see “Methodology for Defining Variants” below.
Digit Variants: All Arabic digits are treated as semantic variants of the corresponding common (ASCII) digits. By transitivity, they are also semantic variants of any native digits in scripts that also include the common digits. Such variant relations are deemed to exist implicitly by transitivity but are not listed explicitly in each reference LGR. Instead, if needed, they are applied by using the Common LGR in label processing.
Because of the restriction on leading digits, most labels would contain a unique code point in addition to any digits, thus no variant labels would actually result from any pro-forma cross-script variants.
To keep digit variant sets manageable in zones where multiple scripts are present, no attempt has been made at identifying cross-script variants among digits of different numeric value or between a digit in one script and a letter in another, such as between digit zero and Latin letter ‘o’. Other mechanisms may be required to prevent homograph labels.
Variant Disposition: This LGR includes “blocked” and “allocatable” variants, assigned according to Section 4, “Final recommendation of variants for Top Level Domains (TLDs)” in [Proposal-Arabic]. These recommendations balance the desire to minimize the number of possible allocatable variants with the need to keep the definition of variants simple. See also the comments given in the listing.
For the second level, three additional variant types are added: “optionally-allocatable”, “activated”, and “optionally-activated”. They are used to improve user acceptance. The rationale for these new types is provided below.
In generating the variant tables, a number of concepts have been used:
One of the main principles for the stability of the Internet and IDNs is that the end user should be able to reach a website connected to his/her domain name regardless of location. Additionally, an end user reads and types website addresses based on his/her language alphabet and whatever is available in his/her keyboard. Therefore, in order to enforce this principle the input devices (language table) that the user may use to reach a domain name (based on the user location) should be carefully considered when defining variants. Otherwise, it may cause a reachability problem and reduce the user acceptance. For example, if someone registered the domain name “مكة” (all characters from the Arabic language) and a user try to reach the website connected to this domain name from an Internet café or airport, say, in Pakistan. He/she will not be able to reach that website unless if the variant “مکۃ” (Urdu variant) is already allocated and activated. Thus, variants need to be studied from both similarity point of view (by language community) and reachability point of view (based on input devices used by other language communities).
Consistency is a very important concept in generating variants. Regardless of the selected applied-for label the list of generated allocatable variants should be the same. As we are dealing with normal users at the SLD, their 1st choice (applied-for) label might not be the one that will be used by the internet community. Therefore, a registry should provide the registrant the ability to “correct” his/her choice if he/she was not successful with the first try. For example, the word “Internet” is written in most Arab countries in North Africa as (أنترنت) while it is written in other Arab countries as (إنترنت), while end users often write it as (انترنت). Therefore, if someone registered “أنترنت”, he/she should be able to enable “إنترنت” or “انترنت”. Additionally, many words have two correct ways to write them, for example, both “آدم” and “أدم” are widely used for the same name Adam. Hence, if someone registered “أدم” he/she should be able to enable “آدم” or “ادم”. This is achieved by making variants allocatable in at least one direction in the LGR.
Based on the principle expressed in the previous item, some code points are involved in at least one variant mapping of type “activated”, “optionally-activated”, or “optionally-allocatable. The dispositions related to these mappings may be optionally modified by a registry by editing the appropriate action elements. See the section on “Customizing Actions for International Reachability” for details of how this feature can be made mandatory or disabled.
The specification of variants in this LGR follows the guidelines in [RFC 8228].
This proposal defines the following named character classes:
By default, the LGR includes the rules and actions to implement the following restrictions mandated by the IDNA protocol. They are marked with ⍟.