Aller au contenu principal

Annexe A. Modifications

Cette annexe n’est pas normative.

Le présent document constitue une réécriture presque complète de parties des RFC 2251, RFC 2252 et RFC 2256, destinée à améliorer la clarté générale de la spécification technique. Cette annexe résume les modifications substantielles apportées aux parties incorporées ici. Voir [RFC4510], [RFC4511], [RFC4517] et [RFC4519] pour les autres parties.

A.1. Modifications de la RFC 2251​

Le présent document incorpore les sections 3.2 et 3.4, ainsi que des parties des sections 4 et 6 de la RFC 2251, comme résumé ci-dessous.

A.1.1. Section 3.2 de la RFC 2251​

Cette section présentait brièvement le modèle de données X.500 utilisé par LDAP. L’ancienne spécification s’appuyait sur [X.501] sans expliquer clairement l’adaptation des modèles X.500 à LDAP. Le présent document les décrit plus précisément, surtout là où une adaptation est nécessaire.

La section 3.2.1 décrivait un attribut comme « un type avec une ou plusieurs valeurs associées ». Dans LDAP, il vaut mieux le décrire comme une description d’attribut, c’est-à-dire un type avec zéro ou plusieurs options, et une ou plusieurs valeurs associées.

La section 3.2.2 exigeait les attributs objectClasses et attributeTypes dans les sous-entrées de sous-schéma, alors que X.500(93) les considère facultatifs. Les mises en œuvre prenant en charge ces mécanismes les fournissent généralement tous deux, mais l’interopérabilité n’exige pas absolument que tous les serveurs le fassent. Cette obligation a été supprimée pour s’aligner sur X.500(93). Il a aussi été précisé que le sous-schéma régissant une entrée s’obtient en lisant la (sous-)entrée désignée par son attribut 'subschemaSubentry'.

A.1.2. Section 3.4 de la RFC 2251​

Cette section fournissait les « exigences relatives aux données propres au serveur ». Ce contenu modifié a été intégré à la section 5.1.

Modifications :

  • préciser que les attributs de la DSE racine sont soumis à « d’autres restrictions » en plus des contrôles d’accès ;
  • préciser que seules les demandes étendues reconnues doivent être énumérées dans 'supportedExtension' ;
  • préciser que seuls les contrôles de demande reconnus doivent être énumérés dans 'supportedControl' ;
  • préciser que les attributs de la DSE racine sont opérationnels et ne sont renvoyés que s’ils sont demandés par leur nom ;
  • préciser que tous ne sont pas modifiables par l’utilisateur ;
  • supprimer le texte incohérent relatif à 'subschemaSubentry' dans la DSE racine. L’ancienne spécification indiquait qu’il désignait les « entrées (ou sous-entrées) de sous-schéma connues de ce serveur », ce qui contredit son usage prévu et sa définition formelle comme attribut monovalué [X.501]. Une simple liste, éventuellement incomplète, est en outre peu utile. La section 5.1 précise qu’il désigne le sous-schéma régissant la DSE racine. Le mécanisme général reste disponible (voir la section 4.4).

A.1.3. Section 4 de la RFC 2251​

Les parties détaillant le modèle d’informations LDAP incorporées sont :

  • la restriction des valeurs distinctives aux attributs dont la description ne comporte aucune option (section 4.1.3) ;
  • les aspects du modèle de données des types d’attribut (4.1.4), descriptions d’attribut (4.1.5), attributs (4.1.8) et identifiants de règle de correspondance (4.1.9) ;
  • les exigences de schéma utilisateur (4.1.6, 4.5.1 et 4.7).

Les clarifications comprennent :

  • la relation de sous-type et les AttributeDescriptions avec options.

A.1.4. Section 6 de la RFC 2251​

La section 6.1 et le deuxième paragraphe de la section 6.2 ont été incorporés.

A.2. Modifications de la RFC 2252​

Le présent document incorpore les sections 4, 5 et 7 de la RFC 2252.

A.2.1. Section 4 de la RFC 2252​

La spécification utilise désormais l’Augmented BNF [RFC4234]. La représentation textuelle d’un OBJECT IDENTIFIER a été resserrée pour interdire les zéros initiaux comme indiqué dans la RFC 2252.

La syntaxe interdit désormais le point-virgule (U+003B), conformément à sa définition : « descr est la représentation syntaxique d’un descripteur d’objet, composé de lettres et de chiffres et commençant par une lettre ». L’affirmation selon laquelle « une AttributeDescription peut servir de valeur dans une partie NAME d’une AttributeTypeDescription » a aussi été supprimée, la RFC 2252 ne définissant pas la sémantique des options d’attribut dans les champs NAME.

La RFC 2252 indiquait que la forme de DEVRAIT (SHOULD) être préférée à , mais la forme peut être ambiguë. Cette exigence a été remplacée en section 1.4 par l’indication que est généralement préférée, mais que doit être utilisée lorsqu’aucune non ambiguë n’existe. La section 6.2 (« Noms courts ») développe aussi ces questions.

L’ABNF des chaînes entre guillemets (qdstring) a été mise à jour pour le mécanisme d’échappement de la section 4.3 de la RFC 2252.

A.2.2. Section 5 de la RFC 2252​

Les définitions d’attributs opérationnels de cette section ont été incorporées.

'namingContexts' a été précisé : un DSA de premier niveau devrait publier, outre les autres valeurs, "" pour indiquer la racine du DIT.

'altServer' peut contenir n’importe quel URI.

Pour 'supportedExtension', un serveur ne doit énumérer que les OBJECT IDENTIFIER associés aux demandes étendues qu’il reconnaît.

Pour 'supportedControl', il ne doit énumérer que les OBJECT IDENTIFIER associés aux contrôles de demande reconnus.

Les descriptions de 'structuralObjectClass' et 'governingStructureRule' ont été ajoutées.

La définition de 'subschemaSubentry' a été corrigée afin d’ordonner correctement SINGLE-VALUE et NO-USER-MODIFICATION.

A.2.3. Section 7 de la RFC 2252​

Cette section définissait les classes 'subschema' et 'extensibleObject', intégrées respectivement aux sections 4.2 et 4.3. Son exigence de mise en œuvre des classes d’objet a été incorporée à la section 7.

L’interaction de 'extensibleObject' avec les attributs interdits a été précisée.

A.3. Modifications de la RFC 2256​

Le présent document incorpore les sections 5.1, 5.2, 7.1 et 7.2 de la RFC 2256.

La définition de 'objectClass' de la section 5.1 a été intégrée à la section 2.4.1. « Une des valeurs est soit 'top', soit 'alias' » a été remplacé par l’affirmation qu’une valeur est 'top', car les entrées appartenant à 'alias' appartiennent aussi à 'top'.

La définition de 'aliasedObjectName' de la section 5.2 a été intégrée à la section 2.6.2.

La définition de la classe 'top' de la section 7.1 a été intégrée à la section 2.4.1.

La définition de la classe 'alias' de la section 7.2 a été intégrée à la section 2.6.1.

A.4. Modifications de la RFC 3674​

Le présent document n’apporte aucune modification substantielle à la spécification technique de 'supportedFeatures' donnée dans la RFC 3674.