view release on metacpan or  search on metacpan

share/fixed_amqp0-9-1.xml  view on Meta::CPAN

          that requested by the client in the protocol header.
        </doc>
        <doc type = "scenario">
          The client requests a protocol version that is higher than any valid
          implementation, e.g. 2.0.  The server must respond with a protocol header
          indicating its supported protocol version, e.g. 1.0.
        </doc>
      </rule>
      <rule name = "client-support">
        <doc>
          If the client cannot handle the protocol version suggested by the server
          it MUST close the socket connection without sending any further data.
        </doc>
        <doc type = "scenario">
          The server sends a protocol version that is lower than any valid
          implementation, e.g. 0.1.  The client must respond by closing the
          connection without sending any further data.
        </doc>
      </rule>

      <chassis name = "client" implement = "MUST" />
      <response name = "start-ok" />

      <field name = "version-major" domain = "octet" label = "protocol major version">
        <doc>
          The major version number can take any value from 0 to 99 as defined in the
          AMQP specification.
        </doc>
      </field>

      <field name = "version-minor" domain = "octet" label = "protocol minor version">
        <doc>
          The minor version number can take any value from 0 to 99 as defined in the
          AMQP specification.
        </doc>
      </field>

      <field name = "server-properties" domain = "peer-properties" label = "server properties">
        <rule name = "required-fields">
          <doc>
            The properties SHOULD contain at least these fields: "host", specifying the
            server host name or address, "product", giving the name of the server product,
            "version", giving the name of the server version, "platform", giving the name
            of the operating system, "copyright", if appropriate, and "information", giving
            other general information.
          </doc>
          <doc type = "scenario">
            Client connects to server and inspects the server properties. It checks for
            the presence of the required fields.
          </doc>
        </rule>
      </field>

      <field name = "mechanisms" domain = "longstr" label = "available security mechanisms">
        <doc>
          A list of the security mechanisms that the server supports, delimited by spaces.
        </doc>
        <assert check = "notnull" />
      </field>

      <field name = "locales" domain = "longstr" label = "available message locales">
        <doc>
          A list of the message locales that the server supports, delimited by spaces. The
          locale defines the language in which the server will send reply texts.
        </doc>
        <rule name = "required-support">
          <doc>
            The server MUST support at least the en_US locale.
          </doc>
          <doc type = "scenario">
            Client connects to server and inspects the locales field. It checks for
            the presence of the required locale(s).
          </doc>
        </rule>
        <assert check = "notnull" />
      </field>
    </method>

    <method name = "start-ok" synchronous = "1" index = "11"
      label = "select security mechanism and locale">
      <doc>
        This method selects a SASL security mechanism.
      </doc>

      <chassis name = "server" implement = "MUST" />

      <field name = "client-properties" domain = "peer-properties" label = "client properties">
        <rule name = "required-fields">
          <!-- This rule is not testable from the client side -->
          <doc>
            The properties SHOULD contain at least these fields: "product", giving the name
            of the client product, "version", giving the name of the client version, "platform",
            giving the name of the operating system, "copyright", if appropriate, and
            "information", giving other general information.
          </doc>
        </rule>
      </field>

      <field name = "mechanism" domain = "shortstr" label = "selected security mechanism">
        <doc>
          A single security mechanisms selected by the client, which must be one of those
          specified by the server.
        </doc>
        <rule name = "security">
          <doc>
            The client SHOULD authenticate using the highest-level security profile it
            can handle from the list provided by the server.
          </doc>
        </rule>
        <rule name = "validity">
          <doc>
            If the mechanism field does not contain one of the security mechanisms
            proposed by the server in the Start method, the server MUST close the
            connection without sending any further data.
          </doc>
          <doc type = "scenario">
            Client connects to server and sends an invalid security mechanism. The
            server must respond by closing the connection (a socket close, with no
            connection close negotiation).
          </doc>
        </rule>
        <assert check = "notnull" />
      </field>

      <field name = "response" domain = "longstr" label = "security response data">
        <doc>
          A block of opaque data passed to the security mechanism. The contents of this
          data are defined by the SASL security mechanism.
        </doc>
        <assert check = "notnull" />
      </field>

      <field name = "locale" domain = "shortstr" label = "selected message locale">
        <doc>
          A single message locale selected by the client, which must be one of those
          specified by the server.
        </doc>
        <assert check = "notnull" />
      </field>
    </method>

    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

    <method name = "secure" synchronous = "1" index = "20" label = "security mechanism challenge">
      <doc>
        The SASL protocol works by exchanging challenges and responses until both peers have
        received sufficient information to authenticate each other. This method challenges
        the client to provide more information.
      </doc>

      <chassis name = "client" implement = "MUST" />
      <response name = "secure-ok" />

      <field name = "challenge" domain = "longstr" label = "security challenge data">
        <doc>
          Challenge information, a block of opaque binary data passed to the security
          mechanism.
        </doc>
      </field>
    </method>

    <method name = "secure-ok" synchronous = "1" index = "21" label = "security mechanism response">
      <doc>
        This method attempts to authenticate, passing a block of SASL data for the security
        mechanism at the server side.
      </doc>

      <chassis name = "server" implement = "MUST" />

      <field name = "response" domain = "longstr" label = "security response data">
        <doc>
          A block of opaque data passed to the security mechanism. The contents of this
          data are defined by the SASL security mechanism.
        </doc>
        <assert check = "notnull" />
      </field>
    </method>

    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

    <method name = "tune" synchronous = "1" index = "30"
      label = "propose connection tuning parameters">
      <doc>
        This method proposes a set of connection configuration values to the client. The
        client can accept and/or adjust these.
      </doc>

      <chassis name = "client" implement = "MUST" />

      <response name = "tune-ok" />

      <field name = "channel-max" domain = "short" label = "proposed maximum channels">
        <doc>
          Specifies highest channel number that the server permits.  Usable channel numbers
          are in the range 1..channel-max.  Zero indicates no specified limit.