Préparation des chaînes internationalisées ("stringprep")

Statut de ce mémo

Le présent document spécifie un protocole de normalisation Internet pour la communauté de l'Internet, qui appelle à la discussion et à des suggestions pour son amélioration. Prière de se reporter à l'édition en cours des "Normes de protocole officielles de l'Internet" (STD 1) sur l'état de la normalisation et le statut de ce protocole. La distribution du présent mémo n'est soumise à aucune restriction.

Notice de Copyright

Copyright (C) The Internet Society (2002). Tous droits réservés.

Résumé

Le présent document décrit un cadre de préparation des chaînes de texte Unicode afin d’augmenter la probabilité que l’entrée de chaîne et la comparaison de chaîne fonctionne d’une manière qui ait un sens pour les usagers normaux tout autour du globe. Le protocole stringprep est utile pour les valeurs d’identifiant de protocole, les noms de personnes et de sociétés, les noms de domaine internationalisés et d’autres chaînes de texte.

Le présent document ne spécifie pas comment les protocoles devraient préparer les chaînes de texte. Les protocoles doivent créer des profils de stringprep afin de spécifier pleinement les options de traitement.

Table des matières

1 Introduction
1.1 Terminologie .
1.2 Utilisation de stringprep dans les protocoles
2 Vue générale de la préparation
3 Transposition
3.1 Habituellement transposés à rien
3.2 Changement de casse
4. Normalisation
5 Résultat interdit
5.1 Caractères d’espace
5.2 Caractères de contrôle
5.3 Utilisation privée
5.4 Séquences codées de non caractère
5.5 Codes de substitution
5.6 Inapproprié pour le texte en clair
5.7 Inapproprié pour une représentation canonique
5.8 Changement des propriétés d’affichage ou déconseillés
5.9 Caractères d’étiquetage
6. Caractères bidirectionnels
7 Séquences codées non allouées dans les profils Stringprep
7.1 Catégories de séquence codée
7.2 Raisons des différences entre chaînes mémorisées et interrogations
7.3 Versions d’applications et chaînes mémorisées
8 Références
8.1 Références normatives
8.2 Références informatives
9 Considérations sur la sécurité
9.1 Considérations de sécurité spécifiques de stringprep .
9.2 Considérations de sécurité génériques d’Unicode
10 Considérations relatives à l’IANA
11 Remerciements
A Répertoires Unicode
A.1 Séquences codées non allouées dans Unicode 3.2
B Tableaux de transposition
B.1 Habituellement transposé à rien
B.2 Transposition pour le repli de casse utilisé avec NFKC
B.3 Transposition pour le repli de casse utilisé sans normalisation
C. Tableaux d’interdiction
C.1 Caractères d’espace
C.2 Caractères de contrôle
C.3 Utilisation privée
C.4 Séquences codées ne représentant pas un caractère
C.5 Codes de substitution
C.6 Inapproprié pour le texte en clair
C.7 Inapproprié pour la représentation canonique
C.8 Changement des propriétés d’affichage ou déconseillés
C.9 Caractères d’étiquetage
D. Tableaux bidirectionnels
D.1 Caractères avec la propriété bidirectionnelle "R" ou "AL"
D.2 Caractères avec la propriété bidirectionnelle "L"

1 Introduction

Les programmes d’application peuvent afficher du texte de nombreuses façons différentes. De même, un utilisateur peut entrer du texte dans un programme d’application d’une multitude de façons. Le texte internationalisé (c’est-à-dire, du texte qui n’est pas restreint à l’ensemble étroit des caractères de l’US-ASCII) a de nombreux comportements d’entrée et d’affichage qui peuvent rendre difficile la comparaison de texte d’une façon cohérente.

Le présent document spécifie un cadre de règles de traitement pour le texte Unicode. D’autres protocoles peuvent créer des profils de ces règles ; ces profils permettront aux utilisateurs d’entrer des chaînes de texte internationalisé dans les applications et auront les plus grandes chances d’obtenir correctement le contenu de ces chaînes. Dans ce cas, "correct" signifie que si deux personnes différentes entrent ce qu’elles pensent être la même chaîne dans deux mécanismes d’entrée différents, les chaînes devraient correspondre caractère par caractère.

Le présent cadre ne décrit pas comment les données sont transcodées des autres jeux de caractère en Unicode. Dans les systèmes qui utilisent des ensembles de caractères non Unicode, l’algorithme de transcodage est une partie critique de l’activation d’un fonctionnement sûr et "correct" des chaînes de texte internationalisé.

En plus de l’aide à la correspondance des chaînes, les profils de stringprep peuvent aussi exclure des caractères qui ne devraient normalement pas apparaître dans du texte utilisé dans le protocole. Le profile peut empêcher de tels caractères en changeant les caractères à exclure en d’autres caractères, en supprimant ces caractères, ou en provoquant une erreur si le caractère apparaît dans le résultat. Par exemple, comme le caractère effacement arrière peut causer des résultats d’affichage imprévisibles, un profil peut spécifier qu’une chaîne contenant un caractère d’effacement arrière causera une erreur.

Un profil de stringprep convertit une seule chaîne de caractères d’entrée en une chaîne de caractères de sortie ou retourne une erreur si la chaîne de sortie contiendrait un caractère interdit. Les profils stringprep ne peuvent pas à la fois émettre une chaîne et retourner une erreur.

Les profils stringprep ne peuvent pas tenir compte de toutes les variations qui pourraient survenir ou auxquels peut s’attendre un utilisateur. En particulier, un profil ne sera pas capable de prendre en compte les différentes façons d’épeler dans toutes les langues pour toutes les écritures parce que le nombre de solutions alternatives d’épeler les mots et les phrases est immense. Les utilisateurs s’attendent probablement à ce que toutes les façons équivalentes d’écrire un mot soient rendues équivalentes, ou qu’aucune d’elles ne le soit. Dans les exemples d’équivalents on a "theater" et "theatre", "hemoglobin" et "h<U+00E6>moglobin" en anglais américain opposé à l’anglais britannique. D’autres exemples sont les épellations simplifiées des noms en chinois (par exemple,"<U+7EDF><U+4E00><U+7801>") opposé à l’épellation chinoise traditionnelle équivalente (par exemple, "<U+7D71><U+4E00><U+78BC>"). Les équivalences spécifiques d’une langue telles que "Aepfel" opposé à "<U+00C4>pfel", qui sont parfois considérés comme équivalents en allemand, peuvent n’être pas considérés comme équivalents dans d’autres langages.

1.1 Terminologie

Les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans le BCP 14 [RFC2119].

Note : Un glossaire des termes utilisés dans Unicode et ISO/CEI 10646 se trouve dans [Glossary]. On trouvera des informations sur le modèle de codage des caractères 10646/Unicode dans [CharModel].

Dans le présent document, les noms des caractères utilisent la notation des séquences codées et des noms tirée de la norme Unicode [Unicode3.2] et de la norme ISO/CEI 10646 [ISO10646]. Par exemple, la lettre "a" peut être représentée par "U+0061" ou par "LATIN SMALL LETTER A". Dans les listes des transpositions et des caractères interdits, le "U+" est abandonné pour faciliter la lecture. Les commentaires pour les gammes de caractères sont indiqués entre crochets (comme "[CARACTERES DE CONTROLE]") et ne viennent pas de la norme.

1.2 Utilisation de stringprep dans les protocoles

Le protocole stringprep n’est pas autonome ; il doit être utilisé par d’autres protocoles des à des endroits précisément définis de ces autres protocoles. Par exemple, un protocole qui a des chaînes qui viennent de la totalité du répertoire de caractères de l’ISO/CEI 10646 [ISO10646] peut spécifier que seules les chaînes qui ont été traitées avec un profil particulier de stringprep sont légales. Un autre exemple serait celui d’un protocole qui effectue la comparaison de chaîne à une étape du protocole ; ce protocole pourrait spécifier qu’une telle comparaison n’est effectuée qu’après le traitement des chaînes selon un profil spécifique de stringprep.

Lorsque deux protocoles qui utilisent des profils différents de stringprep interopèrent, il peut y avoir un conflit sur les caractères qui sont ou ne sont pas permis dans la chaîne finale. Et donc, les développeurs de protocoles devraient considérer avec la plus grande attention la réutilisation de profils de stringprep existants.

Lorsqu’un développeur souhaite permettre aux utilisateurs une gamme de caractères aussi large que possible dans les chaînes d’entrée de texte, il doit, lorsque c’est possible, faire que stringprep convertisse les caractères de la chaîne d’entrée en forme canonique plutôt que de les interdire.

Bien qu’il soit facile d’utiliser le processus stringprep pour "corriger" les bogues ou dysfonctionnements perçus dans les normes de caractère actuelles, les profils stringprep NE DEVRAIENT PAS le faire.

Un profil de stringprep peut créer des tableaux différents de ceux qui figurent dans les appendices du présent document, mais cela devra rester une exception. L’intention de stringprep est de définir les tableaux et de choisir les profils de stringprep parmi les tableaux définis.

Un profil de stringprep DOIT inclure tout ce qui suit :

- l’applicabilité prévue du profil,
- le répertoire de caractères en entrée et en sortie de stringprep (Unicode 3.2 pour cette version de stringprep),
- les tableaux de transposition utilisés à partir du présent document (comme décrit à la section 3),
- tous tableaux de transposition supplémentaires spécifiques du profil,
- la normalisation Unicode utilisée, s’il en est (comme décrit à la section 4),
- les tableaux de caractères, tirés du présent document, qui sont interdits en sortie (comme décrit à la section 5),
- l’essai de chaîne bidirectionnelle utilisé, s’il en est (comme décrit à la section 6),
- tous les caractères supplémentaires qui sont spécifiquement interdits en sortie pour le profil.

Chaque profil DOIT déclarer le répertoire de caractères sur lequel va fonctionner le profil. L’appendice A fait la liste des répertoires Unicode qui peuvent être choisis. Aucun répertoire n’est jamais complet, et on s’attend à ce que des caractères soient ajoutés au répertoire Unicode dans un futur prévisible ; la section 7 du présent document décrit comment traiter les caractères qui seront alloués dans des versions ultérieures des répertoires Unicode. Les paragraphes de l’appendice A font aussi la liste des séquences codées non allouées pour chaque répertoire.

Le présent document est pour Unicode version 3.2, et ne devrait pas être considéré comme d’application automatique à toutes les versions Unicode ultérieures. L’IETF, par une action explicite de normalisation, peut mettre à jour le présent document en tant que de besoin pour traiter les versions Unicode ultérieures.

Le présent document fait la liste des séquences codées non allouées dans la gamme de 0 à 10FFFF pour Unicode 3.2 dans l’appendice A. La liste de l’appendice A DOIT être utilisée par les mises en oeuvre de la présente spécification. Si il y a des discordances entre la liste de l’appendice A et la spécification Unicode 3.2, la liste de l’appendice A a toujours la préséance.

Chaque profil de stringprep DOIT être enregistré auprès de l’IANA. La procédure d’enregistrement est décrite dans l’appendice Considérations relatives à l’IANA ; schématiquement, l’IESG doit revoir chaque profil de stringprep. Les développeurs de protocoles sont vivement encouragés à vérifier dans les registres de profil de l’IANA lorsqu’ils créent de nouveaux profils de stringprep, et à réutiliser la logique des profils précédents chaque fois que possible dans les nouveaux profils. Dans certains cas, un profil existant peut être réutilisé par un protocole différent.

2 Vue générale de la préparation

Les étapes de la préparation des chaînes sont :

1) Transposition -- Pour chaque caractère en entrée, vérifier si il a une transposition, et si c’est le cas, le remplacer par sa transposition. Ceci est décrit à la section 3.

2) Normalisation – Normaliser si possible le résultat de l’étape 1 en utilisant la normalisation Unicode. Ceci est décrit à la section 4.

3) Interdiction – Rechercher tous les caractères qui ne sont pas permis dans le résultat. Si il s’en trouve, retourner une erreur. Ceci est décrit à la section 5.

4) Rechercher les caractères bidirectionnels – Rechercher si possible les caractères de droite à gauche, et s’il s’en trouve, s’assurer que toute la chaîne satisfait aux exigences des chaînes bidirectionnelles. Si la chaîne ne satisfait pas aux exigences des chaînes bidirectionnelles, retourner une erreur. C’est ce qui est décrit à la section 6.

Les étapes ci-dessus DOIVENT être effectuées dans l’ordre donné pour la conformité à la présente spécification.

Les transpositions décrites à la section 3, et la normalisation Unicode facultative décrite à la section 4, peuvent être de une à rien, de une à une, de une à plusieurs, de plusieurs à une, ou de plusieurs à plusieurs. C’est-à-dire que certains caractères peuvent être éliminés ou remplacés par plus d’un caractère, et le résultat à cette étape peut être plus court ou plus long que l’entrée. A cause de cela, le système qui utilise stringprep DOIT être prêt à recevoir une chaîne plus longue ou plus courte que celle entrée dans l’algorithme stringprep.

3 Transposition

Chaque caractère dans le flux d’entrée DOIT être confronté à un tableau de transposition. Le tableau de transposition DEVRAIT provenir du présent document, bien que le tableau de transposition PUISSE être ajouté ou modifié par le profil. Les tableaux de transposition sont les paragraphes de l’appendice B.

Les listes de l’appendice B DOIVENT être utilisées par les mises en œuvre de la présente spécification. En cas de désaccord entre les listes de l’appendice B et les paragraphes ci-dessous, les listes de l’appendice B ont toujours la préséance.

Pour tout caractère individuel, le tableau de transposition PEUT spécifier qu’un caractère ne soit transposé en rien, ou transposé en un autre caractère, ou transposé en une chaîne d’autres caractères.

Les caractères transposés ne sont pas réexaminés durant l’étape de transposition. C’est-à-dire que si le caractère A à la position X est transposé en caractère B, le caractère B qui est maintenant à la position X n’est pas confronté de nouveau au tableau de transposition.

3.1 Habituellement transposés à rien

Les caractères suivants sont simplement supprimés de l’entrée (c’est-à-dire qu’il ne sont transposés à rien du tout) parce que leur présence ou leur absence dans les identifiants de protocole ne rendrait pas deux chaînes différentes. Leur liste figure au Tableau B.1. Certains caractères ne sont utiles que dans du texte fondé sur la ligne, et sont autrement invisibles et ignorés.

Certains caractères affectent le choix du graphisme et la position du graphème, mais ne porte pas de sémantique.

3.2 Changement de casse

Si un profil est sur le point de transposer des caractères pour une comparaison insensible à la casse, ce profil DEVRAIT transposer en utilisant l’appendice B.2 ou l’appendice B.3. L’appendice B.2 est pour les profils qui utilisent aussi la forme KC de normalisation Unicode, alors que l’appendice B.3 est pour les profils qui n’utilisent pas la normalisation Unicode. Ces tableaux transposent de majuscule en minuscule. Noter que ceci aurait pu être "changer tous les caractères minuscules en caractères majuscules". Cependant, le changement de majuscules en minuscules a été choisi parce qu’il y a une tradition d’utilisation des minuscules dans les applications et protocoles courantes de l’Internet.

Si un profil crée ses propres tableaux de transposition de changement de casse, ils DEVRAIENT se fonder sur [UTR21], et DEVRAIENT transposer des caractères majuscules aux caractères minuscules. Le fichier "CaseFolding.txt" tiré de la base de données Unicode DEVRAIT être utilisé pour préparer le tableau de transposition. Le profil DEVRAIT faire une transposition de casse complète (c’est-à-dire, en utilisant les statuts C, F, et I).

Si le profil utilise la forme KC de normalisation Unicode (comme décrit à la section 4 du présent document), il est important de noter qu’il y a des caractères qui n’ont pas de transposition en [UTR21] mais doivent tout de même être traités. Ces caractères incluent quelques caractères grecs et de nombreux symboles qui contiennent des caractères latins. La liste des caractères à ajouter au tableau de transposition peut être déterminé par l’algorithme suivant :

b = NormalizeWithKC(Fold(a)) ;
c = NormalizeWithKC(Fold(b)) ;

si c n’est pas le même que b, ajouter une transposition pour de "a à c".

Comme NormalizeWithKC(Fold(c)) est toujours égal à c, le tableau est stable à partir de ce point.

L’Appendice B.3 est déduit du fichier CaseFolding-3.txt associé à Unicode 3.2 ; l’Appendice B.2 est fondé sur l’Appendice B.3 avec l’ajout des caractères supplémentaires provenant de l’algorithme ci-dessus.

Les auteurs des profils du présent document doivent considérer les effets du changement de la transposition de tout caractère actuellement alloué lors de la mise à jour de leurs profils. L’ajout d’une nouvelle transposition pour un caractère actuellement alloué, ou le changement d’une transposition existante, pourrait causer une variation entre le comportement des systèmes qui ont été mis à jour et les systèmes qui ne l’ont pas été.

4. Normalisation

Le résultat de l’étape de transposition est facultativement normalisé en utilisant une des formes de normalisation Unicode, comme décrit dans [UAX15]. Un profil peut spécifier une des deux options de normalisation Unicode :

- pas de normalisation
- normalisation Unicode avec la forme KC

Un profil PEUT choisir de ne pas faire de normalisation. Cependant, un tel profil peut facilement donner des résultats surprenants pour les utilisateurs normaux, selon le mécanisme d’entrée qu’ils utilisent. Par exemple, certains mécanismes entrent des caractères de compatibilité qui ressemblent exactement aux caractères sous-jacents, mais ont une séquence codée différente. Dans un autre où la normalisation Unicode aide à créer des résultats prévisibles, les caractères ont plusieurs couplages diacritiques : la normalisation ordonne ces caractères diacritiques de façon prévisible.

D’un autre côté, la normalisation Unicode exige d’assez grands tableaux et une logique de réorganisation des caractères assez compliquée. La taille et la complexité ne devraient pas considérées comme un obstacle, sauf dans les environnements les plus restrictifs, et les besoins devraient être soupesés par rapport aux problèmes résultants de la surprise de l’utilisateur ayant à comparer des chaînes non normalisés. Noter que les tableaux utilisés pour la normalisation ne sont pas donnés dans le présent document, mais qu’ils doivent être déduits de la base de données Unicode, comme décrit dans [UAX15].

Il y a une troisième forme de normalisation, la normalisation Unicode de forme C. Si un profil veut utiliser la normalisation Unicode, il DOIT utiliser la normalisation Unicode de forme KC. La forme KC transpose de nombreux "caractères de compatibilité" en leurs équivalents. Certains systèmes d’interface d’utilisateur rendent possible d’entrer des caractères de compatibilité au lieu de leurs équivalents de base. Et donc, utiliser la forme KC au lieu de la forme C sera cause que plus de chaînes que les utilisateurs voudraient voir correspondre correspondent réellement.

Un profil qui spécifie la normalisation Unicode DOIT utiliser la normalisation qui dans [UAX15] est associée à la version de l’ensemble de caractères Unicode spécifié pour le profil.

Le processus de composition décrit dans [UAX15] exige une version de composition d’Unicode fixée pour s’assurer que les chaînes normalisées dans une version d’Unicode restent normalisées dans d’autres versions futures d’Unicode.

L’IETF compte sur Unicode pour ne pas changer la normalisation des caractères actuellement alloués dans les futures versions de normalisation. Si une version future des tableaux de normalisation changeait la valeur normalisée d’un caractère existant, les auteurs de profils du présent document devront regarder très attentivement les changements avant de mettre à jour les tableaux de normalisation. Un tel changement pourrait causer une variation du comportement entre des systèmes mis à jour et des systèmes qui ne le sont pas.

5 Résultat interdit

Avant qu’un texte puisse être émis, il DOIT faire l’objet d’une recherche de séquences codées interdites. Il y a une grande variété de séquences codées interdites, comme l’explique la présente section. Un profil du présent document PEUT utiliser tous les tableaux de l’appendice C, ou certains d’entre eux.

Le processus stringprep n’émet jamais à la fois une erreur et une chaîne. Si une erreur est détectée durant la recherche de séquences codées interdites, seule une erreur est retournée.

Noter que les paragraphes ci-dessous décrivent comment les tableaux de l’appendice C ont été formés. Ils sont faits pour les personnes qui veulent comprendre le processus, mais devraient être ignorés par les développeurs. Les mises en œuvre qui utilisent les tableaux DOIVENT fonder les transpositions sur les tableaux eux-mêmes, et non sur les descriptions de la présente section qui expliquent comment ont été formés les tableaux.

Les listes de l’appendice C DOIVENT être utilisées par les mises en œuvre de la présente spécification. En cas de désaccord entre les listes de l’appendice C et les paragraphes ci-dessous, les listes de l’appendice C ont toujours la préséance.

Certaines des séquences codées figurant dans un paragraphe peuvent aussi apparaître dans d’autres paragraphes.

Il est important de noter qu’un profil du présent document PEUT interdire des caractères supplémentaires.

Chaque paragraphe de la présente section a un paragraphe correspondant dans l’appendice C. Par exemple, les caractères figurant au paragraphe 5.1 figurent dans l’appendice C.1.

5.1 Caractères d’espace

Les caractères d’espace peuvent rendre presque impossible une transcription visuelle précise des chaînes et peuvent conduire à des erreurs d’entrée par l’utilisateur de nombreuses façons. Noter que la liste ci-dessous est divisée en deux tableaux dans l’appendice C : le Tableau C.1.1 contient les séquences codées en ASCII, alors que le Tableau C.1.2 contient les séquences codées non ASCII. La plupart des profils du présent document qui veulent interdire les caractères d’espace devront inclure les deux tableaux.

5.2 Caractères de contrôle

Les caractères de contrôle (ou caractères avec des fonctions de contrôle) ne peuvent pas être vus et peuvent causer des résultats imprévisibles lorsqu’ils ont affichés. Noter que la liste ci-dessous est divisée en deux tableaux dans l’appendice C : le Tableau C.2.1 contient les séquences codées en ASCII, alors que le Tableau C.2.2 contient les séquences codées non ASCII. La plupart des profils du présent document qui veulent interdire les caractères de contrôle auront à inclure les deux tableaux.

5.3 Utilisation privée

Parce que les caractères d’utilisation privée n’ont pas de signification définie, ils seront vraisemblablement interdits. Les caractères d’utilisation privée sont :

5.4 Séquences codées de non caractère

Les séquences codées de non caractère sont des séquences codées qui ont été allouées dans la norme ISO/CEI 10646 mais ne sont pas des caractères. Étant déjà alloués, on est sûr qu’ils ne seront pas changés ultérieurement en caractères.

La liste des séquences codées de non caractères figure dans le fichier PropList.txt de la base de données Unicode.

5.5 Codes de substitution

Les séquences codées suivantes sont réservées en permanence pour être utilisées comme valeurs de substitution dans le codage UTF-16. Elles ne seront jamais allouées à des caractères dans le répertoire Unicode, et sont donc interdites :

5.6 Inapproprié pour le texte en clair

Les caractères suivants n’apparaissent pas dans le texte normal.

Bien que le caractère de remplacement (U+FFFD) puisse être utilisé lors de l’affichage d’une chaîne, il n’a pas besoin de faire partie de la chaîne elle-même. Il est souvent affiché par les traducteurs pour indiquer "il devrait y avoir un caractère ici, mais il ne peut être traduit". Par exemple, sur un ordinateur sans polices asiatiques, une chaîne avec trois idéogrammes pourrait être traduite par trois caractères de remplacement.

5.7 Inapproprié pour une représentation canonique

Les caractères de description idéographique permettent que différentes séquences de caractères soient traduites de la même façon, ce qui les rend inappropriés pour les chaînes qui doivent avoir une seule représentation canonique.

5.8 Changement des propriétés d’affichage ou déconseillés

Les caractères suivants peuvent causer des changements dans l’affichage ou dans l’ordre dans lequel les caractères apparaissent lors de leur restitution, ou bien sont déconseillés dans Unicode.

5.9 Caractères d’étiquetage

Les caractères suivants sont utilisés pour étiqueter le texte et sont invisibles.

6. Caractères bidirectionnels

La plupart des caractères sont affichés de gauche à droite, mais certains sont affichés de droite à gauche. Cette caractéristique de Unicode est appelée "texte bidirectionnel", ou "bidi" en abrégé. La norme Unicode comporte un exposé détaillé sur la façon de réordonner l’affichage des glyphes lors du traitement de textes bidirectionnels tels que l’arabe ou l’hébreu. Voir [UAX9] pour des précisions. En particulier, tout le texte en Unicode est mémorisé dans l’ordre logique.

Un profil PEUT choisir d’ignorer le texte bidirectionnel. Cependant, ignorer le texte bidirectionnel peut causer des ambiguïtés à l’affichage. Par exemple, il est assez facile de créer deux chaînes différentes avec les mêmes caractères (mais dans un ordre différent) qui soient affichées correctement de façon identique. Donc, pour éviter la plupart des problèmes avec l’affichage ambigu de texte bidirectionnel, les créateurs de profils devraient considérer avec attention l’inclusion du traitement des caractères bidirectionnels décrite dans la présente section dans leur profil.

Le processus stringprep n’émet jamais à la fois une erreur et une chaîne. Si une erreur est détectée durant la vérification de chaînes bidirectionnelles, seule une erreur est retournée.

[Unicode3.2] définit plusieurs catégories bidirectionnelles ; chaque caractère a une catégorie bidirectionnelle qui lui est allouée. Pour les besoins des exigences ci-dessous, un "caractère RandALCat" est un caractère qui a les catégories bidirectionnelles Unicode "R" ou "AL" ; un "caractère LCat" est un caractère qui a une catégorie bidirectionnelle Unicode de "L". Noter qu’il y a de nombreux caractères qui ne rentrent dans aucune des définitions ci-dessus ; les chiffres latins (de <U+0030> à <U+0039>) en sont des exemples parce qu’ils ont la catégorie bidirectionnelle "EN".

Dans tout profil qui spécifie un traitement de caractère bidirectionnel, les trois exigences suivantes DOIVENT toutes être satisfaites :

1) Les caractères du paragraphe 5.8 DOIVENT être interdites.

2) Si une chaîne contient un caractère RandALCat, la chaîne NE DOIT PAS contenir de caractère LCat.

3) Si une chaîne contient un caractère RandALCat, un caractère RandALCat DOIT être le premier caractère de la chaîne, et un caractère RandALCat DOIT être le dernier caractère de la chaîne.

Noter que l’exigence 3 interdit les chaînes telles que <U+0627><U+0031> ("aleph 1") mais permet des chaînes telles que <U+0627><U+0031><U+0628> ("aleph 1 beh"). [UAX9] décrit très en détail l’ordre d’affichage des chaînes qui contiennent des catégories particulières de caractères dans des séquences spéciales.

Le Tableau D.1 fait la liste des caractères qui appartiennent aux catégories bidirectionnelles "R" et "AL" d’Unicode. Le Tableau D.2 fait la liste de tous les caractères qui appartiennent à la catégorie bidirectionnelle "L" d’Unicode. Ces tableaux sont tirés de [Unicode3.2].

7 Séquences codées non allouées dans les profils Stringprep

La présente section décrit deux différents types de chaînes dans des protocoles typiques où sont utilisées les chaînes internationalisées : "chaînes mémorisées" et "interrogations". Bien sûr, les différents protocoles de l’Internet utilisent les chaînes de façon très différente, aussi ces termes ne peuvent pas être utilisés exactement dans chaque protocole qui a besoin d’utiliser stringprep. En général, les "chaînes mémorisées" sont des chaînes qui sont utilisées dans des identifiants de protocole et des entités nommées, tels que les noms des certificats numériques et les parties de nom de domaines de DNS. Les "interrogations" sont des chaînes qui sont utilisées pour la confrontation avec des chaînes qui sont des identifiants mémorisés, tels que des noms introduits par l’utilisateur pour des autorités de certificat numérique et des recherches de DNS.

Toutes les séquences codées qui ne sont pas allouées dans le répertoire de caractère désigné dans un profil stringprep sont appelées "séquences codées non allouées". Les chaînes mémorisées qui utilisent le profil NE DOIVENT PAS contenir de séquence codée non allouée. Les interrogations pour les chaînes correspondantes PEUVENT contenir des séquences codées non allouées. Noter que c’est la seule partie du présent document où les exigences pour les interrogations diffèrent des exigences pour les chaînes mémorisées.

Utiliser deux politiques différentes là où les séquences codées non allouées peuvent apparaître supprime le besoin de fournir le numéro de version dans les protocoles qui utilisent les profils stringprep. Ceci est très utile car cela simplifie le processus global et n’impose pas un "protocole" pour traiter les versions. On s’attend à ce que la norme ISO/CEI 10646 et les répertoires Unicode soient mis à jour très fréquemment ; au moment de la rédaction du présent document, cela est arrivé approximativement une fois par an. Chaque fois qu’apparaît une nouvelle version d’un répertoire, une nouvelle version d’un profil PEUT être créée. Certains utilisateurs finaux voudront utiliser les nouvelles séquences codées sitôt qu’elles sont définies.

La liste des séquences codées non allouées DOIT être donnée dans un profil, et cette liste DOIT être utilisée par les mises en oeuvre du profil.

L’objectif des exigences de la présente section est d’empêcher les comparaisons entre deux chaînes qui ont toutes deux reçu la permission de contenir des séquences codées non allouées. Lorsque deux chaînes X et Y sont comparées et que la chaîne Y a été préparée d’une façon qui permet les séquences codées non allouées, un résultat négatif de la comparaison n’est pas définitif ; il est possible que les chaînes ne correspondent pas même si elles correspondraient si on utilisait une version plus récente du profil pour Y. Cependant, si X et Y sont toutes deux préparées d’une façon qui permet les séquences codées non allouées, il peut arriver quelque chose de pire : même un résultat positif de la comparaison ne sera pas définitif. Il est possible que les chaînes correspondent alors qu’elles ne correspondraient pas si on avait utilisé une version plus récente du profil (un profil qui interdirait une séquence codée apparaissant à la fois dans X et dans Y).

Du fait que la gestion des versions est traitée dans la présente section, les chaînes mémorisées qui sont incorporées dans des structures qu’on ne peut changer (telles que la partie signée des certificats numériques) NE DOIVENT PAS contenir de séquence codée non allouée.

7.1 Catégories de séquence codée

Chaque séquence codée dans un répertoire désigné par un profil de stringprep peut être catégorisé par la façon dont il agit dans le processus décrit dans les paragraphes précédents de ce document :

AO Séquences codées qui peuvent figurer dans le résultat

MN Séquences codées qui ne peuvent pas figurer dans le résultat parce qu’elles n’apparaissent jamais comme résultat de la transposition ou de la normalisation

D Séquences codées qui ne peuvent pas figurer dans le résultat parce qu’elles sont interdites dans l’étape d’interdiction

U Séquences codées non allouées

Une version ultérieure d’un profil qui fait références à une version plus récente d’un répertoire avec de nouvelles séquences codées aura naturellement certaines séquences codées déplacées de la catégorie U à D, MN, ou AO. Pour la rétro compatibilité, une version ultérieure d’un profil NE DOIT PAS déplacer de séquence codée d’autres catégories. C’est-à-dire que les séquences codées AO, MN, ou D actuelles NE DOIVENT PAS passer à une catégorie différente.

Les chaînes mémorisées NE DOIVENT PAS contenir de séquence codée en dehors de AO pour la dernière version d’un profil. C’est-à-dire qu’il lui est interdit de contenir des séquences codées provenant des catégories MN, D, ou U.

Les applications qui créent des interrogations DOIVENT traiter les séquences codées U comme si elles étaient AO lors de la préparation de l’interrogation à entrer dans le processus décrit par un profil de stringprep. Ces applications PEUVENT facultativement avoir un préprocesseur qui fournit des vérifications plus strictes : traiter les séquences codées non allouées dans les entrées comme des erreurs, ou avertir l’utilisateur sur le fait que la séquence codée est non allouée dans la version d’un profil sur lequel est fondé le logiciel ; un tel choix est une question locale pour le logiciel.

7.2 Raisons des différences entre chaînes mémorisées et interrogations

Des logiciels différents qui utilisent des versions différentes d’un profil stringprep ont besoin d’interopérer avec la compatibilité maximale. Le schéma décrit dans la présente section (les chaînes mémorisées NE DOIVENT PAS contenir des s »quences codées non allouées, les interrrogations PEUVENT inclure des séquences codées non allouées) permet cette compatibilité sans introduire de problème connu de sécurité ou d’interopérabilité.

La liste ci-dessous montre ce qui arrive si une interrogation contient une séquence codée provenant de la catégorie U qui est permise dans une version plus récente d’un profil. L’interrogation correspond à la chaîne qui était prévue, ou ne correspond à aucune chaîne. Dans cette liste, l’interrogation provient d’une application qui utilise la version "oldVersion" d’un profil, la chaîne mémorisée a été créée en utilisant la version "newVersion" du même profil, et la séquence codée X était dans la catégorie U dans oldVersion, et a changé de catégorie, AO, MN, ou D. Il y a trois scénarios possibles :

1. X est alloué à AO -- Dans newVersion, X est dans la catégorie AO. Comme l’application a passé X, elle obtient en retour une correspondance positive avec la chaîne mémorisée. Il y a un cas exceptionnel, où X est une marque combinatoire.

L’ordre des marques combinatoires est normalisé, de sorte que si une autre marque combinatoire Y a une classe combinatoire inférieure à celle de X, XY sera mis dans l’ordre canonique YX. (Les séquences codées non allouées ne sont jamais réordonnées, aussi ceci n’arrive pas dans oldVersion). Si l’interrogation contient YX, elle obtiendra une correspondance positive avec la chaîne mémorisée. Cependant, aucune chaîne ne peut être mémorisée avec XY, aussi une interrogation avec XY recevra une réponse négative à l’essai de correspondance.

2. X est alloué à MN -- Dans newVersion, X est normalisé à la séquence codée "nX" et donc X est maintenant mis dans la catégorie MN. Ceci ne peut exister dans aucune chaîne mémorisée, de sorte que toute interrogation contenant X aura une réponse négative à l’essai de correspondance. Noter, cependant, que si l’interrogation avait contenu la lettre nX, elle aurait eu une correspondance positive.

3. X est alloué à D -- Dans newVersion, X est dans la catégorie D. Ceci ne peut exister dans aucune chaîne mémorisée, de sorte que toute interrogation contenant X recevra une réponse négative à l’essai de correspondance.

Dans aucun des cas l’interrogation n’obtient les données pour une chaîne mémorisée autre que celle faisant réellement l’essai de correspondance.

Les profils sont stables entre les versions dans le sens suivant : si une chaîne S a été préparée en utilisant newVersion, elle ne changera pas si elle est ensuite préparée en utilisant oldVersion.

7.3 Versions d’applications et chaînes mémorisées

Une autre façon de voir que ce système de versions fonctionne est de comparer ce qui arrive lorsque une application utilise une version plus récente ou plus ancienne d’un profil.

Nouvelle application d’interrogation -- Supposons qu’une application qui interroge utilise une version newVersion que la chaîne mémorisée a été créée en utilisant la version oldVersion. Ce cas est simple : il n’y aura pas de caractères dans la chaîne mémorisée qui ne puisse être interrogé par l’application parce que le nouveau profil utilise un surensemble des séquences codées utilisées pour construire la chaîne mémorisée.

Nouvelle chaîne mémorisée -- Supposons qu’une application qui interroge utilise oldVersion et que la chaîne mémorisée a été créée en utilisant un profil qui utilise newVersion. Comme l’application qui interroge a laissé passer des séquences codées non allouées, l’utilisateur peut interroger sur des chaînes mémorisées qui utilisent des séquences codées dans newVersion. Aucune chaîne mémorisée ne peut avoir de séquence codée qui soit non allouée dans newVersion, car c’est illégal. Afin d’obtenir une correspondance, l’application qui interroge doit entrer les séquences codées non allouées dans l’ordre appropriée, et doit utiliser des séquences codées non allouées qui passeront à la fois l’étape de transposition et l’étape de normalisation.

8 Références

8.1 Références normatives

[UAX15] Mark Davis et Martin Duerst. Norme Unicode Annexe n° 15 : Formes de normalisation Unicode, Version 3.2.0. <http://www.unicode.org/unicode/reports/tr15/tr15-22.html>.

[Unicode3.2] The Unicode Consortium. La norme Unicode, Version 3.2.0 est définie par la norme Unicode, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), amendée par la norme Unicode Annexe n° 27 : Unicode 3.1 (http://www.unicode.org/reports/tr27/) et par la norme Unicode Annexe n° 28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).

[RFC2119] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigences", BCP 14, RFC 2119, mars 1997.

8.2 Références informatives

[CharModel] Rapport technique Unicode ;17, Modèle de codage des caractères. <http://www.unicode.org/unicode/reports/tr17/>.

[Glossary] Glossaire Unicode, <http://www.unicode.org/glossary/>.

[ISO10646] ISO/CEI, "Technologies de l’information – Ensemble universel des caractères codées sur plusieurs octets (UCS) - Partie 1 : Architecture et plan multilingue de base", ISO/CEI 10646-1:2000, octobre 2000.

[RFC2434] Narten, T. et H. Alvestrand, "Lignes directrices pour les considérations relatives à l’IANA", BCP 26, RFC 2434, octobre 1998.

[UAX9] The Unicode Consortium. Norme Unicode Annexe n° 9, L’algorithme bidirectionnel, <http://www.unicode.org/unicode/reports/tr9/>.

[UTR21] Mark Davis. Transpositions de casse. Rapport technique Unicode n° 21.<http://www.unicode.org/unicode/reports/tr21/>.

9 Considérations sur la sécurité

Stringprep est utilisé avec les caractères Unicode. Des considérations de sécurité sont spécifiques de stringprep, et d’autres sont génériques de l’utilisation de Unicode.

9.1 Considérations de sécurité spécifiques de stringprep

Les répertoires Unicode et ISO/CEI 10646 ont de nombreux caractères qui paraissent semblables. Dans de nombreux cas, les utilisateurs des protocoles de sécurité pourraient faire une comparaison visuelle, comme lors de la comparaison des noms des tiers de confiance. Comme il est impossible de transposer des caractères qui ont la même apparence sans tout un contexte dont fait partie la connaissance de la police de caractère utilisée, stringprep ne fait rien pour transposer les caractères qui paraissent semblables, ni pour interdire certains caractères à cause de leur ressemblance avec d’autres. Les utilisateurs d’applications peuvent aider à lever les ambiguïtés sur certains caractères qui ressemblent à d’autres en montrant à l’utilisateur lorsqu’une chaîne change selon les écritures.

La plupart des profils de stringprep peuvent causer des changements dans les chaînes qui sont des entrées à stringprep. A cause de cela, les protocoles qui ont des ensembles des caractères ou des séquences non admises DOIVENT vérifier les caractères ou séquences non admises après le traitement stringprep.

Le présent document ne rend pas obligatoire la vérification des caractères bidirectionnels de la section 6. Si les exigences de la section 6 ne sont pas utilisées dans un profil de stringprep, il est aisé de créer de nombreuses chaînes dont les caractères sont dans un ordre différent mais sont affichés de la même façon. Ceci peut causer une confusion de l’utilisateur avec des implications sur la sécurité similaire à celle des caractères qui semblent identiques, comme décrit ci-dessus.

Stringprep ne fait rien pour assurer que des algorithmes de traduction de caractères de non Unicode à Unicode produisent le même résultat dans toutes les mises en œuvre.

Certaines séquences codées d’Unicode sont invisibles. Les protocoles qui permettent ces caractères (c’est-à-dire, qui ne les transposent pas ou ne les interdisent pas dans stringprep) peuvent causer la confusion des utilisateurs lorsque deux chaînes qui semblent identiques ne correspondent pas.

9.2 Considérations de sécurité génériques d’Unicode

L’utilisation des caractères Unicode force explicitement les applications à utiliser des caractères multi octets. La conversion d’une application à partir d’une utilisation de caractères mono octet en une utilisation de caractères multi octets doit être faite avec de grandes précautions, en particulier dans une application qui vérifie les valeurs des caractères ou trie les caractères.

Les protocoles qui utilisent stringprep utilisent habituellement aussi des codages d’Unicode, tels que UTF-8 ou UTF-16. Certaines applications qui utilisent ces codages sont connues pour ne pas vérifier les séquences illégales ou mal formées dans les codages, et donc pour ne pas détecter les séquences d’octets qui auraient été détectées si elles utilisaient juste ASCII. Par exemple, en UTF-8, la séquence d’octet "0xC0 0xAB" est une formation illégale de U+002B (signe plus). Tous les programmes devraient rejeter une chaîne qui est une séquence d’octets illégale ou mal formée pour le codage utilisé.

La normalisation et la conversion Unicode entre les codages Unicode peuvent causer la croissance ou la réduction des chaînes. Les programmes qui utilisent des mémoires tampon de taille fixe, ou qui font l’hypothèse que les mémoires tampon seront toujours supérieures ou inférieure à une taille particulières, ont des chances de tomber dans des modes non sécurisés lorsqu’ils utilisent la normalisation Unicode ou des conversions de codage.

Le développement d’une liste exhaustive des menaces pour la sécurité et des considérations sur l’utilisation des versions actuelles et futures d’Unicode est en-dehors du domaine d’application du présent document.

10 Considérations relatives à l’IANA

Les profils stringprep DOIVENT avoir le consensus de l’IETF tel que décrit dans la [RFC2434]. Chaque profil DOIT être revu par l’IESG avant son enregistrement. L’IESG PEUT changer un profil avant l’enregistrement.

L’IANA a établi un registre des profils stringprep. Ce registre est un seul fichier de texte qui fait la liste des profils connus. Chaque entrée dans le registre a trois champs :

- Nom du profil
- RFC dans laquelle le profil est défini
- Indication de la dernière version du profil ou non.

Chaque version d’un profil restera pour toujours dans le registre. C’est à dire que si une nouvelle version d’un profil se substitue à une ancienne version, les deux versions continuent de figurer dans la liste du registre, mais l’indicateur de la version en cours passera de la plus ancienne version à la plus récente.

Il serait probablement dommageable que prolifèrent un grand nombre de profils de stringprep. L’IESG peut donc rejeter des propositions de nouveaux profils et suggérer à la place que des protocoles réutilisent des profils existants.

11 Remerciements

De nombreuses personnes du groupe de travail IDN de l’IETF et du comité technique Unicode ont contribué par leurs idées à la première version du présent document. Mark Davis et Patrik Faltstrom ont particulièrement aidé par certaines de leurs idées, comme la description des problèmes de version.

L’équipe de conception nameprep de IDN a fait de nombreux changements utiles au premier document. Cette équipe et ses conseillers comprenn ent :

Des améliorations significatives supplémentaires ont été proposées par :

A Répertoires Unicode

Ce qui suit est le seul répertoire couvert par le présent document :

Unicode 3.2, comme défini dans [Unicode3.2].

A.1 Séquences codées non allouées dans Unicode 3.2

Tableau A.1

B Tableaux de transposition

Ci après figure le tableau de transposition de la section 3. Le tableau a trois colonnes :

- la séquence codée d’où est tirée la transposition
- les zéro, une ou plusieurs séquences codées résultant de la transposition
- la raison de la transposition

B.1 Habituellement transposé à rien

Tableau B.1

B.2 Transposition pour le repli de casse utilisé avec NFKC

Tableau B.2