\documentclass{report}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage{geometry}
\geometry{top=15mm, bottom=15mm, left=1cm, right=1cm}
\usepackage[french]{babel}
\usepackage{pslatex}
\usepackage[colorlinks=true,urlcolor=black]{hyperref}
\usepackage{graphicx}
\usepackage{fancyhdr}
\pagestyle{fancy}
\renewcommand{\footrulewidth}{0.4pt}
\fancyfoot[L]{Uubu.fr}
\fancyfoot[R]{mer. nov. 6 15:15:04 CET 2013}
\lfoot{\Large \textit{Uubu.fr}}
\hypersetup{pdfinfo={
Title={rfc3296},
Author={Sylvain Girod},
Creator={Bash script from uubu.fr's format version 1},
Producer={Bash script and PDFLaTeX},
Subject={Named Subordinate References},
CreationDate={D:20131106151504},
ModDate={D:20131106151504},
Keywords={LDAP;Lightweight Directory Access Protocol}
}}
\begin{document}
 
\begin{center}
{\Huge rfc3296 }
\end{center}
\vspace{1cm}
 
\begin{flushleft}
 
{\large Named Subordinate References}
 
\vspace{10mm}
 
\vspace{1cm}{\huge objectClass }
 
\
 
\hspace{1mm}  Détail les éléments du schéma et du protocole pour représenter et gérer les références subordonnées nommées dans LDAP. un objet référant maintient une ou plusieurs URI contenus dans des valeurs de type d'attributs de référence et sont utilisé pour générer des références. Un contrôle, \textbf{ManageDsaIT}, est définis pour permettre de manipuler ces référants et autres objets spéciaux comme des objets spéciaux.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge ObjectClass referral }
 
\
 
\hspace{1mm} Cette classe d'objet devrait être utilisé en conjonction avec la classe d'objet extensibleObject pour supporter les attributs de nommage utilisé dans le DN de l'entrée. Les objets référrant sont normalement instanciés aux DSE immédiatement subordonnés au entrées dans un contexte de nommage maintenu par le DSA. \\
\hspace{1mm} \textbf{( 2.16.840.1.113730.3.2.6 NAME 'referral' DESC 'named subordinate reference object' STRUCTURAL MUST ref )} \\
 
\vspace{1cm}{\huge Type d'attribut ref }
 
\
 
\hspace{1mm} Ce type d'attribut a une syntaxe directoryString sensible à la casse et multi-valué. Les valeurs placées dans cet attribut doivent être conforme à la spécification donnée pour l'attribut labeledURI. Si cet attribut réfère à un serveur LDAP, il doit être sous la forme d'URL LDAP. Cette URL LDAP ne devrait pas contenir de scope, filtre, liste d'attribut, ou extension et devrait contenir un DN on-vide. \\
\hspace{1mm} \textbf{( 2.16.840.1.113730.3.1.34 NAME 'ref' DESC 'named reference - a labeledURI' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE distributedOperation )} \\
 
\vspace{1cm}{\huge Contrôle ManageDsaIT }
 
\
 
\hspace{1mm}  Un client peut fournir le contrôle \textbf{ManageDsaIT} avec une opération pour indiquer que l'opération est de gérer des objets dans le DIT. Ce contrôle indique que les entrée spécifique sont traitées comme des entrées normales.
\vspace{5mm} \\
\hspace{1mm}  Le \textbf{controlType} vaut \textbf{2.16.840.1.113730.3.4.2} et \textbf{controlValue} est absent.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Références des subordonnés nommés }
 
\
 
\hspace{1mm}  Une référence subordonnée nommée est construite en instançiant un objet referral dans le serveur dé-référençant avec les les valeurs de l'attribut ref. qui pointent vers le subtree correspondant maintenu dans le serveur référencié. En général, le nom de l'objet referral est le même que l'objet référencé et cet objet référencé est un préfixe de contexte.
\vspace{5mm} \\
 
 
\hspace{1mm}  Si le serveur A maintient \textbf{DC=example,dc=net} et le serveur B maintient \textbf{dc=sub,dc=example,dc=net}, le serveur A peut contenir un objet referral nommé \textbf{dc=sub,dc=example,dc=net} qui contient un attribut ref avec la valeur \textbf{ldap ://B/dc=sub,dc=example,dc=net}
\vspace{5mm} \\
 
 
{\ttfamily
dn: DC=sub,DC=example,DC=net\\ dc: sub\\ ref: ldap://B/DC=sub,DC=example,DC=net\\ objectClass: referral\\ objectClass: extensibleObject\\
}
\vspace{8mm}
 
\hspace{1mm}  Typiquement, le DN de l'objet referral et le DN de l'objet sur le serveur référencé sont les même. Si l'attribut ref a plusieurs valeurs, tous les DN contenus dans les URL LDAP devraient être équivalent. Les administrateurs devraient éviter de configurer des boucles en utilisant des référants. Les références nommées doivent être traitées comme des entrées normales si la requête inclus le contrôle manageDsaIT.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge scénario }
 
\
 
\hspace{1mm}  Les sections suivante contiennent des spécifications sur l'utilisation des referral dans différent scénarios. Il est à noter que, dans ce document, une opération de recherche est conceptuellement divisée en 2 phases distincts : 1. trouver l'objet de base où la recherche commence, et 2. effectuer la recherche.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Exemple de configuration }
 
\
 
\hspace{1mm} Par exemple, supposons que le serveur contacté (hosta) maintient l'entrée O=MNN,C=WW" et l'entrée "CN=manager,O=MNN,C=WW" et les objets referral suivants:
 
{\ttfamily
dn: OU=People,O=MNN,C=WW\\ ou: People\\ ref: ldap://hostb/OU=People,O=MNN,C=US\\ ref: ldap://hostc/OU=People,O=MNN,C=US\\ objectClass: referral\\ objectClass: extensibleObject\\ dn: OU=Roles,O=MNN,C=WW\\ ou: Roles\\ ref: ldap://hostd/OU=Roles,O=MNN,C=WW\\ objectClass: referral\\ objectClass: extensibleObject\\
}
\vspace{8mm}
 
\hspace{1mm}  Le premier referral indique que \textbf{hostb} et \textbf{hostc} maintiennent \textbf{"OU=People,O=MNN,C=WW"}. Le second indique que \textbf{hostd} maintient \textbf{"OU=Roles,O=MNN,C=WW"}.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Considérations de l'objet cible }
 
\
 
\hspace{1mm}  Cette section détail la manipulation des referral pour les opérations add, compare, delete, modify et modrdn. Si le client demande une de ces opérations, il y'a 4 cas que le serveur doit gérer.
\vspace{5mm} \\
 
 
\hspace{1mm}  \textbf{cas 1:} l'objet cible n'est pas manipulé parle serveur et n'est pas dans ou subordonné à un contexte de nommage ni subordonné à un referral maintenu par le serveur.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le serveur devrait traiter la requête normallement comme approprié pour une base non-exsitante qui n'est pas dans un contexte de nommage du serveur. (retourne générallement noSuchObject ou un referral).
\vspace{5mm} \\
 
 
\hspace{1mm}  \textbf{cas 2:} L'objet cible est maintenu par le serveur et est un objet referral.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le serveur devrait retourner l'URI contenu dans ref, modifié comme suit.
\vspace{5mm} \\
 
 
\hspace{1mm} exemple: Si le client requête une opération modify pour l'objet cible "OU=People,O=MNN,C=WW", le serveur va retourner:
 
{\ttfamily
ModifyResponse (referral) \{\\ \hspace{2mm}ldap ://hostb/OU=People,O=MNN,C=WW\\ \hspace{2mm}ldap ://hostc/OU=People,O=MNN,C=WW\\ \}\\
}
\vspace{8mm}
 
\hspace{1mm}  \textbf{cas 3:} L'objet cible n'est pas maintenu par le serveur, mais le contexte de nommage le plus proche ne contient pas de referral.
\vspace{5mm} \\
 
 
\hspace{1mm}  Si le contexte de nommage le plus proche ne contient pas de referral auquel l'objet cible est subordonné, le serveur devrait traiter la requête de manière appropriée (généralement retourne noSuchObject)
\vspace{5mm} \\
 
 
\hspace{1mm}  \textbf{cas 4:} L'objet cible n'est pas maintenu par le serveur, mais le contexte de nommage le plusproche contient un referral.
\vspace{5mm} \\
 
 
\hspace{1mm}  Si le client demande une opération pour laquelle l'objet cible n'est pas maintenu par le serveur et que le contexte de nommage le plus proche contient un referral, le serveur devrait retourner une réponse referral contruite avec la portion URI de la valeur ref.
\vspace{5mm} \\
 
 
\hspace{1mm} exemple: Si le client fournir une opération add où l'objet cible a un DN de "CN=Manager,OU=Roles,O=MNN,C=WW", le serveur va retourner:
 
{\ttfamily
AddResponse (referral) \{\\ \hspace{2mm}ldap ://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"\\ \}\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Considérations de l'objet de base }
 
\
 
\hspace{1mm}  Cette section détail la manipulation des referral pour le traitement de l'objet de base dans les opérations de recherche, il y'a 4 cas.
\vspace{5mm} \\
 
 
\hspace{1mm}  Dans les cas où l'URI retourné est une URL LDAP, le serveur doit fournir un scope explicite avant de le retourner. En plus, la partie DN doit être modifiée de sorte qu'il réfère à la cible appropriée dans le serveur référencé.
\vspace{5mm} \\
 
 
\hspace{1mm}  Si le dé-référencement d'alias est nécessaire pour trouver l'objet referral, la partie DN de l'URI doit être remplacée avec le DN de base comme modifié par le dé-référencement d'alias de sorte que l'URL réfère au nouvel objet cible.
\vspace{5mm} \\
 
 
\hspace{1mm}  \textbf{cas 1:} L'objet de base n'est pas maintenu par le serveur et n'est pas dans ou subordonné à un contexte de nommage maintenu par le serveur.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le serveur devrait traiter la requête normalement comme approprié pour une base non-existante qui n'est pas dans un contexte de nommage du serveur (généralement retourne un referral supérieur ou noSuchObject).
\vspace{5mm} \\
 
 
\hspace{1mm}  \textbf{cas 2:} L'objet de base est maintenu par le serveur et est un objet referral.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le serveur devrait retourner la valeur URI contenu dans ref, modifié comme indiqué plus haut.
\vspace{5mm} \\
 
 
\hspace{1mm} exemple: Si le client requête un recherche subtree avec l'objet de base "OU=Roles,O=MNN,C=WW", le serveur va retourner:
 
{\ttfamily
SearchResultDone (referral) \{\\ \hspace{2mm}ldap ://hostd/OU=Roles,O=MNN,C=WW??sub\\ \}\\
}
\vspace{8mm}
 
\hspace{1mm}  \textbf{cas 3:} L'objet de base n'est pas maintenu par le serveur, mais le contexte de nommage le plus proche ne contient pas de referral dont l'objet de base est subordonné. Le serveur devrait retourner noSuchObject
\vspace{5mm} \\
 
 
\hspace{1mm}  \textbf{cas 4:} L'objet de base n'est pas maintenu par le serveur, mais le contexte de nommage le plus proche contient un objet referral dont l'objet de base est subordonné. Le serveur devrait retourner une réponse referral qui est construite depuis la portion URI de ref.
\vspace{5mm} \\
 
 
\hspace{1mm} exemple: Si le client requête un search sur la base "CN=Manager,OU=Roles,O=MNN,C=WW", le serveur va retourner:
 
{\ttfamily
SearchResultDone (referral) \{\\ \hspace{2mm}ldap ://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"\\ \}\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Considérations de continuation de recherche }
 
\
 
\hspace{1mm}  Pour les opérations de recherche, une fois l'objet de base trouvé et qu'il n'est pas un objet referral, la recherche peut progresser.
\vspace{5mm} \\
 
 
\hspace{1mm}  exemple: Si un client requête un search subtree de "O=MNN,C=WW", en plus de toute entrée dans le scope dont le filtre match, hosta va aussi retourner 2 références de recherche en tant que 2 objets referral dans le scope. Une réponse possible peut être :
\vspace{5mm} \\
 
 
\hspace{1mm} SearchEntry for O=MNN,C=WW
 
{\ttfamily
SearchResultReference \{\\ \hspace{2mm}ldap://hostb/OU=People,O=MNN,C=WW??sub\\ \hspace{2mm}ldap://hostc/OU=People,O=MNN,C=WW??sub\\ \}\\ SearchEntry for CN=Manager,O=MNN,C=WW\\ SearchResultReference \{\\ \hspace{2mm}ldap://hostd/OU=Roles,O=MNN,C=WW??sub\\ \}\\ SearchResultDone (success)\\
}
\vspace{8mm}
 
\hspace{1mm} exemple avec one level: Si le client effectue la recherche de scope OneLevel, une réponse possible peut être:
 
{\ttfamily
SearchResultReference \{\\ \hspace{2mm}ldap://hostb/OU=People,O=MNN,C=WW??base\\ \hspace{2mm}ldap://hostc/OU=People,O=MNN,C=WW??base\\ \}\\ SearchEntry for CN=Manager,O=MNN,C=WW\\ SearchResultReference \{\\ \hspace{2mm}ldap://hostd/OU=Roles,O=MNN,C=WW??base\\ \}\\ SearchResultDone (success)\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge BindRequest }
 
\
 
\hspace{1mm}  Les serveurs ne devraient pas retourner de resultCode referral si un nom bind (ou aun authentication identity ou une authorization identity) est ou est subordonné à un objet referral mais peut utiliser les informations connues pour traiter la requête bind. Si le serveur n'utilise par ces informations, il doit traiter la requête normallement (retourner un invalidCredentials)
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Modify DN }
 
\
 
\hspace{1mm}  Si le newSuperior est un objet referral ou est subordonné à un objet referral, le serveur devrait retourner un affectsMultipleDSAs. si le newRDN existe déjà mais est un objet referral, le serveur devrait retourner affectsMultipleDSAs au lieu de entryAlreadyExists.
\vspace{5mm} \\
 
\end{flushleft}
\end{document}
