rfc3080.txt

最新的RFC

Rose                        Standards Track                    [Page 27]

RFC 3080                     The BEEP Core                    March 2001


2.6 Asynchrony

   BEEP accommodates asynchronous interactions, both within a single
   channel and between separate channels.  This feature allows
   pipelining (intra-channel) and parallelism (inter-channel).

2.6.1 Within a Single Channel

   A BEEP peer acting in the client role may send multiple "MSG"
   messages on the same channel without waiting to receive the
   corresponding replies.  This provides pipelining within a single
   channel.

   A BEEP peer acting in the server role must process all "MSG" messages
   for a given channel in the same order as they are received.  As a
   consequence, the BEEP peer must generate replies in the same order as
   the corresponding "MSG" messages are received on a given channel.

   Note that in one-to-many exchanges (c.f., Section 2.1.1), the reply
   to the "MSG" message consists of zero or more "ANS" messages followed
   by a "NUL" message.  In this style of exchange, the "ANS" messages
   comprising the reply may be interleaved.  When the BEEP peer acting
   in the server role signifies the end of the reply by generating the
   "NUL" message, it may then process the next "MSG" message received
   for that channel.

2.6.2 Between Different Channels

   A BEEP peer acting in the client role may send multiple "MSG"
   messages on different channels without waiting to receive the
   corresponding replies.  The channels operate independently, in
   parallel.

   A BEEP peer acting in the server role may process "MSG" messages
   received on different channels in any order it chooses.  As a
   consequence, although the replies for a given channel appear to be
   generated in the same order in which the corresponding "MSG" messages
   are received, there is no ordering constraint for replies on
   different channels.












Rose                        Standards Track                    [Page 28]

RFC 3080                     The BEEP Core                    March 2001


2.6.3 Pre-emptive Replies

   A BEEP peer acting in the server role may send a negative reply
   before it receives the final "MSG" frame of a message.  If it does
   so, that BEEP peer is obliged to ignore any subsequent "MSG" frames
   for that message, up to and including the final "MSG" frame.

   If a BEEP peer acting in the client role receives a negative reply
   before it sends the final "MSG" frame for a message, then it is
   required to send a "MSG" frame with a continuation status of complete
   (".") and having a zero-length payload.

2.6.4 Interference

   If the processing of a particular message has sequencing impacts on
   other messages (either intra-channel or inter-channel), then the
   corresponding profile should define this behavior, e.g., a profile
   whose messages alter the underlying transport mapping.

































Rose                        Standards Track                    [Page 29]

RFC 3080                     The BEEP Core                    March 2001


2.7 Peer-to-Peer Behavior

   BEEP is peer-to-peer -- as such both peers must be prepared to
   receive all messages defined in this memo.  Accordingly, an
   initiating BEEP peer capable of acting only in the client role must
   behave gracefully if it receives a "MSG" message.  Accordingly, all
   profiles must provide an appropriate error message for replying to
   unexpected "MSG" messages.

   As a consequence of the peer-to-peer nature of BEEP, message numbers
   are unidirectionally-significant.  That is, the message numbers in
   "MSG" messages sent by a BEEP peer acting in the initiating role are
   unrelated to the message numbers in "MSG" messages sent by a BEEP
   peer acting in the listening role.

   For example, these two messages

       I: MSG 0 1 . 52 120
       I: Content-Type: application/beep+xml
       I:
       I: <start number='1'>
       I:    <profile uri='http://iana.org/beep/SASL/OTP' />
       I: </start>
       I: END
       L: MSG 0 1 . 221 116
       L: Content-Type: application/beep+xml
       L:
       L: <start number='2'>
       L:    <profile uri='http://iana.org/beep/APEX' />
       L: </start>
       L: END

   refer to different messages sent on channel zero.


















Rose                        Standards Track                    [Page 30]

RFC 3080                     The BEEP Core                    March 2001


3. Transport Security

   When a BEEP session is established, plaintext transfer, without
   privacy, is provided.  Accordingly, transport security in BEEP is
   achieved using an initial tuning profile.

   This document defines one profile:

   o  the TLS transport security profile, based on TLS version one [3].

   Other profiles may be defined and deployed on a bilateral basis.
   Note that because of their intimate relationship with the transport
   service, a given transport security profile tends to be relevant to a
   single transport mapping (c.f., Section 2.5).

   When a channel associated with transport security begins the
   underlying negotiation process, all channels (including channel zero)
   are closed on the BEEP session.  Accordingly, upon completion of the
   negotiation process, regardless of its outcome, a new greeting is
   issued by both BEEP peers.  (If the negotiation process fails, then
   either BEEP peer may instead terminate the session, and it is
   recommended that a diagnostic entry be logged.)

   A BEEP peer may choose to issue different greetings based on whether
   privacy is in use, e.g.,

       L: <wait for incoming connection>
       I: <open connection>
       L: RPY 0 0 . 0 110
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/TLS' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END
       I: MSG 0 1 . 52 158
       I: Content-Type: application/beep+xml
       I:








Rose                        Standards Track                    [Page 31]

RFC 3080                     The BEEP Core                    March 2001


       I: <start number='1'>
       I:    <profile uri='http://iana.org/beep/TLS'>
       I:        <![CDATA[<ready />]]>
       I:    </profile>
       I: </start>
       I: END
       L: RPY 0 1 . 110 121
       L: Content-Type: application/beep+xml
       L:
       L: <profile uri='http://iana.org/beep/TLS'>
       L:     <![CDATA[<proceed />]]>
       L: </profile>
       L: END

           ... successful transport security negotiation ...

       L: RPY 0 0 . 0 221
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
       L:    <profile uri='http://iana.org/beep/SASL/OTP' />
       L:    <profile uri='http://iana.org/beep/APEX' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END

   Of course, not all BEEP peers need be as single-minded:

       L: <wait for incoming connection>
       I: <open connection>
       L: RPY 0 0 . 0 268
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
       L:    <profile uri='http://iana.org/beep/SASL/OTP' />
       L:    <profile uri='http://iana.org/beep/APEX' />
       L:    <profile uri='http://iana.org/beep/TLS' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:



Rose                        Standards Track                    [Page 32]

RFC 3080                     The BEEP Core                    March 2001


       I: <greeting />
       I: END
       I: MSG 0 1 . 52 158
       I: Content-Type: application/beep+xml
       I:
       I: <start number='1'>
       I:    <profile uri='http://iana.org/beep/TLS'>
       I:        <![CDATA[<ready />]]>
       I:    </profile>
       I: </start>
       I: END
       L: RPY 0 1 . 268 121
       L: Content-Type: application/beep+xml
       L:
       L: <profile uri='http://iana.org/beep/TLS'>
       L:     <![CDATA[<proceed />]]>
       L: </profile>
       L: END

           ... failed transport security negotiation ...

       L: RPY 0 0 . 0 268
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
       L:    <profile uri='http://iana.org/beep/SASL/OTP' />
       L:    <profile uri='http://iana.org/beep/APEX' />
       L:    <profile uri='http://iana.org/beep/TLS' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END















Rose                        Standards Track                    [Page 33]

RFC 3080                     The BEEP Core                    March 2001


3.1 The TLS Transport Security Profile

   Section 6.2 contains the registration for this profile.

3.1.1 Profile Identification and Initialization

   The TLS transport security profile is identified as:

       http://iana.org/beep/TLS

   in the BEEP "profile" element during channel creation.

   During channel creation, the corresponding "profile" element in the
   BEEP "start" element may contain a "ready" element.  If channel
   creation is successful, then before sending the corresponding reply,
   the BEEP peer processes the "ready" element and includes the
   resulting response in the reply, e.g.,

       C: MSG 0 1 . 52 158
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/TLS'>
       C:        <![CDATA[<ready />]]>
       C:    </profile>
       C: </start>
       C: END
       S: RPY 0 1 . 110 121
       S: Content-Type: application/beep+xml
       S:
       S: <profile uri='http://iana.org/beep/TLS'>
       S:     <![CDATA[<proceed />]]>
       S: </profile>
       S: END

















Rose                        Standards Track                    [Page 34]

RFC 3080                     The BEEP Core                    March 2001


   Note that it is possible for the channel to be created, but for the
   encapsulated operation to fail, e.g.,

       C: MSG 0 1 . 52 173
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/TLS'>
       C:        <![CDATA[<ready version="oops" />]]>
       C:    </profile>
       C: </start>
       C: END
       S: RPY 0 1 . 110 193
       S: Content-Type: application/beep+xml
       S:
       S: <profile uri='http://iana.org/beep/TLS'>
       S:     <![CDATA[<error code='501'>version attribute
       S: poorly formed in &lt;ready&gt; element</error>]]>
       S: </profile>
       S: END

   In this case, a positive reply is sent (as channel creation
   succeeded), but the encapsulated response contains an indication as
   to why the operation failed.

3.1.2 Message Syntax

   Section 7.2 defines the messages that are used in the TLS transport
   security profile.






















Rose                        Standards Track                    [Page 35]

RFC 3080                     The BEEP Core                    March 2001


3.1.3 Message Semantics

3.1.3.1 The Ready Message

   The "ready" element has an optional "version" attribute and no
   content:

   o  the "version" element defines the earliest version of TLS
      acceptable for use.

   When a BEEP peer sends the "ready" element, it must not send any
   further traffic on the underlying transport service until a
   corresponding reply ("proceed" or "error") is received; similarly,
   the receiving BEEP peer must wait until any pending replies have been
   generated and sent before it processes a "ready" element.

3.1.3.2 The Proceed Message

   The "proceed" element has no attributes and no content.  It is sent
   as a reply to the "ready" element.

   When a BEEP peer receives the "ready" element, it must not send any
   further traffic on the underlying transport service until it
   generates a corresponding reply.  If the BEEP peer decides to allow
   transport security negotiation, it implicitly closes all channels
   (including channel zero), and sends the "proceed" element, and awaits
   the underlying negotiation process for transport security.

   When a BEEP peer receives a "proceed" element in reply to its "ready"
   message, it implicitly closes all channels (including channel zero),