This document specifies a reference set of Label Generation Rules (LGR) for the Arabic language for the second level. The starting point for the development of this LGR can be found in the related Root Zone LGR [RZ-LGR-4-Arab]. For details and additional background on the script, see "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 format of this file follows [RFC 7940].
The document contains certain provisions for customization. (See "Customizing actions for International Reachability" below.)
The repertoire is a subset of the one described in Section 3.2 of [Proposal-Arabic] and only includes the 36 code points for letters in active everyday general use in the Arabic language. For the second level, the repertoire has been augmented with the HYPHEN-MINUS, and two sets of decimal digits:
for a total of 57 repertoire elements.
This LGR does not include combining marks or code point sequences. All combining marks have been excluded for these reasons:
For further details, see Section 3.2, "Code point repertoire included" in [Proposal-Arabic]. (The proposal cited has been adopted for the Arabic script portion of the Root Zone LGR.)
Code points outside the Arabic language that are listed in this file are targets for out-of-repertoire variants and are identified by a reflexive (identity) variant of type "out-of-repertoire-var". They do not form part of the repertoire.
Each code point or range is tagged with the script or scripts that the code point is used with, and one or more references documenting sufficient justification for inclusion in the repertoire, see "References" below. Comments identify the languages using the code point.
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:
This reference LGR is designed for use in zones shared by more than one language. Where appropriate, cross-language variants have been defined to mutually exclude labels from different languages that could otherwise be substituted by the users. Once a label has been delegated for one language, any such variant labels from other languages could be blocked. Any label containing at least one code point that is not a cross-language variant would be considered distinct. Because of that, even large numbers of defined cross-language variants generally do not lead to a high percentage of labels experiencing a collision.
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. 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'.
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:
When building a variant table, for each code point in the Arabic language repertoire, a full study is conducted across the whole Arabic script in order to identify all possible variants corresponding to the code point. This is done for more protection to the registry’s TLD-space and to minimize the overhead of re-studying when the registry decides to support more than one language from the Arabic script. Hence, conducting this variant study across the whole Arabic script would provide an IDN registry with the following benefits:
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 pointy 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.
Even though we are constructing an LGR at a language level, because we are addressing international reachability, we need to prevent mixing between code points from different language tables while generating a valid variant. Otherwise, some of permuted variants will be composed of characters (code points) that are not part of a single language or they are not easily available for a single input device (keyboard). Therefore, from a practical and realistic point of view, and to significantly minimize the number of allocatable variants and maximize the number of blocked variants, it blocking these unrealistic variants represents best practice.
Based on the principle expressed in the previous item, code points not part of the Arabic language repertoire have been added to variant sets to facilitate international reachability. Many of these out-of-repertoire code points are involved in at least one variant mapping of type "activated", "optionally-activated", or "optionally-allocatable. The dispositions related to the extended variants 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.
Note: Please note that the set of supported languages used for implementing the above concepts (namely international reachability and no mixing between languages) is a first version. The set may be updated in the future by adding new languages whenever they become ready.
The specification of variants in this reference LGR follows the guidelines in [RFC 8228].
This proposal defines the following named character classes:
Actions include the default actions for LGRs as well as that needed to invalidate labels with misplaced combining marks. They are marked with ⍟. For a description see [RFC 7940].
The following rules aim at reducing the allocation of redundant labels.
The three non-default variant mapping types used in this reference LGR trigger actions that result in variant label dispositions as follows:
Variant mappings of type "activated" lead to a disposition of "activated", which means the variant label should be delegated. This variant type is used here for the variant mappings between European and Arabic-Indic digits, to guarantee that labels differing only by the digit set used will all be delegated. Activated variants are handled by the first action above, and are not affected by the optional customizations described below.
As described above, this LGR is designed so that full "international reachability" is optionally available. It can easily be enabled with a small customization.
The disposition for the second of the actions listed above is by default set to "allocatable" which makes the variant available to registrants that would like to support international reachability. Some registry operators may desire to make support for such variants mandatory, in which case the disposition (disp="allocatable" in the XML) for the relevant action could be changed from "allocatable" to "activated" without further changes to the LGR.
The disposition for the last of the actions listed above is by default set to "blocked" which reserves the variants of type "optionally-allocatable". Some registry operators may desire to support such variants as allocatable, in which case the disposition (disp="blocked" in the XML) for the relevant action could be changed from "blocked" to "allocatable" without further changes to the LGR.
Note that this reference LGR allows variant labels containing out-of-repertoire code points to be "allocatable" or "activated". However, independent of which of the customizations for disposition is chosen above, an original label (as applied for) that contains any of the affected code points would remain unavailable.
Most of the code points involved in labels resulting in "activated" or "allocatable" actions are subject to a "single-language-label" rule to decrease the number of activated or allocatable variants. This is especially a concern for the "activated" action which results in forced delegation.
If optional variant labels are all made allocatable, a significantly large number of allocatable variant labels can potentially be created. Keeping the allocatable variant labels manageable is advised by SSAC in their [SAC060] report. One way to contain such variant labels, as suggested by the Arabic script community, is to allow only the variant labels which are usable and still block those which may be redundant, e.g. cannot be typed from a single keyboard supporting a given language. For this purpose, the no languages mixing rule is part of this LGR.
Furthermore, applying this customization to variant sets involving code points which are not restricted by the "single-language-label" rule should be done with caution. This is especially true for the variant set including the ALEF characters, for which an external policy should be established to ensure that only a strictly limited number of variant labels are allocated. It may not be possible to create a general policy that determines which of the variants from among a potential large variant pool are indeed suitable; therefore, the selection may have to be left as a choice to the registrant, but within a strict cap on their number.
This reference LGR for the Arabic language for the 2nd Level has been edited by Michel Suignard and Asmus Freytag, based on extensive community input. This LGR is based on the Root Zone LGR for Arabic and relies on information contained or referenced therein, see [RZ-LGR-4-Arab]. Suitable extensions for the second level have been applied according to the [Guidelines]. The specific features related to the Arabic Language LGR were drafted by a TF-AIDN sub-group (namely in alphabetical order: Abdalmonem Tharwat Galila , Abdeslam Nasri , Abdulaziz Al-Zoman, Abdulrahman Alghadir, Hazem Hezzah, Nabil Benamar, Raed Alfayez, Tarik Merghani). In addition, Sarmad Hussain provided editorial support.
For more information on methodology and contributors to the underlying Root Zone LGR, see [Proposal-Arabic], as well as [RZ-LGR-Overview].
For references consulted particularly in designing the repertoire for the Arabic language LGR for the second level, please see details in the Table of References below. Reference [0] refers to Unicode Standard version in which the corresponding code points were initially encoded. References [100] and above correspond to sources justifying the inclusion of the corresponding code points. Entries in the table may have multiple source reference values. References [150] and [160] indicate the source for common rules.
]]>