Groupe de travail Réseau	K. Zeilenga, éditeur	
Request for Comments : 3698	OpenLDAP Foundation	
RFC mise à jour : 2798	février 2004	
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle	

Protocole léger d’accès à un répertoire (LDAP) : 
règles de correspondance supplémentaires

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2004).

Résumé
Le présent document fournit une collection de règles de correspondance à utiliser avec le protocole léger d’accès à un répertoire (LDAP, Lightweight Directory Access Protocol). Comme ces règles de correspondance sont une simple adaptation des règles de correspondance à utiliser avec l’annuaire X.500, la plupart sont déjà largement utilisées.

Table des Matières
1. Fondements et utilisation prévue	1
2. Règles de correspondance	2
2.1 booleanMatch	2
2.2 caseExactMatch	2
2.3 caseExactOrderingMatch	2
2.4 caseExactSubstringsMatch	2
2.5 caseIgnoreListSubstringsMatch	2
2.6 directoryStringFirstComponentMatch	3
2.7 integerOrderingMatch	3
2.8 keywordMatch	3
2.9 numericStringOrderingMatch	3
2.10 octetStringOrderingMatch	3
2.11 storedPrefixMatch	4
2.12 wordMatch	4
3. Considérations sur la sécurité	4
4. Considérations relatives à l’IANA	4
5. Remerciements	5
6. Références	5
6.1 Références normatives	5
6.2. Références Informatives	5
7. Adresse de l’auteur	5
8. Déclaration complète de droits de reproduction	5
Déclaration de propriété intellectuelle	6

1.	Fondements et utilisation prévue

Le présent document adapte les règles de correspondance supplémentaires de l’annuaire X.500 [X.500], [X.520] à utiliser avec le protocole léger d’accès à un répertoire (LDAP) [RFC3377]. La plupart de ces règles sont largement utilisées aujourd’hui sur l’Internet, par exemple à l’appui des schémas LDAP inetOrgPerson [RFC2798] et du modèle d’informations de cœur de politique [RFC3703]. Les règles sont applicables à de nombreuses autres applications.

Le présent document se substitue aux descriptions de règles de correspondance informatives fournies dans la RFC2798 qui sont mainteant fournies dans le présent document. Précisément, la section 2 du présent document remplace le paragraphe 9.3.3 de la RFC2798.

Les définitions de schémas sont fournies en utilisant les formats de description LDAP de la [RFC2252]. Les définitions fournies ici sont formatées (retour à la ligne) pour en faciliter la lecture.

2.	Règles de correspondance
2.1	booleanMatch

La règle booleanMatch (correspondance booléenne) compare en égalité une assertion de valeur booléene avec une valeur d’attribut de syntaxe BOOLEAN. La règle retourne TRUE (VRAI) si et seulement si les valeurs sont les mêmes, c’est-à-dire, toutes deux sont VRAI ou toutes les deux sont FAUX. (Source: X.520).

( 2.5.13.13 NAME 'booleanMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )

La syntaxe BOOLEAN (1.3.6.1.4.1.1466.115.121.1.7) est décrite dans la [RFC2252].

2.2	caseExactMatch

La règle caseExactMatch (correspondance exacte de casse) compare en égalité la valeur affirmée avec une valeur d’attribut de synataxe DirectoryString (chaîne de répertoire). La règle est identique à la règle caseIgnoreMatch [RFC2252] excepté que la casse n’est pas ignorée (Source: X.520).

( 2.5.13.5 NAME 'caseExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) est décrite dans la [RFC2252].

2.3	caseExactOrderingMatch

La règle caseExactOrderingMatch (correspondance d’ordre à casse exacte) compare l’ordre de collation de la chaîne de l’assertion avec une valeur d’attribut de syntaxe DirectoryString. La règle est identique à la règle caseIgnoreOrderingMatch [RFC2252] excepté que les lettres ne sont pas repliées sur une casse spécifique. (Source : X.520).

( 2.5.13.6 NAME 'caseExactOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) est décrite dans la [RFC2252].

2.4	caseExactSubstringsMatch

La règle caseExactSubstringsMatch (correspondance de sous chaînes à casse exacte) détermine si la ou les valeurs affirmées sont des sous chaînes d’une valeur d’attribut de syntace DirectoryString. La règle est identique à la règle caseIgnoreSubstringsMatch [RFC2252] excepté que la casse n’est pas ignorée. (Source: X.520).

( 2.5.13.7 NAME 'caseExactSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

La syntaxe SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) est décrite dans la [RFC2252].

2.5	caseIgnoreListSubstringsMatch

La règle caseIgnoreListSubstringMatch (correspondance de sous chaîne de liste enignorant la casse) compare l’assertion de sous chaîne à une valeur d’attribut qui est une séquence de DirectoryStrings, mais où la casse (majuscules ou minuscules) n’est pas significative pour les besoins de la comparaison. La valeur de l’assertion correspond à une valeur mémorisée si et seulement si la valeur de l’assertion correspond à la chaîne formée en enchaînant les chaînes de la valeur mémorisée. Cette correspondance est faite conformément à la règle caseIgnoreSubstringsMatch [RFC2252] ; cependant, aucune des valeurs initiale, courante, ou finale de la valeur de l’assertion n’est considérée correspondre à une sous chaîne de l’enchaînement de chaînes qui s’étend sur plus des chaînes de la valeur mémorisée. (Source : X.520).

( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

La syntaxe SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) est décrite dans la [RFC2252].

2.6	directoryStringFirstComponentMatch

La règle directoryStringFirstComponentMatch (correspondance de premier composant de chaîne de répertoire) compare en égalité l’assertion de valeur de DirectoryString avec une valeur d’attribut de type SEQUENCE dont le premier composant est obligatoire et de type DirectoryString. La règle retourne VRAI si et seulement si la valeur de l’attribut a un premier composant dont la valeur correspond à l’assertion de DirectoryString en utilisant les règles de caseIgnoreMatch [RFC2252]. Une valeur de la syntaxe de l’assertion est déduite d’une valeur de la syntaxe de l’attribut en utilisant la valeur du premier composant de la SEQUENCE. (Source : X.520).

( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) est décrite dans la [RFC2252].
2.7	integerOrderingMatch

La règle integerOrderingMatch (correspondance d’ordre d’entier) compare l’ordre de l’entier affirmé avec une valeur d’attribut de syntaxe INTEGER (entier). La règle retourne VRAI si la valeur de l’attribut est inférieure à la valeur affirmée. (Source : X.520).

( 2.5.13.15 NAME 'integerOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

La syntaxe INTEGER (1.3.6.1.4.1.1466.115.121.1.27) est décrite dans la [RFC2252].

2.8	keywordMatch

La règle keywordMatch (correspondance de mot-clé) compare la chaîne de l’assertion avec des mots-clés dans une valeur d’attribut de syntaxe DirectoryString. La règle retourne VRAI si et seulement si la valeur affirmée correspond à tout mot-clé dans la valeur d’attribut. L’identification des mots-clés dans une valeur d’attribut et l’exactitude de la correspondance sont toutes deux spécifiques de la mise en œuvre. (Source: X.520).

( 2.5.13.33 NAME 'keywordMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) est décrite dans la [RFC2252].

2.9	numericStringOrderingMatch

La règle numericStringOrderingMatch (correspondance d’ordre de chaîne numérique) compare l’ordre de collation de la chaîne de l’assertion avec une valeur d’attribut de syntaxe NumericString (chaîne numérique). La règle est identique à la règle caseIgnoreOrderingMatch [RFC2252] excepté que tous les caractères d’espace sont sautés durant la comparaison (la casse est sans objet car les caractères sont numériques). (Source : X.520).

( 2.5.13.9 NAME 'numericStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

La syntaxe de NumericString (1.3.6.1.4.1.1466.115.121.1.36) est décrite dans la [RFC2252].

2.10	octetStringOrderingMatch

La règle octetStringOrderingMatch compare l’ordre de collation de la chaîne d’octets affirmée avec une valeur d’attribut de syntaxe CHAINE D’OCTETS. La règle compare les chaînes d’octets du premier au dernier octet, et du bit de poids fort au bit de moindre poids dans l’octet. La première occurrence d’un bit différent détermine l’ordre des chaînes. Un bit zéro précède un bit un. Si les chaînes sont identiques mais contiennent un nombre différent d’octets, la chaîne la plus courte précède la chaîne plus longue. (Source : X.520)

( 2.5.13.18 NAME 'octetStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

La syntaxe OCTET STRING (1.3.6.1.4.1.1466.115.121.1.40) est décrite dans la [RFC2252].

2.11	storedPrefixMatch

La règle storedPrefixMatch détermine si une valeur d’attribut, dont la syntaxe est DirectoryString est un préfixe (c’est-à-dire, une sous chaîne initiale) de la valeur affirmée, sans égard à la casse (majuscules ou minuscules) des chaînes. La règle retourne VRAI si et seulement si la valeur de l’attribut est une sous chaîne initiale de la valeur affirmée avec les caractères correspondants identiques excepté éventuellement à l’égard de la casse. (Source : X.520)

( 2.5.13.41 NAME 'storedPrefixMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Note : Cette règle peut être utilisée, par exemple, pour comparer des valeurs dans le répertoire des codes de zones téléphoniques avec une valeur qui signifie un numéro de téléphone.

La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) est décrite dans la [RFC2252].

2.12	wordMatch

La règle wordMatch compare la chaîne affirmée avec les mots d’une valeur d’attribut de syntaxe DirectoryString. La règle retourne VRAI si et seulement si le mot affirmé correspond à n’importe quel mot dans la valeur d’attribut. La correspondance de mots individuels est comme pour la règle de correspondance caseIgnoreMatch [RFC2252]. La définition précise de "mot" est spécifique de la mise en œuvre. (Source : X.520)

( 2.5.13.32 NAME 'wordMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

La syntaxe DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) est décrite dans la [RFC2252].

3.	Considérations sur la sécurité

Les considérations générales de sécurité de LDAP [RFC3377] sont applicables à l’utilisation du présent schéma. Des considérations supplémentaires sont notées ci-dessus lorsque approprié.

4.	Considérations relatives à l’IANA

L’autorité d’allocation des numéros de l’Internet (IANA) a mis à jour le registre des descripteurs de LDAP [RFC3383] comme indiqué dans le gabarit suivant :

Objet : Demande de mise à jour d’enregistrement de descripteur LDAP
Descripteur (nom abrégé) : voir le commentaire
Identifiant d’objet : voir les commentaires
Adresse personnelle & de messagerie à contacter pour plus d’informations : Kurt Zeilenga <kurt@OpenLDAP.org>
Usage : voir les commentaires
Spécification : RFC 3698
Auteur/Contrôleur des changements : IESG
Commentaires : Les descripteurs suivants ont été ajoutés :
Nom	Type	OID
booleanMatch	M	2.5.13.13
caseExactMatch	M	2.5.13.5
caseExactOrderingMatch	M	2.5.13.6
caseExactSubstringsMatch	M	2.5.13.7
caseIgnoreListSubstringsMatch	M	2.5.13.12
directoryStringFirstComponentMatch	M	2.5.13.31
integerOrderingMatch	M	2.5.13.15
keywordMatch	M	2.5.13.33
numericStringOrderingMatch	M	2.5.13.9
octetStringOrderingMatch	M	2.5.13.18
storedPrefixMatch	M	2.5.13.41
wordMatch	M	2.5.13.32

où le type M est Règle de correspondance.

Le présent document ne fait aucune nouvelle allocation d’OID. Il associe seulement les descriptions de règles de correspondance LDAP aux règles de de correspondance X.500 existantes.

5.	Remerciements

Le présent document fait des emprunts à [X.520], une Recommandation de l’UIT-T.

6.	Références
6.1	Références normatives

[RFC2252]	M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Protocole léger d’accès à un répertoire (v3) : Définitions de syntaxe d'attribut", décembre 1997. (Obsolète, voir RFC4510, RFC4517, RFC4523, RFC4512) (MàJ par RFC3377) (P.S.)

[RFC3377]	J. Hodges, R. Morgan, "Protocole léger d'accès à un répertoire (v3) : Spécification technique", septembre 2002. Obsolète, voir RFC4510) (P.S.)

6.2.	Références Informatives

[RFC2798]	M. Smith, "Définition de la classe d’objet LDAP inetOrgPerson", avril 2000.

[RFC3383]	K. Zeilenga, "Autorité d'allocation des numéros de l'Internet (IANA) : Considérations sur le protocole léger d'accès à un répertoire (LDAP)", septembre 2002. (Obsolète, voir RFC4520)

[RFC3703]	J. Strassner et autres, "Schéma de cœur de politique du protocole léger d'accès à un répertoire (LDAP)", février 2004. (MàJ par RFC4104) (P.S.)

[X.500]	Recommandation UIT-T X.500 (1993) | ISO/CEI 9594-1:1994, "Technologies de l’Information - Interconnexion des systèmes ouverts - L’annuaire : Vue d’ensemble des concepts, modèles et services".

[X.520]	Recommandation UIT-T X.520 (1993) | ISO/CEI 9594-6:1994, "Technologies de l’Information - Interconnexion des systèmes ouverts - L’annuaire : Types d’attribut choisis".

7.	Adresse de l’auteur

Kurt D. Zeilenga
OpenLDAP Foundation

mél : Kurt@OpenLDAP.org 

8.	Déclaration complète de droits de reproduction

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

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.
Déclaration de propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.