\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]{ven. nov. 8 10:32:35 CET 2013}
\lfoot{\Large \textit{Uubu.fr}}
\hypersetup{pdfinfo={
Title={rfc3928},
Author={Sylvain Girod},
Creator={Bash script from uubu.fr's format version 1},
Producer={Bash script and PDFLaTeX},
Subject={LCUP: Client Update Protocol},
CreationDate={D:20131108103235},
ModDate={D:20131108103235},
Keywords={LDAP;Lightweight Directory Access Protocol}
}}
\begin{document}
 
\begin{center}
{\Huge rfc3928 }
\end{center}
\vspace{1cm}
 
\begin{flushleft}
 
{\large LCUP: Client Update Protocol}
 
\vspace{10mm}
 
\hspace{1mm}  Ce protocole permet à un client LDAP de synchroniser le contenu d'un DIT et d'être notifié des changements du contenu. Il adresse les problèmes suivants:
\vspace{5mm} \\
 
 
\hspace{1mm}  Lorsqu'un client utilise une copie local en lecture seul de l'annuaire et qu'il se connecte au réseau, il synchronise son contenu avec l'annuaire et peut optionnellement recevoir des notifications sur les changements qui se produisent pendant qu'il est en ligne. Par exemple, un client mail peut maintenir une copie local de l'adresse book qu'il synchronise avec la copie master quand le client est connecté au réseau de l'entreprise.
\vspace{5mm} \\
 
 
\hspace{1mm}  Les applications qui synchronisent les données, une application meta-annuaire par exemple, va récupérer périodiquement une liste de modifications de l'annuaire, construire les changements, et les appliquer aux données stockées.
\vspace{5mm} \\
 
 
\hspace{1mm}  Les clients qui ont besoin de prendre certaines actions quand une entrée d'annuaire est modifiée. Par exemple, un système de messagerie peut vouloir faire un 'create mailbox' quand une nouvelle personne est créée, et un 'delete mailbox' quand l'entrée est supprimée.
\vspace{5mm} \\
 
 
\hspace{1mm}  \textbf{Le problème suivant n'est pas adressé}: La synchronisation entre serveurs d'annuaire.
\vspace{5mm} \\
 
 
\hspace{1mm}  LCUP est conçus de telle sorte que le serveur n'a pas besoin de maintenir l'état des informations spécifique à chaque client. Le serveur peut maintenir des informations d'état additionnels sur la modification des attributs et autres. les clients sont responsable du stockage des informations sur la manière de mettre à jours leur données avec le contenu de l'annuaire. Le client décide quand et où récupérer les changements. LCUP nécessite que les clients initient la session update et "pull" les changements depuis le serveur.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge applicabilité }
 
\
 
\hspace{1mm}  LCUP fonctionne mieux quand les conditions suivantes sont rencontrées:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1)]{le serveur stocke un certain degré d'informations d'état historique pour réduire la quantité de trafic requis pour les synchronisations incrémentales.}
\item[\hspace{1mm} 2)]{le client ne peut pas assumer comprendre le modèle d'information physique (attributs virtuels, opérationnels, subentries, etc.) implémentés par le serveur.}
\end{description}
 
\vspace{1cm}{\huge Spécification des éléments du protocole }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} Universally Unique Identifiers]{les DN peuvent changer, donc ils ne sont pas des identifiants fiables. Un UUID doit être utilisé avec LCUP. Le serveur doit fournir cet UUID en tant qu'attribut opérationnel single-value. (par exemple: entryUUID). \textbf{LCUPUUID::= OCTET STRING}}
\item[\hspace{1mm} Schéma LCUP et cookie LCUP]{Le protocole LCUP utilise un cookie pour maintenir l'état des données client. Chaque format de cookie est identifié de manière unique avec son schéma. \textbf{LCUPScheme::= LDAPOID}. C'est l'OID qui identifie le format de la valeur du cookieLCUP. \textbf{LCUPCookie::= OCTET STRING}}
\item[\hspace{1mm} contexte LCUP]{La partie du DIT qui est autorisé pour LCUP est appelé un contexte LCUP. Un serveur peut supporter un ou plusieurs contextes LCUP. Chaque contexte LCUP peut utiliser un schéma de cookie différent.}
\end{description}
 
\vspace{1cm}{\huge ResultCode additionnels }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} lcupResourcesExhausted (113)]{Le serveur n'a plus de ressources}
\item[\hspace{1mm} lcupSecurityViolation (114)]{Le client est suspecté d'actions malicieuses}
\item[\hspace{1mm} lcupInvalidData (115)]{Schéma ou cookie invalide}
\item[\hspace{1mm} lcupUnsupportedScheme (116)]{Le schéma du cookie est un OID valide mais n'estpas supporté par ce serveur}
\item[\hspace{1mm} lcupReloadRequired (117)]{Indique que les données client doivent être réinitialisées si le serveur ne contient pas suffisamment d'information pour synchroniser les données, ou si les données du serveur ont été rechargée depuis la dernière session de synchronisation.}
\end{description}
 
\vspace{1cm}{\huge Contrôle Sync Request }
 
\
 
\hspace{1mm} Ce contrôle a \textbf{controlType} à \textbf{1.3.6.1.1.7.1} et \textbf{controlValue}, un OCTET STRING contenant un syncRequestControlValue encodé BER:
 
{\ttfamily
syncRequestControlValue ::= SEQUENCE \{\\ \hspace{2mm}updateType ENUMERATED \{\\ \hspace{2mm}\hspace{2mm}syncOnly (0),\\ \hspace{2mm}\hspace{2mm}syncAndPersist (1),\\ \hspace{2mm}\hspace{2mm}persistOnly (2) \},\\ \hspace{2mm}sendCookieInterval \texttt{[}0\texttt{]} INTEGER OPTIONAL,\\ \hspace{2mm}scheme \texttt{[}1\texttt{]} LCUPScheme OPTIONAL,\\ \hspace{2mm}cookie \texttt{[}2\texttt{]} LCUPCookie OPTIONAL\\ \}\\
}
\vspace{8mm}
 
\hspace{1mm}  \textbf{sendCookieInterval} Le serveur devrait envoyer le cookie dans la valeur du contrôle Sync Update à chaque sendCookieInterval nombre de SearchResultEntry et SearchResultReference retourné au client. Par exemple, si la valeur est 5, le serveur devrait envoyer le cookie dans la valeur du contrôle Sync Update pour toutes les 5 recherches retournés au client. Si cette valeur est absente, 0 ou inférieur à 0, le serveur choisis l'interval.
\vspace{5mm} \\
\hspace{1mm}  Ce contrôle est seulement applicable au message searchRequest.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Contrôle Sync Update }
 
\
 
\hspace{1mm} Ce contrôle a \textbf{controlType} à \textbf{1.3.6.1.1.7.2} et \textbf{controlValue} un OCTET STRING contenant le syncUpdateControlValue encodé BER:
 
{\ttfamily
syncUpdateControlValue ::= SEQUENCE \{\\ \hspace{2mm}stateUpdate BOOLEAN,\\ \hspace{2mm}entryUUID \texttt{[}0\texttt{]} LCUPUUID OPTIONAL, — REQUIRED for entries —\\ \hspace{2mm}UUIDAttribute \texttt{[}1\texttt{]} AttributeType OPTIONAL,\\ \hspace{2mm}entryLeftSet \texttt{[}2\texttt{]} BOOLEAN,\\ \hspace{2mm}persistPhase \texttt{[}3\texttt{]} BOOLEAN,\\ \hspace{2mm}scheme \texttt{[}4\texttt{]} LCUPScheme OPTIONAL,\\ \hspace{2mm}cookie \texttt{[}5\texttt{]} LCUPCookie OPTIONAL\\ \}\\
}
\vspace{8mm}
 
\hspace{1mm}  \textbf{UUIDAttribute} contient le nom ou l'OID de l'attribut que le client devrait utiliser pour effectuer les recherches pour les entrées basée sur l'UUID. Le client devrait être capable de l'utiliser dans un filtre de recherche d'égalité, par exemple "(<uuid attribute>=<entry UUID value>)" et devrait être capable de l'utiliser dans la liste des attributs de requête search pour retourner ses valeurs. UUIDAttribute peut être omis si le serveur ne supporte pas les recherches sur les valeurs UUID.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Contrôle Sync Done }
 
\
 
\hspace{1mm} Ce contrôle a \textbf{controlType} à \textbf{1.3.6.1.1.7.3} et \textbf{controlValue} contenant un syncDoneValue encodé BER:
 
{\ttfamily
syncDoneValue ::= SEQUENCE \{\\ \hspace{2mm}scheme \texttt{[}0\texttt{]} LCUPScheme OPTIONAL,\\ \hspace{2mm}cookie \texttt{[}1\texttt{]} LCUPCookie OPTIONAL\\ \}\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Requêtes LCUP search }
 
\
 
\hspace{1mm}  Un client initie une synchronisation ou une session de recherche persistente avec un serveur en attachant un Sync Request à un message searchRequest. La spécification de recherche détermine le DIT, le jeu d'attributs et la quantité de données que le client veut recevoir. Le contrôle Sync Request contient la spécification de requête du client. S'il y'a une condition d'erreur, le serveur doit retourner SearchResultDone avec un resultCode approprié à l'erreur.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Synchronisation initiale et re-synchronisation complète }
 
\
 
\hspace{1mm}  Les champs du contrôle Sync Request doivent être spécifiés comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} updateType]{Doit être mis à syncOnly ou syncAndPersist}
\item[\hspace{1mm} sendCookieInterval]{Peut être définis}
\item[\hspace{1mm} scheme]{Peut être définis. si définis, le serveur doit utiliser ce schéma ou retourner lcupUnsupportedScheme, sinon, le serveur peut utiliser tout schéma qu'il supporte}
\item[\hspace{1mm} cookie]{Ne doit pas être définis.}
\end{description}
 
\vspace{1cm}{\huge Synchronisation incrémentale et de mise à jours }
 
\
 
\hspace{1mm}  Les champs du contrôle Sync Request doivent être spécifiés comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} updateType]{Doit être à syncOnly ou syncAndPersist}
\item[\hspace{1mm} sendCookieInterval]{Peut être définis}
\item[\hspace{1mm} scheme]{Doit être définis}
\item[\hspace{1mm} cookie]{Doit être définis}
\end{description}
 
\hspace{1mm}  Le client devrait toujours utiliser le dernier cookie reçu par le serveur.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Persistent Only }
 
\
 
\hspace{1mm}  Les champs de Sync Request doivent être spécifié comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} updateType]{Doit être à persistOnly}
\item[\hspace{1mm} sendCookieInterval]{Peut être définis}
\item[\hspace{1mm} scheme]{Peut être définis}
\item[\hspace{1mm} cookie]{Peut être définis, mais le serveur doit l'ignorer.}
\end{description}
 
\vspace{1cm}{\huge Réponses LCUP Search }
 
\
 
\hspace{1mm}  Dans la réponse au client, le serveur retourne 0 ou plusieurs SearchResultEntry ou SearchResultReference, suivis par un SearchResultDone. Chaque SearchResultEntry ou SearchResultReference contient aussi un contrôle Sync Update qui décrit l'état LCUP de l'entrée retournée. SearchResultDone contient un contrôle Sync Done.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Réponses Sync Update Informational }
 
\
 
\hspace{1mm}  Le serveur peut utiliser le contrôle Sync Update pour retourner des informations non liées à une entrée particulière. Il peut le faire à tout moment pour retourner un cookie au client, ou pour informer le client que la phase de sync d'une recherche syncAndPersist est complète et que la phase persist a commencé. Il peut le faire durant la phase persist même quand aucune entrée n'a changé/ Pour faire çà, il faut retourner:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{un PDU SearchResultEntry avec objectName contenant le DN de baseObject de la requête de recherche et avec un attribut list vide.}
\item[\hspace{1mm} -]{Un contrôle Sync Update avec les champs définis comme suit :}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{1mm} stateUpdape]{Doit être à TRUE}
\item[\hspace{1mm} entryUUID]{Devrait être l'UUID du baseObject de la requête search}
\item[\hspace{1mm} entryLeftSet]{Doit être à FALSE}
\item[\hspace{1mm} persistPhase]{Doit être FALSE si la recherche est dans la phase sync et TRUE si elle est dans la phase persist.}
\item[\hspace{1mm} UUIDAttribute]{Devrait seulement être définis si c'est soit le premier résultat retourné soit l'attribut a changé}
\item[\hspace{1mm} scheme]{Doit être définis si le cookie est définis et que le format a changé, sinon il peut être omi.}
\item[\hspace{1mm} cookie]{Devrait être définis}
\end{description}
 
\hspace{1mm}  Durant une requête \textbf{SyncAndPersist}, le serveur doit retourner immédiatement après que la dernière entrée de la phase sync ait été envoyée et avant que la première entrée de la phase persist ait été envoyée. Celà permet au client de savoir quand la phase sync se termine et quand la phase persist commence.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Fréquence de retour de cookie }
 
\
 
\hspace{1mm}  Le champ cookie d'un contrôle Sync Update peut être définis dans tout résultat retourné, durant la phase sync et persist. Le serveur devrait retourner le cookie suffisamment souvent pour que le client resynchronise dans une période de temps raisonnable en cas de déconnections par ex. Le champ sendCookieInterval est une suggestion au serveur et il devrait respecter cette valeur.
\vspace{5mm} \\
\hspace{1mm}  Le champ scheme doit être définis si le cookie est présent et que le format a changé, sinon il peut être omis.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Définition d'une entrée qui entre dans le jeu de résultat }
 
\
 
\hspace{1mm}  Une entrée doit être considérée rentrer dans le jeu de résultat de la recherche du client si un des conditions est rencontrée:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Durant la phase sync pour une opération sync incrémentale, l'entrée est présent dans le jeu de résultat de la recherche mais n'était pas présente avant ; typiquement une entrée qui a été ajoutée ou déplacée dans l'annuaire.}
\item[\hspace{1mm} -]{Durant la phase persist pour une opération de recherche persistante, l'entrée entre dans le jeu de résultat de recherche, typiquement une entrée qui a été ajoutée ou déplacée dans l'annuaire.}
\end{description}
 
\vspace{1cm}{\huge Définition d'une entrée qui a changé }
 
\
 
\hspace{1mm}  Une entrée doit être considérée changée si un ou plusieurs de ses attributs dans la liste des attributs de la recherche ont été modifiés.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Définition d'une entrée qui a quitté le jeu de résultat }
 
\
 
\hspace{1mm}  Une entrée doit être considérée sortie du jeu de résultat si elle rencontre une de ces conditions:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Durant la phase sync, l'entrée n'est pas présente dans le jeu de résultat mais était présent avant.}
\item[\hspace{1mm} -]{Durant la phase persist, l'entrée quitte le jeu de résultat.}
\end{description}
 
\vspace{1cm}{\huge Résultats pour les entrées présentes dans le jeu de résultat }
 
\
 
\hspace{1mm}  Une entrée devrait être retournée présente sous les conditions suivante:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{La requête est une synchronisation initiale pour une requête full resync et l'entrée est présent dans le jeu de résultat de la recherche du client.}
\item[\hspace{1mm} -]{La requête est une synchronisation incrémentale et l'entrée a changé ou est entrée dans le jeu de résultat depuis la dernière synchronisation.}
\item[\hspace{1mm} -]{La recherche est dans la phase persist et l'entrée entre dans le jeu de résultat ou change.}
\end{description}
 
\hspace{1mm}  Pour un retour SearchResultEntry, les champs du contrôle Sync Update doivent être définis comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} stateUpdate]{Doit être FALSE}
\item[\hspace{1mm} entryUUID]{Doit être l'UUID de l'entrée}
\item[\hspace{1mm} entryLeftSet]{Doit être FALSE}
\item[\hspace{1mm} persistPhase]{Doit être FALSE durant la phase sync, TRUE durant la phase Persist}
\item[\hspace{1mm} UUIDAttribute]{Devrait être définis seulement si c'est le premier résultat retourné ou si l'attribut a changé}
\item[\hspace{1mm} schema]{comme plus haut}
\item[\hspace{1mm} cookie]{Comme plus haut}
\end{description}
 
\vspace{1cm}{\huge Résultat pour les entrées qui ont quitté le jeu de résultat }
 
\
 
\hspace{1mm}  Une entrée devrait être considéré ayant quitté le jeu de résultat si elle est dans les conditions suivantes:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{La requête est une synchronisation incrémentale durant la phase sync et l'entrée est sortie du jeu de résultat}
\item[\hspace{1mm} -]{La recherche est dans la phase persist et l'entrée a quitté le jeu de résultat}
\item[\hspace{1mm} -]{L'entrée a quitté le jeu derésultat suitte à un LDAP delte ou ldap ModifyDN}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{1mm} stateUpdate]{Doit être FALSE}
\item[\hspace{1mm} entryUUID]{Doit être l'UUID de l'entrée qui a quitté le jeu de résultat}
\item[\hspace{1mm} entryLeftSet]{Doit être TRUE}
\item[\hspace{1mm} persistPhase]{Doit être FALSE durant la phase sync, TRUE durant la phase Persist}
\item[\hspace{1mm} UUIDAttribute]{Devrait être définis seulement si c'est le premier résultat retourné ou si l'attribut a changé}
\item[\hspace{1mm} schema]{comme plus haut}
\item[\hspace{1mm} cookie]{Comme plus haut}
\end{description}
 
\vspace{1cm}{\huge Retourner les résultats durant la phase persistante }
 
\
 
\hspace{1mm}  Le serveur devrait retourner les entrées changées au client le plus rapidement possible
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Pas de mixe de phase sync et persist }
 
\
 
\hspace{1mm}  Durant la phase sync, le serveur ne doit pas retourner d'entrée avec le flag persistPhase à TRUE et durant la phase persisit ce flag doit être à TRUE.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Retourner les résultats mis à jours durant la phase sync }
 
\
 
\hspace{1mm}  Il peut y avoir des mises à jours des entrées dans le jeu de résultats durant l'opération de recherche. Si le serveur est surchargé de mises à jours et qu'il tente d'envoyer toutes ces mises à jours, il peut ne jamais terminer la phase sync. C'est à la discretion de l'implémentation du serveur de décider quand le client est en "in sync", c'est à dire quand se termine un suncOnly ou quand envoyer la réponse Update Informational entre les phases sync et persist.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Attributs opérationnels et entrées administratives }
 
\
 
\hspace{1mm}  Ils devraient être retournés tels qu'il seraient retournés dans une recherche normal. Si le serveur ne supporte pas la synchronisation des attributs opérationnel, le serveur doit retourner SearchResultDone avec un result unwillingToPerform
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Garantie de convergence }
 
\
 
\hspace{1mm}  Si durant une recherche LCUP soit durant la phase sync ou persist, le serveur détermine qu'il ne peut pas garantir la délivrance de la copie au client pour une éventuelle convergence, il devrait immédiatement terminer la recherche LCUP et retourner un resultCode lcupReloadRequired.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Fin de recherche LCUP }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} Fin initiée par le serveur]{Quand le serveur a terminé le traitement avec succès, il attache un contrôle Sync Done au message SearchResultDone et il l'envoie au client. Cependant, si le resultCode de ce message est différent de success ou canceled, le contrôle Sync Done peut être omis. Le cookie doit être présent si resultCode est success ou canceled. Il devrait être présent si le resultCode est lcupResourcesExhausted, timeLimitExceeded, sizeLimitExceeded, ou adminLimitExceeded. Celà permet au client de resynchroniser plus facilement.}
\item[\hspace{1mm} Fin initiée par le client]{Si le client doit terminer la synchronisation et veut obtenir le cookie qui représente l'état courant, il fournis une opération LDAP Cancel. Le serveur répond immédiatement avec une réponse LDAP Cancel.}
\item[\hspace{1mm} Limite de temps et de taille]{Le serveur doit supporter les limites de taille et de temps. Le serveur doit s'assurer que si l'opération est terminée dû à ces conditions, le cookie est renvoyé au client.}
\item[\hspace{1mm} Opération sur la même connexion]{Il est permis au client de fournis des opérations LDAP sur la connexion utilisé par le protocole.}
\item[\hspace{1mm} Intéraction avec d'autres contrôles]{LCUP ne définit pas de restriction ni ne garantie la capacité d'utiliser les contrôles de ce document avec d'autres contrôles.}
\item[\hspace{1mm} Considérations de réplication]{L'utilisation d'un cookie LCUP avec plusieurs DSA dans un environnement répliqué n'estpas définis parLCUP. Une implémentation LCUP peut supporter la continuation de session avec un autre DSA. Les clients peuvent envoyer des cookies retournés par un DSA à un autre DSA.}
\end{description}
 
\vspace{1cm}{\huge Considérations côté client }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} Utiliser les cookies avec différents critères de recherche]{Le cookie reçu d'un serveur après une session de synchronisation devrait seulement être utilisé avec les même spécifications de recherche qui ont généré le cookie.}
\item[\hspace{1mm} Manipulation de référrant]{Le client peut reçevoir un référrant quandla recherche de base est une référence subordonnées et va terminer l'opération.}
\end{description}
 
\vspace{1cm}{\huge Considération d'implémentation serveur }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} Support des UUID]{Les serveurs doivent supporter les UUID.}
\item[\hspace{1mm} Exemple en utilisant un RUV comme valeur de cookie]{Par concept, le protocole supporte plusieurs schéma de cookie, ce qui permet à différentes implémentations la flexibilité du stockage des informations. Une implémentation raisonnable serait d'utiliser le ReplicaUpdate Vector. Pour chaque Master, RUV contient le plus grand CSN vu par ce master. En plus, RUV implémenté par certains serveurs contiennent une génération de réplica, un chaîne opaque qui identifie le stockage des données de réplica. La valeur change quand les données sont rechargées. La génération de réplica est utilisé pour signaler aux parties de réplication/synchronisation que les données de réplica ont été rechargée et que tous les autres réplica doivent être réinitialisées.}
\item[\hspace{1mm} Support pour plusieurs schéma de cookie]{Un serveur doit publier les OID des schéma de cookie supportés}
\end{description}
\end{flushleft}
\end{document}
