Corrections de casses dans "Chiffrement SSL de session"

postgresql/protocol.xml

@@ -1439,40 +1439,40 @@ SELCT 1/0;
   </sect2>
 
   <sect2>
-   <title>Chiffrement <acronym>ssl</acronym> de session</title>
+   <title>Chiffrement <acronym>SSL</acronym> de session</title>
 
    <para>
     Si <productname>PostgreSQL</productname> a été construit avec le support de
-    <acronym>ssl</acronym>, les communications client/serveur peuvent être chiffrées
+    <acronym>SSL</acronym>, les communications client/serveur peuvent être chiffrées
     en l'utilisant. Ce chiffrement assure la sécurité de la communication
     dans les environnements où des agresseurs pourraient capturer le trafic
     de la session. Pour plus d'informations sur le cryptage des sessions
-    <productname>PostgreSQL</productname> avec <acronym>ssl</acronym>, voir
+    <productname>PostgreSQL</productname> avec <acronym>SSL</acronym>, voir
     <xref linkend="ssl-tcp"/>.
    </para>
 
    <para>
-    Pour initier une connexion chiffrée par <acronym>ssl</acronym>, le client envoie
+    Pour initier une connexion chiffrée par <acronym>SSL</acronym>, le client envoie
     initialement un message SSLRequest à la place d'un StartupMessage. Le
-    serveur répond avec un seul octet contenant <literal>s</literal> ou <literal>n</literal>
-    indiquant respectivement s'il souhaite ou non utiliser le <acronym>ssl</acronym>.
+    serveur répond avec un seul octet contenant <literal>S</literal> ou <literal>N</literal>
+    indiquant respectivement s'il souhaite ou non utiliser le <acronym>SSL</acronym>.
     Le client peut alors clore la connexion s'il n'est pas satisfait de la
-    réponse. Pour continuer après un <literal>s</literal>, il faut échanger une poignée
-    de main <acronym>ssl</acronym> (handshake) (non décrite ici car faisant partie de
-    la spécification <acronym>ssl</acronym>) avec le serveur. En cas de succès, le
+    réponse. Pour continuer après un <literal>S</literal>, il faut échanger une poignée
+    de main <acronym>SSL</acronym> (handshake) (non décrite ici car faisant partie de
+    la spécification <acronym>SSL</acronym>) avec le serveur. En cas de succès, le
     StartupMessage habituel est envoyé. Dans ce cas, StartupMessage et toutes
-    les données suivantes seront chiffrées avec <acronym>ssl</acronym>. Pour continuer
-    après un <literal>n</literal>, il suffit d'envoyer le startupmessage habituel et
+    les données suivantes seront chiffrées avec <acronym>SSL</acronym>. Pour continuer
+    après un <literal>N</literal>, il suffit d'envoyer le startupmessage habituel et
     de continuer sans chiffrage.
    </para>
 
    <para>
     Le client doit être préparé à gérer une réponse ErrorMessage à un SSLRequest
     émanant du serveur. Ceci ne peut survenir que si le serveur ne dispose pas
-    du support de <acronym>ssl</acronym>. (De tels servers sont maintenant
+    du support de <acronym>SSL</acronym>. (De tels servers sont maintenant
     très anciens, et ne doivent certainement plus exister.) Dans ce cas, la
     connexion doit être fermée, mais le client peut choisir d'ouvrir une
-    nouvelle connexion et procéder sans <acronym>ssl</acronym>.
+    nouvelle connexion et procéder sans <acronym>SSL</acronym>.
    </para>
 
    <para>
@@ -1482,7 +1482,7 @@ SELCT 1/0;
 
    <para>
     Alors que le protocole lui-même ne fournit pas au serveur de moyen de
-    forcer le chiffrage <acronym>ssl</acronym>, l'administrateur peut configurer le
+    forcer le chiffrage <acronym>SSL</acronym>, l'administrateur peut configurer le
     serveur pour rejeter les sessions non chiffrées, ce qui est une autre
     façon de vérifier l'authentification.
    </para>