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 French

Overview

This document specifies a set of Label Generation Rules (LGR) for the French language using a language-specific repertoire for the second level domain or domains identified above. The format of this file follows [RFC 7940]. This LGR is adapted from the “Reference LGR for the Second Level for the French Language” [Ref-LGR-fr-Latn], for details, see Change History 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

Most references converge on 42 Latin code points.

There is no IDN table published in the IANA Repository of IDN Practices by a .fr ccTLD, but AFNIC has published specifications [700] listing the code points accepted for registration as IDNs in the .fr domain. PointQuébec has published a list of accepatable code points for the .quebec domain [701].

Excluded code points

Letters documented in some references but not included:

• U+00DF ß LATIN SMALL LETTER SHARP S

• U+00E1 á LATIN SMALL LETTER A WITH ACUTE

• U+00E3 ã LATIN SMALL LETTER A WITH TILDE

• U+00E4 ä LATIN SMALL LETTER A WITH DIAERESIS

• U+00E5 å LATIN SMALL LETTER A WITH RING ABOVE

• U+00EC ì LATIN SMALL LETTER I WITH GRAVE

• U+00ED í LATIN SMALL LETTER I WITH ACUTE

• U+00F2 ò LATIN SMALL LETTER O WITH GRAVE

• U+00F3 ó LATIN SMALL LETTER O WITH ACUTE

• U+00F5 õ LATIN SMALL LETTER O WITH TILDE

• U+00F6 ö LATIN SMALL LETTER O WITH DIAERESIS

• U+00F8 ø LATIN SMALL LETTER O WITH STROKE

• U+00FA ú LATIN SMALL LETTER U WITH ACUTE

• U+00FD ý LATIN SMALL LETTER Y WITH ACUTE

• U+0101 ā LATIN SMALL LETTER A WITH MACRON

• U+0113 ē LATIN SMALL LETTER E WITH MACRON

• U+012B ī LATIN SMALL LETTER I WITH MACRON

• U+01D4 ǔ LATIN SMALL LETTER U WITH CARON

Extended code points

A number of letters not considered essential to writing the core vocabulary of the language are nevertheless in common use. Where they have not been added to the core repertoire, they are flagged as “extended-cp” in the table of code points. A context rule is provided that by default will prohibit labels with such extended code points. To support extended single code points or code point sequences, delete the context “extended-cp” from their repertoire definition.

The sole “extended” code point in the second version had been U+0F1 LATIN SMALL LETTER N WITH TILDE, cited by some references as being used in loan words. Based on additional research, it can also be found in personal names from the region of Brittany which argues that it should be included by default.

Variants

It has been the practice of some second level registries to allow both the registration of an accented label as well as the pure ASCII fallback to the same entity, while disallowing the registration of the two labels to unrelated entities (See [CIRA]).

By default, this LGR treats all accented forms as optionally-enabled" variants of the non-accented form of a label which would prevent them from being delegated to two different entities simultaneously. In order to restrict the number of allocatable variants, only one accented form can be allocated alongside the non-accented form. If the desired accented form has been applied for, the non-accented form would then be a variant that is allocatable to the original applicant. This covers the most common scenario of a single “correct” accented form, plus a non-accented “fallback”.

This extension to in-language variants is not compatible with using this LGR in a zone with another LGR and using the Common LGR to process conflicts between labels from multiple LGRs as described in Section 3 “Use of Multiple Reference LGRs in the Same Zone” in [Level-2-Overview].

No other variants are applicable when using the LGR in a standalone fashion.

Variants Limited to Standalone Use This LGR is not intended for use with LGRs for other languages or scripts in the same zone. The LGR does not define any “blocked” variants with code points in other languages or script that would prevent malicious registration of duplicate labels perceived as the same by users. As a result of transitivity, the scheme of internal variants defined here would have to be imposed on other LGRs that contain copies or variants of the affected code points.

If it is desired to support multiple languages in the same zone, the preferred method would be to support the corresponding script LGRs, which cater to the use of multiple languages, and are designed with the possibility of concurrent use in mind.

Optionally-enabled Variants

Certain variants in this LGR are defined as optionally enabled. They are using the context rule “enabled”. This context rule matches any label (it always succeeds). Any variant marked with when=“enabled” (in the XML file) is in force, while marking it with not-when=“enabled” causes the variant definition to be ignored in processing. This allows these variants to be disabled, for example, to better match legacy practice for a given zone.

Care must be taken to enable or disable variants so that all variant mappings to and from the same code point are either enabled or disabled at the same time, ensuring that all enabled variant mappings remain symmetric and transitive.

The specification of variants in this LGR follows the guidelines in [RFC 8228].

Character Classes

This LGR does not define named character classes.

Rules

Common Rules

The LGR includes the rules and actions to implement the following restrictions, some of which are mandated by the IDNA protocol. They are marked with ⍟ and included here by default. A special context rule enables optional variants by default.

• 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].
• Enabled — matches any label. Used as variant context rule; any variant with when="enabled" in the xml will be active, while any with not-when="enabled" will be inactive.

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

Because this LGR defines allocatable fallback variants the following default actions are applicable.

• blocked — a variant label containing a blocked variant will receive a disposition of “blocked”.
• r-original — a label containing one or more of this reflexive variant type and no others represents an original label and receives a disposition of “valid”.
• fallback — a label containing one or more of these variant types and no others represents a label that contains only fallback variants and receives a disposition of “allocatable”.
• fallback plus other — any label remaining containing both this variant type and any others receives a disposition of “blocked”.

These actions resolve as “allocatable” any label where all variants are of type “fallback”, and as “valid” any label where all variants are of type “r-original”. Labels with a mix of variant types are resolved as “blocked”.

To account for original code points in a permuted variant, reflexive variant mappings with an “r-” prefix are used. (See [RFC 7940]). In particular, the mapping type “r-original” is given to any code point that has a fallback mapping, but that appears in its non-fallback form in the original label, and thus “maps to itself”.

Default actions that are triggered by the LGR-specific variant types described above limit the “allocatable” variant labels to those variants resulting from removal of the accents, while disallowing mixed use of variants with or without accents, except as in the original applied-for label. The use of such variants is "optionally_enabled_variants">optionally enabled in this LGR.

Note that the mapping types for variants are not symmetric: they depend on which code point is considered the source or the target in a given mapping. As specified in [RFC 7940], when mapping types are evaluated code points in a label that are unchanged use the type of their “reflexive” mapping. Per [RFC 7940] the actions are always applied one after the other, and the evaluation stops at the first action that assigns a disposition to a given label.

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 French Language was developed by Michel Suignard and Asmus Freytag, including input by Michael Everson, Nicholas Ostler, and Wil Tan, and based on multiple open public consultations.

Changes from Version Dated 10 October 2016

Language tag has been updated.

Changes from Version Dated 18 May 2021

Unicode Version has been updated.

Based on research showing use of ‘ñ’ in Breton names, U+00F1 ñ LATIN SMALL LETTER N WITH TILDE has been changed from “extended-cpto included by default.

Based on community comments expressed during the review of the Latin script Root Zone LGR, the need was established for fallback variants between French letters with diacritics and their ASCII base letters. These variants are enabled here by default, but are marked as “enabled” to allow registries to deactivate them if required.

Changes from Version Dated 24 January 2024

Adopted from the Second Level Reference LGR for the French Language [Ref-LGR-fr-Latn] without normative changes.

References

General references for the language:

• Atkins, Beryl T. et al. 1987. Robert · Collins dictionnaire français-anglais anglais-français = Collins · Robert French-English English-French dictionary. Paris: Dictionnaires le Robert. ISBN 2-85036-088-0. Glasgow: HarperCollins. ISBN 0-00-433451-5

• Wikipedia: “French orthography”,
  https://en.wikipedia.org/wiki/French_alphabet

• Omniglot: French (français)
  https://www.omniglot.com/writing/french.htm

In addition, the following references were consulted:

[CIRA]

cira, Section 3, “Admissible Domain Names” in General Registration Rules
https://www.cira.ca/policy/rules-and-procedures/general-registration-rules
(Accessed 25 May 2022)

[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

[PointQuebec]

PointQuébec, Section 8 “Permissible Characters” in General Registration Policies
https://registry.quebec/legal/

[Ref-LGR-fr-Latn]

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

[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

[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/

In the listing of the repertoire by code point, references starting from [0] refer to the version of the Unicode Standard in which the corresponding code point was initially encoded. Other references (starting from [100]) document usage of code points. Entries in the table may have multiple source reference values. In the listing of whole label evaluation and context rules, reference [150] indicates the source for common rules. For more details, see the Table of References below.

Character Classes

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
implicit	Tag=sc:Latn	43	{0061-007A 00E0 00E2 00E6-00EB 00EE-00EF 00F1 00F4 00F9 00FB-00FC 00FF 0153}		Any character tagged as Latin
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 "...".

Tag=ttt

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

Implicit

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

Whole label evaluation and context rules

Number of rules	4
Used to trigger actions	1
Used as context rule (C)	1
Used as context rule (V)	1
Anchored context rules	1
Used only in another rule	1

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 - ⍟
extended-cp	(start)(end)					context to gate off code points from the extended range, matches no label ⍟
enabled	(start).*(end)			V		use as when-context to enable: matches any label ⍟

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.

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

(^.*$) - any label

The regex (^.*$) matches any label. Used as a context rule, it always matches, thus not affecting the validity of a label containing the code point. By convention, it is used to explicitly mark a preferred code point for review purposes.

⍟ - default rule

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

Note: The following rules are defined but not used in this LGR: extended-cp.

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 matches	leading-combining-mark	→	invalid		labels with leading combining marks are invalid ⍟
2	if at least one variant is in	{blocked}	→	blocked		any variant label containing blocked variants is blocked ⍟
3	if each variant is in	{fallback}	→	allocatable		any label with all variants of type fallback is allocatable ⍟
4	if at least one variant is in	{fallback}	→	blocked		any variant label with a mix of variant forms is blocked ⍟
5	if each variant is in	{r-original}	→	valid		any remaining label containing only original code points is valid ⍟
6	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.