<varlistentry>
      <term>AuthenticationSASL</term>
      <listitem>
       <para>
        The frontend must now initiate a SASL negotiation, using one of the
        SASL mechanisms listed in the message. The frontend will send a
        SASLInitialResponse with the name of the selected mechanism, and the
        first part of the SASL data stream in response to this. If further
        messages are needed, the server will respond with
        AuthenticationSASLContinue. See <xref linkend="sasl-authentication"/>
        for details.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>AuthenticationSASLContinue</term>
      <listitem>
       <para>
        This message contains challenge data from the previous step of SASL
        negotiation (AuthenticationSASL, or a previous
        AuthenticationSASLContinue). The frontend must respond with a
        SASLResponse message.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>AuthenticationSASLFinal</term>
      <listitem>
       <para>
        SASL authentication has completed with additional mechanism-specific
        data for the client. The server will next send AuthenticationOk to
        indicate successful authentication, or an ErrorResponse to indicate
        failure. This message is sent only if the SASL mechanism specifies
        additional data to be sent from server to client at completion.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>NegotiateProtocolVersion</term>
      <listitem>
       <para>
        The server does not support the minor protocol version requested
        by the client, but does support an earlier version of the protocol;
        this message indicates the highest supported minor version.  This
        message will also be sent if the client requested unsupported protocol
        options (i.e., beginning with <literal>_pq_.</literal>) in the
        startup packet.
       </para>
       <para>
        After this message, the authentication will continue using the version
        indicated by the server.  If the client does not support the older
        version, it should immediately close the connection.  If the server
        does not send this message, it supports the client's requested
        protocol version and all the protocol options.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>
   </para>

   <para>
    If the frontend does not support the authentication method
    requested by the server, then it should immediately close the
    connection.
   </para>

   <para>
    After having received AuthenticationOk, the frontend must wait
    for further messages from the server.  In this phase a backend process
    is being started, and the frontend is just an interested bystander.
    It is still possible for the startup attempt
    to fail (ErrorResponse) or the server to decline support for the requested
    minor protocol version (NegotiateProtocolVersion), but in the normal case
    the backend will send some ParameterStatus messages, BackendKeyData, and
    finally ReadyForQuery.
   </para>

   <para>
    During this phase the backend will attempt to apply any additional
    run-time parameter settings that were given in the startup message.
    If successful, these values become session defaults.  An error causes
    ErrorResponse and exit.
   </para>

   <para>
    The possible messages from the backend in this phase are:

    <variablelist>
     <varlistentry>
      <term>BackendKeyData</term>
      <listitem>
       <para>
        This message provides secret-key data that the frontend must
        save if it wants to be able to issue cancel requests later.
        The frontend should not respond to this message, but should
        continue listening for a ReadyForQuery message.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>ParameterStatus</term>