rfc3080.txt

最新的RFC

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


   There are two kinds of frames: data and mapping.  Each transport
   mapping (c.f., Section 2.5) may define its own frames.  For example,
   [5] defines the SEQ frame.  The remainder of this section discusses
   data frames.

   When a message is segmented and sent as several frames, those frames
   must be sent sequentially, without any intervening frames from other
   messages on the same channel.  However, there are two exceptions:
   first, no restriction is made with respect to the interleaving of
   frames for other channels; and, second, in a one-to-many exchange,
   multiple answers may be simultaneously in progress.  Accordingly,
   frames for "ANS" messages may be interleaved on the same channel --
   the answer number is used for collation, e.g.,

       S: ANS 1 0 * 0 20 0
       S:     ...
       S:     ...
       S: END
       S: ANS 1 0 * 20 20 1
       S:     ...
       S:     ...
       S: END
       S: ANS 1 0 . 40 10 0
       S:     ...
       S: END

   which shows two "ANS" messages interleaved on channel 1 as part of a
   reply to message number 0.  Note that the sequence number is advanced
   for each frame sent on the channel, and is independent of the
   messages sent in those frames.





















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


   There are several rules for identifying poorly-formed frames:

   o  if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or
      "NUL";

   o  if any of the parameters in the header cannot be determined or are
      invalid (i.e., syntactically incorrect);

   o  if the value of the channel number doesn't refer to an existing
      channel;

   o  if the header starts with "MSG", and the message number refers to
      a "MSG" message that has been completely received but for which a
      reply has not been completely sent;

   o  if the header doesn't start with "MSG", and refers to a message
      number for which a reply has already been completely received;

   o  if the header doesn't start with "MSG", and refers to a message
      number that has never been sent (except during session
      establishment, c.f., Section 2.3.1.1);

   o  if the header starts with "MSG", "RPY", "ERR", or "ANS", and
      refers to a message number for which at least one other frame has
      been received, and the three-character keyword starting this frame
      and the immediately-previous received frame for this message
      number are not identical;

   o  if the header starts with "NUL", and refers to a message number
      for which at least one other frame has been received, and the
      keyword of of the immediately-previous received frame for this
      reply isn't "ANS";

   o  if the continuation indicator of the previous frame received on
      the same channel was intermediate ("*"), and its message number
      isn't identical to this frame's message number;

   o  if the value of the sequence number doesn't correspond to the
      expected value for the associated channel (c.f., Section 2.2.1.2);
      or,

   o  if the header starts with "NUL", and the continuation indicator is
      intermediate ("*") or the payload size is non-zero.

   If a frame is poorly-formed, then the session is terminated without
   generating a response, and it is recommended that a diagnostic entry
   be logged.




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


2.2.1.2 Frame Payload

   The frame payload consists of zero or more octets.

   Every payload octet sent in each direction on a channel has an
   associated sequence number.  Numbering of payload octets within a
   frame is such that the first payload octet is the lowest numbered,
   and the following payload octets are numbered consecutively.  (When a
   channel is created, the sequence number associated with the first
   payload octet of the first frame is 0.)

   The actual sequence number space is finite, though very large,
   ranging from 0..4294967295 (2**32 - 1).  Since the space is finite,
   all arithmetic dealing with sequence numbers is performed modulo
   2**32.  This unsigned arithmetic preserves the relationship of
   sequence numbers as they cycle from 2**32 - 1 to 0 again.  Consult
   Sections 2 through 5 of [8] for a discussion of the arithmetic
   properties of sequence numbers.

   When receiving a frame, the sum of its sequence number and payload
   size, modulo 4294967296 (2**32), gives the expected sequence number
   associated with the first payload octet of the next frame received.
   Accordingly, when receiving a frame if the sequence number isn't the
   expected value for this channel, then the BEEP peers have lost
   synchronization, then the session is terminated without generating a
   response, and it is recommended that a diagnostic entry be logged.

























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


2.2.1.3 Frame Trailer

   The frame trailer consists of "END" followed by a CRLF pair.

   When receiving a frame, if the characters immediately following the
   payload don't correspond to a trailer, then the session is terminated
   without generating a response, and it is recommended that a
   diagnostic entry be logged.











































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


2.2.2 Frame Semantics

   The semantics of each message is channel-specific.  Accordingly, the
   profile associated with a channel must define:

   o  the initialization messages, if any, exchanged during channel
      creation;

   o  the messages that may be exchanged in the payload of the channel;
      and,

   o  the semantics of these messages.

   A profile registration template (Section 5.1) organizes this
   information.

2.2.2.1 Poorly-formed Messages

   When defining the behavior of the profile, the template must specify
   how poorly-formed "MSG" messages are replied to.  For example, the
   channel management profile sends a negative reply containing an error
   message (c.f., Section 2.3.1.5).

   If a poorly-formed reply is received on channel zero, the session is
   terminated without generating a response, and it is recommended that
   a diagnostic entry be logged.

   If a poorly-formed reply is received on another channel, then the
   channel must be closed using the procedure in Section 2.3.1.3.






















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


2.3 Channel Management

   When a BEEP session starts, only channel number zero is defined,
   which is used for channel management.  Section 6.1 contains the
   profile registration for BEEP channel management.

   Channel management allows each BEEP peer to advertise the profiles
   that it supports (c.f., Section 2.3.1.1), bind an instance of one of
   those profiles to a channel (c.f., Section 2.3.1.2), and then later
   close any channels or release the BEEP session (c.f., Section
   2.3.1.3).

   A BEEP peer should support at least 257 concurrent channels.






































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


2.3.1 Message Semantics

2.3.1.1 The Greeting Message

   When a BEEP session is established, each BEEP peer signifies its
   availability by immediately sending a positive reply with a message
   number of zero that contains a "greeting" element, 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

   Note that this example implies that the BEEP peer in the initiating
   role waits until the BEEP peer in the listening role sends its
   greeting -- this is an artifact of the presentation; in fact, both
   BEEP peers send their replies independently.

   The "greeting" element has two optional attributes ("features" and
   "localize") and zero or more "profile" elements, one for each profile
   supported by the BEEP peer acting in a server role:

   o  the "features" attribute, if present, contains one or more feature
      tokens, each indicating an optional feature of the channel
      management profile supported by the BEEP peer;

   o  the "localize" attribute, if present, contains one or more
      language tokens (defined in [9]), each identifying a desirable
      language tag to be used by the remote BEEP peer when generating
      textual diagnostics for the "close" and "error" elements (the
      tokens are ordered from most to least desirable); and,

   o  each "profile" element contained within the "greeting" element
      identifies a profile, and unlike the "profile" elements that occur
      within the "start" element, the content of each "profile" element
      may not contain an optional initialization message.

   Section 5.2 defines a registration template for optional features.



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


2.3.1.2 The Start Message

   When a BEEP peer wants to create a channel, it sends a "start"
   element on channel zero, e.g.,

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

   The "start" element has a "number" attribute, an optional
   "serverName" attribute, and one or more "profile" elements:

   o  the "number" attribute indicates the channel number (in the range
      1..2147483647) used to identify the channel in future messages;

   o  the "serverName" attribute, an arbitrary string, indicates the
      desired server name for this BEEP session; and,

   o  each "profile" element contained with the "start" element has a
      "uri" attribute, an optional "encoding" attribute, and arbitrary
      character data as content:

      *  the "uri" attribute authoritatively identifies the profile;

      *  the "encoding" attribute, if present, specifies whether the
         content of the "profile" element is represented as a base64-
         encoded string; and,

      *  the content of the "profile" element, if present, must be no
         longer than 4K octets in length and specifies an initialization
         message given to the channel as soon as it is created.

   To avoid conflict in assigning channel numbers when requesting the
   creation of a channel, BEEP peers acting in the initiating role use
   only positive integers that are odd-numbered; similarly, BEEP peers
   acting in the listening role use only positive integers that are
   even-numbered.

   The "serverName" attribute for the first successful "start" element
   received by a BEEP peer is meaningful for the duration of the BEEP
   session.  If present, the BEEP peer decides whether to operate as the
   indicated "serverName"; if not, an "error" element is sent in a
   negative reply.




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


   When a BEEP peer receives a "start" element on channel zero, it
   examines each of the proposed profiles, and decides whether to use
   one of them to create the channel.  If so, the appropriate "profile"
   element is sent in a positive reply; otherwise, an "error" element is
   sent in a negative reply.

   When creating the channel, the value of the "serverName" attribute
   from the first successful "start" element is consulted to provide
   configuration information, e.g., the desired server-side certificate
   when starting the TLS transport security profile (Section 3.1).

   For example, a successful channel creation might look like this:

       C: MSG 0 1 . 52 178
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/SASL/OTP' />
       C:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
       C: </start>
       C: END
       S: RPY 0 1 . 221 87
       S: Content-Type: application/beep+xml
       S:
       S: <profile uri='http://iana.org/beep/SASL/OTP' />
       S: END

   Similarly, an unsuccessful channel creation might look like this:

       C: MSG 0 1 . 52 120
       C: Content-Type: application/beep+xml
       C:
       C: <start number='2'>
       C:    <profile uri='http://iana.org/beep/SASL/OTP' />
       C: </start>
       C: END
       S: ERR 0 1 . 221 127
       S: Content-Type: application/beep+xml
       S:
       S: <error code='501'>number attribute