Registry Contact Details

• Contact Name: [Please fill in Contact Name]
• Email address: [Please fill in Email address]
• Phone Number: [Please fill in optional Phone Number]

Label Generation Rules for the Arabic Language

Overview

This document specifies a set of Label Generation Rules (LGR) for the Arabic language for the second level domain or domains identified above. The ultimate starting point for the development of this LGR can be found in the related Root Zone LGR [RZ-LGR-Arab]. Note that while it is the Arabic Script Root Zone LGR that forms the starting point, the LGR defined here covers the Arabic Language. The format of this file follows [RFC 7940]. This LGR is adapted from the “Reference LGR for the Second Level for the Arabic Language” [Ref-LGR-ar-Arab], for details, see Change History below.

For details and additional background on the Arabic 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 document contains certain provisions for customization. (See “Customizing actions for International Reachability” below.)

Standalone LGR: This LGR is designed to be used in a zone that does not cater to IDNs other than those valid under this LGR. This LGR lacks features that would allow its use in the context of another LGR in the same zone, and it may contain other features incompatible with such use.

Repertoire

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. 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 two sets of decimal digits:

• European (common) digits
• Arabic-Indic 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:

• First, they can significantly overproduce and would require additional rules to contain them effectively, complicating the design.
• Second, even where they are required for some languages, they are optional for others.
• Third, this also circumvents the issue regarding duplication between some precomposed code points and combining sequences raised by [IAB].

Any code points outside the Arabic Language repertoire that are targets for out-of-repertoire variants would be included here only if the variant is listed in this file. In this case they are identified as a reflexive (identity) variant of type “out-of-repertoire-var”. Whether or not they are listed, they do not form part of the repertoire.

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 references documenting sufficient justification for inclusion in the repertoire, see “References” below. For code points that are part of the repertoire, comments identify the languages using the code point.

Correlation Between Repertoire and Bidi Rules

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:

• Prevent digits (whether European, Arabic-Indic, or Extended-Arabic-Indic) from starting a label.
• In any label, allow only digits from one the sets (whether European, Arabic-Indic, or Extended-Arabic-Indic).

Variants

This LGR is designed for use in zones shared by more than one language. For details, see Section 3, “Use of Multiple Reference LGRs in the Same Zone” in [Level-2-Overview]. 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 of its variant labels consisting entirely of cross-language variants would 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. 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. Note that some of these optional variants map to code points that are not declared as part of the repertoire. If such optional variants are enabled, the reflexive “out-of-repertoire-var” mappings for the targets of these mappings must be removed, lest the generated variants fail to validate.

Methodology for Defining Variants

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 was conducted across the whole Arabic script in order to identify all possible variants corresponding to the code point. This was 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 provides an IDN registry with the following benefits:

  • Protection to the registry name space regardless of the supported languages.
  • Doing the work for a language one time. No need to re-study the code-point’s relationship each time a new language (or new set of code point) is supported by the registries.
  • Flexibility to add more language as they become ready without affecting currently supported languages.
  • Consistency with the principle of identifying all possible variants without neglecting or overlooking any similarities without documenting it.

• 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.

• 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 LGR follows the guidelines in [RFC 8228].

Character Classes

This proposal defines the following named character classes:

• common-digits — ASCII digits: U+0030 0 to U+0039 9
• arabic-indic-digits — Arabic-Indic digits used with Arabic: U+0660 ٠ to U+0669 ٩
• extended arabic-indic-digits — Arabic-Indic digits used with other languages: U+06F0 ۰ to U+06F9 ۹
• arabic-language — code points used in pure Arabic language labels
• pashto-language — code points used in pure Pashto language labels
• persian-language — code points used in pure Persian language labels
• urdu-language — code points used in pure Urdu language labels
• dual-joining — joining-type D
• right-joining — joining-type R
• joins-to-the right — union of joining-type R and joining-type D

Whole Label Evaluation (WLE) and Context Rules

Common Rules

By default, the LGR includes the rules and actions to implement the following restrictions mandated by the IDNA protocol. They are marked with ⍟.

• Hyphen Restrictions — restrictions on the allowable placement of hyphens (no leading/ending hyphen and no hyphen in positions 3 and 4). These restrictions are described in Section 4.2.3.1 of RFC 5891 [150]. They are implemented here as context rule on U+002D (-) HYPHEN-MINUS.
• Leading Combining Marks — restrictions on the allowable placement of combining marks (no leading combining mark). This rule is described in Section 4.2.3.2 of RFC 5891 [150].

Right-To-Left Rules

• leading-digit — RFC 5893 [160] restrictions on the allowable placement of digits (no leading digit), see section 2.1 of [160]; implemented here as a context rule on each digit.
• digit-mixing — no mixing between different digit sets (European, Arabic-Indic, and Extended-Arabic-Indic digits) is allowed (see section 2.4 of RFC 5893 [160]); implemented here as a WLE rule with associated action.

Default Actions

This LGR includes the default actions for LGRs as well as the action needed to invalidate labels with misplaced combining marks. They are marked with ⍟. For a description see [RFC 7940].

Arabic Language-specific Rules

The following rules aim at reducing the allocation of redundant labels.

• No connected ALEF MAKSURA in the Arabic language — restriction on having ALEF MAKSURA (0649) before a right joining or dual joining code point.
• No languages mixing in the generated variants — restriction on mixing code points from different language tables. Any variant must be generated using code point taken from a single supported language table.

Arabic Language-specific Actions

The LGR includes several actions that invalidate a label violating the constraints expressed by the Arabic-specific rules. In addition, the three non-default variant mapping types used in this LGR trigger actions that result in variant label dispositions as follows:

• if at least one variant is in {activated}, force delegation,
• if at least one variant is in {optionally-activated}, by default the label is allocatable, but the LGR can be customized to force delegation for these variant labels by selecting a different disposition in the corresponding action,
• if at least one variant is in {optionally-allocatable}, by default the label is blocked, but the LGR can be customized to make the variant label allocatable instead, by selecting a different disposition in the corresponding action.

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.

Customizing Actions for International Reachability

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 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.

Methodology and Contributors

The LGR in this document has been adapted from the corresponding Reference LGR for the Second Level. The Second Level Reference LGR for the Arabic Language has been edited by Michel Suignard and Asmus Freytag, based on extensive community input. That LGR is based on the Root Zone LGR for Arabic and relies on information contained or referenced therein, see [RZ-LGR-Arab]. Suitable extensions for the second level have been applied according to the [Guidelines] and with community input. 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 Section 2 and Appendix H in [Proposal-Arabic], as well as [RZ-LGR-Overview].

Changes from Version Dated 13 January 2021

Language tag has been updated.

Changes from Version Dated 18 May 2021

Unicode Version has been updated.

Changes from Version Dated 24 January 2024

Adopted from the Second Level Reference LGR for the Arabic Language [Ref-LGR-ar-Arab] without normative changes.

References

General references for the language

• Wikipedia: Arabic alphabet
  https://en.wikipedia.org/wiki/Arabic_alphabet
• Omniglot: Arabic
  https://www.omniglot.com/writing/arabic.htm

The following general references cited in this document

[Guidelines]

ICANN, “Guidelines for Developing Reference LGRs for the Second Level”, (Los Angeles, California: ICANN, 27 May 2020),
https://www.icann.org/en/system/files/files/lgr-guidelines-second-level-27may20-en.pdf

[IAB]

Internet Architecture Board (IAB), “IAB Statement on Identifiers and Unicode 7.0.0"
https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/

[IDN-GUIDE]

Saudi Network Information Center, “Guidelines Rules for writing Arabic IDNs under the IDN ccTLD (السعودية.)”
https://nic.net.sa/docs/Guidelines_for_writing_Arabic_IDNs_under_the_IDN_ccTLD_V1.2-en.pdf

[Level-2-Overview]

Internet Corporation for Assigned Names and Numbers, (ICANN),“Reference Label Generation Rules (LGR) for the Second Level: Overview and Summary” (PDF), (Los Angeles, California: ICANN, 24 January 2024),
https://www.icann.org/en/system/files/files/level2-lgr-overview-summary-24jan24-en.pdf

[MSR-5]

Integration Panel, “Maximal Starting Repertoire — MSR-5 Overview and Rationale”, 24 June 2021,
https://www.icann.org/en/system/files/files/msr-5-overview-24jun21-en.pdf

[Proposal-Arabic]

TF-AIDN, “Proposal for Arabic Script Root Zone LGR”, Version 3.4, 18 November 2015
https://www.icann.org/en/system/files/files/arabic-lgr-proposal-18nov15-en.pdf

[RFC 5564]

RFC 5564, El-Sherbiny, et al. “Linguistic Guidelines for the Use of the Arabic Language in Internet Domains”, RFC5564, February 2010,
https://tools.ietf.org/html/rfc5564

[RFC 6365]

Hoffman, P. and J. Klensin, “Terminology Used in Internationalization in the IETF”, BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011,
https://www.rfc-editor.org/info/rfc6365

[RFC 7940]

Davies, K. and A. Freytag, “Representing Label Generation Rulesets Using XML”, RFC 7940, August 2016,
https://www.rfc-editor.org/info/rfc7940

[RFC 8228]

A. Freytag, “Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels”, RFC 8228, August 2017,
https://www.rfc-editor.org/info/rfc8228

[RZ-LGR-Overview]

Integration Panel, “Root Zone Label Generation Rules (RZ LGR-5): Overview and Summary”, 26 May 2022 (PDF),
https://www.icann.org/sites/default/files/lgr/rz-lgr-5-overview-26may22-en.pdf

[RZ-LGR-Arab]

ICANN,, “Root Zone Label Generation Rules for the Arabic Script”, (Last published as part of RZ-LGR-5, see
https://www.icann.org/sites/default/files/lgr/rz-lgr-5-overview-26may22-en.pdf)

[SAC060]

ICANN Security and Stability Advisory Committee (SSAC), “SSAC Comment on Examining the User Experience Implications of Active Variant TLDs Report”, 23 July 2013,
https://www.icann.org/en/system/files/files/sac-060-en.pdf

[TF-AIDN]

Fahd Batayneh, Blog, “Task Force for Arabic Script IDNs”, 23 May 2014,
https://community.icann.org/display/MES/Task+Force+on+Arabic+Script+IDNs
workspace:
https://community.icann.org/display/MES/TF-AIDN+Work+Space

[Ref-LGR-ar-Arab]

ICANN, Second Level Reference Label Generation Rules for the Arabic Language (ar-Arab), 24 January 2024 (XML)
https://www.icann.org/sites/default/files/packages/lgr/lgr-second-level-arabic-language-24jan24-en.xml
non-normative HTML presentation:
https://www.icann.org/sites/default/files/packages/lgr/lgr-second-level-arabic-language-24jan24-en.html

[Unicode 11.0.0]

The Unicode Consortium. The Unicode Standard, Version 11.0.0, (Mountain View, CA: The Unicode Consortium, 2018. ISBN 978-1-936213-19-1)
https://www.unicode.org/versions/Unicode11.0.0/

[VIP]

Internationalized Domain Names Variant Issues Project, “Arabic Case Study Team Issues Report”, 7 October 2011,
https://archive.icann.org/en/topics/new-gtlds/arabic-vip-issues-report-07oct11-en.pdf

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. In the listing of whole label evaluation and context rules, references [150] and [160] indicate the source for common rules.

Character Classes

Number of named classes	10
Implict defined by script tag	2

The following table lists all named and implicit classes with their definition and a list of their members intersected with the current repertoire (for larger classes, this list is elided).

Name	Definition	Count	Members or Ranges	Ref	Comment
right-joining	Prop=jt:R	152→14	{0622-0625 0627 0629 062F-0632 0648 06C3 06CD 06D2}		Any character matching Unicode property Joining_Type:Right_Joining
dual-joining	Prop=jt:D	610→30	{0626 0628 062A-062E 0633-063A 0641-0647 0649-064A 06A9 06BA 06BE 06C1 06CC 06D0}		Any character matching Unicode property Joining_Type:Dual_Joining
joins-to-the-right	combined = [[:right-joining:] ∪ [:dual-joining:]]	762→44	{0622-063A 0641-064A 06A9 06BA 06BE 06C1 06C3 06CC-06CD 06D0 06D2}
arabic-language	explicit	57	{002D 0030-0039 0621-063A 0641-064A 0660-0669}
urdu-language	explicit	63→56	{002D 0030-0039 0621-0622 0626-0628 062A-063A 0641-0642 0644-0646 0648 06A9 06BA 06BE 06C1 06C3 06CC 06D2 06F0-06F9}
persian-language	explicit	56→52	{002D 0030-0039 0621-0622 0626-0628 062A-063A 0641-0642 0644-0648 06A9 06CC 06F0-06F9}
pashto-language	explicit	68→56	{002D 0030-0039 0621-0622 0624 0626-0628 062A-063A 0641-0642 0644-0648 064A 06A9 06CC-06CD 06D2 06F0-06F9}
common-digits	Tag=Common-digit	10	{0030-0039}		Digits from the ASCII range; ⍟
arabic-indic-digits	Tag=Arabic-indic-digit	10	{0660-0669}		Arabic-Indic digits; ⍟
extended-arabic-indic-digits	Tag=Extended-arabic-indic-digit	10	{06F0-06F9}		Extended Arabic-Indic digits
implicit	Tag=sc:Arab	65	{0621-063A 0641-064A 0660-0669 06A9 06BA 06BE 06C1 06C3 06CC-06CD 06D0 06D2 06F0-06F9}		Any character tagged as Arabic
implicit	Tag=sc:Zyyy	11	{002D 0030-0039}		Any character tagged as Common

Legend

Members or Ranges

Lists the members of the class as code points (xxx) or as ranges of code points (xxx-yyy). Any class too numerous to list in full is elided with "...".

m→n

Indicates a set for which only n of its m members fall inside the repertoire.

Tag=ttt

A named or implicit class defined by all code points that share the given tag value (ttt).

Prop=ppp:vvv

A named class defined by reference to value vvv of Unicode property ppp.

Explicit

A named class defined by explicitly listing all its members.

Implicit

An anonymous class implicitly defined based on tag value and for which there is no named equivalent.

Combined

A named class defined by set operations on other classes using the following syntax:

[: :] - named or implicit character set

Reference to a named character set [:name:] or an implicit character set [:tag:]. A leading “^” before name or tag indicates the set complement.

∪, ∩, ∖, ∆ - set operators

Sets may be combined by set operators (∪ = union, ∩ = intersection, ∖ = difference, ∆ = symmetric difference).

Whole label evaluation and context rules

Number of rules	6
Used to trigger actions	3
Used as context rule (C)	3
Anchored context rules	3

The following table lists all named rules defined in the LGR and indicates whether they are used as trigger in an action or as context (when or not-when) for a code point or variant.

Name	Regular Expression	Used as Trigger	Anchor	Used as Context	Ref	Comment
leading-combining-mark	(start)[∅=[[∅=\p{gc=Mn}] ∪ [∅=\p{gc=Mc}]]]	✔			[150]	RFC 5891 restrictions on placement of combining marks ⍟
hyphen-minus-disallowed	(((start))← ⚓︎)|(⚓︎ →((end)))|(((start)..\u002D)← ⚓︎)		✔	C	[150]	RFC 5891 restrictions on placement of U+002D - ⍟
single-language-label	(start)(([:arabic-language:]+)|([:persian-language:]+)|([:urdu-language:]+)|([:pashto-language:]+))(end)	✔				a label/variant can only be written using characters from one of the 4 languages
leading-digit	((start))← ⚓︎		✔	C	[160]	RFC 5893 RTL labels cannot start with a digit ⍟
digit-mixing	([:common-digits:].*([:arabic-indic-digits:]|[:extended-arabic-indic-digits:]))|([:arabic-indic-digits:].*([:common-digits:]|[:extended-arabic-indic-digits:]))|([:extended-arabic-indic-digits:].*([:common-digits:]|[:arabic-indic-digits:]))	✔			[160]	RFC 5892 and RFC 5893 restrictions on mixing digits; extended to all three sets
initial-or-medial-position	⚓︎ →([:joins-to-the-right:])		✔	C		U+0649 ى ALEF MAKSURA must not be in initial or medial position

Legend

Used as Trigger

This rule triggers one of the actions listed below.

Used as Context

This rule defines a required or prohibited context for a code point C or variant V.

Anchor

This rule has a placeholder for the code point for which it is evaluated.

Regular Expression

A regular expression equivalent to the rule, shown in a modified notation as noted:

⚓︎ - context anchor

Placeholder for the actual code point when a context is evaluated. The code point must occur at the position corresponding to the anchor. Rules containing an anchor cannot be used as triggers.

(...)← - look-behind

If present encloses required context preceding the anchor.

→(..) - look-ahead

If present encloses required context following the anchor.

( ) - group

An anonymous nested rule is used to group match operators.

(... | ...) - choice

When there is more than one alternative in a rule, the choices are separated by the alternation operator (...|...).

start or end

(start) matches the start of the label; (end) matches the end of the label.

. - any code point

. matches any code point.

*, +, ?, {n,m} - count operators

* indicates 0 or more, + indicates one or more, and ? indicates up to one instance. {n,m} indicates at least n and at most m instances.

[: :] - named or implicit character set

Reference to a named character set [:name:] or an implicit character set [:tag:]. A leading “^” before name or tag indicates the set complement.

[\p{ }] - property

Set of all characters matching a given value for a Unicode property [\p{prop=val}]. Note: uppercase “\P” defines the complement of a property set.

∪, ∩, ∖, ∆ - set operators

Sets may be combined by set operators (∪ = union, ∩ = intersection, ∖ = difference, ∆ = symmetric difference).

∅= - empty set

Indicates that the following set is empty because of the result of set operations, or because none of its elements is part of the repertoire defined here. A rule with a non-optional empty set never matches.

⍟ - default rule

Rules marked with ⍟ are included by default and may or may not be triggered by any possible label under this LGR.

Actions

The following table lists the actions that are used to assign dispositions to labels and variant labels based on the specified conditions. The order of actions defines their precedence: the first action triggered by a label is the one defining its disposition.

#	Condition	Rule / Variant Set		Disposition	Ref	Comment
1	if label does not match	single-language-label	→	invalid		all labels (including variants) must be entirely within one of four languages
2	if label matches	digit-mixing	→	invalid		a label matching the RFC 5892 and RFC 5893 restriction on digit mixing is invalid
3	if label matches	leading-combining-mark	→	invalid		RFC 5892: labels with leading combining marks are invalid ⍟
4	if at least one variant is in	{out-of-repertoire-var}	→	invalid		disallow code points that are out of repertoire
5	if at least one variant is in	{blocked}	→	blocked		any variant label containing blocked variants is blocked ⍟
6	if at least one variant is in	{optionally-allocatable}	→	blocked		optional allocation for certain within-repertoire variants; to make allocation possible, change (blocked) to (allocatable)
7	if at least one variant is in	{optionally-activated}	→	allocatable		optional delegation for certain cross-repertoire variants; to make delegation mandatory, change (allocatable) to (activated)
8	if at least one variant is in	{activated}	→	activated		forced delegation for certain in-repertoire variants
9	if each variant is in	{allocatable}	→	allocatable		variant labels with all variants allocatable are allocatable
10	if any label (catch-all)		→	valid		catch all (default action)

Legend

{...} - variant type set

In the “Rule/Variant Set” column, the notation {...} means a set of variant types.

⍟ - default action

Actions marked with ⍟ are included by default and may or may not be triggered by any possible label under this LGR.