view release on metacpan or  search on metacpan

share/fixed_amqp0-8.xml  view on Meta::CPAN

    connection          = open-connection *use-connection close-connection
    open-connection     = C:protocol-header
                          S:START C:START-OK
                          *challenge
                          S:TUNE C:TUNE-OK
                          C:OPEN S:OPEN-OK | S:REDIRECT
    challenge           = S:SECURE C:SECURE-OK
    use-connection      = *channel
    close-connection    = C:CLOSE S:CLOSE-OK
                        / S:CLOSE C:CLOSE-OK
</doc>
    <chassis name="server" implement="MUST"/>
    <chassis name="client" implement="MUST"/>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="start" synchronous="1" index="10">
  start connection negotiation
  <doc>
    This method starts the connection negotiation process by telling
    the client the protocol version that the server proposes, along
    with a list of security mechanisms which the client can use for
    authentication.
  </doc>
      <rule implement="MUST">
    If the client cannot handle the protocol version suggested by the
    server it MUST close the socket connection.
  </rule>
      <rule implement="MUST">
    The server MUST provide a protocol version that is lower than or
    equal to that requested by the client in the protocol header. If
    the server cannot support the specified protocol it MUST NOT send
    this method, but MUST close the socket connection.
  </rule>
      <chassis name="client" implement="MUST"/>
      <response name="start-ok"/>
      <field name="version major" type="octet">
    protocol major version
    <doc>
      The protocol major version that the server agrees to use, which
      cannot be higher than the client's major version.
    </doc>
      </field>
      <field name="version minor" type="octet">
    protocol major version
    <doc>
      The protocol minor version that the server agrees to use, which
      cannot be higher than the client's minor version.
    </doc>
      </field>
      <field name="server properties" domain="peer properties">
    server properties
  </field>
      <field name="mechanisms" type="longstr">
    available security mechanisms
    <doc>
      A list of the security mechanisms that the server supports, delimited
      by spaces.  Currently ASL supports these mechanisms: PLAIN.
    </doc>
        <see name="security mechanisms"/>
        <assert check="notnull"/>
      </field>
      <field name="locales" type="longstr">
    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 implement="MUST">
      All servers MUST support at least the en_US locale.
    </rule>
        <assert check="notnull"/>
      </field>
    </method>
    <method name="start-ok" synchronous="1" index="11">
  select security mechanism and locale
  <doc>
    This method selects a SASL security mechanism. ASL uses SASL
    (RFC2222) to negotiate authentication and encryption.
  </doc>
      <chassis name="server" implement="MUST"/>
      <field name="client properties" domain="peer properties">
    client properties
  </field>
      <field name="mechanism" type="shortstr">
    selected security mechanism
    <doc>
      A single security mechanisms selected by the client, which must be
      one of those specified by the server.
    </doc>
        <rule implement="SHOULD">
      The client SHOULD authenticate using the highest-level security
      profile it can handle from the list provided by the server.
    </rule>
        <rule implement="MUST">
    The mechanism field MUST contain one of the security mechanisms
    proposed by the server in the Start method. If it doesn't, the
    server MUST close the socket.
    </rule>
        <assert check="notnull"/>
      </field>
      <field name="response" type="longstr">
    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.  For the
      PLAIN security mechanism this is defined as a field table holding
      two fields, LOGIN and PASSWORD.
    </doc>
        <assert check="notnull"/>
      </field>
      <field name="locale" type="shortstr">
    selected message locale
    <doc>
      A single message local 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">
  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" type="longstr">
    security challenge data
    <doc>
      Challenge information, a block of opaque binary data passed to
      the security mechanism.
    </doc>
        <see name="security mechanisms"/>
      </field>
    </method>
    <method name="secure-ok" synchronous="1" index="21">
  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" type="longstr">
    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">
  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" type="short">
    proposed maximum channels
    <doc>
      The maximum total number of channels that the server allows
      per connection. Zero means that the server does not impose a
      fixed limit, but the number of allowed channels may be limited
      by available server resources.
    </doc>
      </field>