rfc3080.txt

最新的RFC

       S: in &lt;start&gt; element must be odd-valued</error>
       S: END









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


   Finally, here's an example in which an initialization element is
   exchanged during channel creation:

       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 19]

RFC 3080                     The BEEP Core                    March 2001


2.3.1.3 The Close Message

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

       C: MSG 0 2 . 235 71
       C: Content-Type: application/beep+xml
       C:
       C: <close number='1' code='200' />
       C: END

   The "close" element has a "number" attribute, a "code" attribute, an
   optional "xml:lang" attribute, and an optional textual diagnostic as
   its content:

   o  the "number" attribute indicates the channel number;

   o  the "code" attribute is a three-digit reply code meaningful to
      programs (c.f., Section 8);

   o  the "xml:lang" attribute identifies the language that the
      element's content is written in (the value is suggested, but not
      mandated, by the "localize" attribute of the "greeting" element
      sent by the remote BEEP peer); and,

   o  the textual diagnostic (which may be multiline) is meaningful to
      implementers, perhaps administrators, and possibly even users, but
      never programs.

   Note that if the textual diagnostic is present, then the "xml:lang"
   attribute is absent only if the language indicated as the remote BEEP
   peer's first choice is used.

   If the value of the "number" attribute is zero, then the BEEP peer
   wants to release the BEEP session (c.f., Section 2.4) -- otherwise
   the value of the "number" attribute refers to an existing channel,
   and the remainder of this section applies.

   A BEEP peer may send a "close" message for a channel whenever all
   "MSG" messages it has sent on that channel have been acknowledged.
   (Acknowledgement consists of the first frame of a reply being
   received by the BEEP peer that sent the MSG "message".)

   After sending the "close" message, that BEEP peer must not send any
   more "MSG" messages on that channel being closed until the reply to
   the "close" message has been received (either by an "error" message
   rejecting the request to close the channel, or by an "ok" message
   subsequently followed by the channel being successfully started).



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


   NOTE WELL: until a positive reply to the request to close the channel
   is received, the BEEP peer must be prepared to process any "MSG"
   messages that it receives on that channel.

   When a BEEP peer receives a "close" message for a channel, it may, at
   any time, reject the request to close the channel by sending an
   "error" message in a negative reply.

   Otherwise, before accepting the request to close the channel, and
   sending an "ok" message in a positive reply, it must:

   o  finish sending any queued "MSG" messages on that channel of its
      own;

   o  await complete replies to any outstanding "MSG" messages it has
      sent on that channel; and,

   o  finish sending complete replies to any outstanding "MSG" messages
      it has received on that channel, and ensure that the final frames
      of those replies have been successfully delivered, i.e.,

      *  for transport mappings that guarantee inter-channel ordering of
         messages, the replies must be sent prior to sending the "ok"
         message in a positive reply; otherwise,

      *  the replies must be sent and subsequently acknowledged by the
         underlying transport service prior to sending the "ok" message
         in a positive reply.























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


   Briefly, a successful channel close might look like this:

       C: MSG 0 2 . 235 71
       C: Content-Type: application/beep+xml
       C:
       C: <close number='1' code='200' />
       C: END
       S: RPY 0 2 . 392 46
       S: Content-Type: application/beep+xml
       S:
       S: <ok />
       S: END

   Similarly, an unsuccessful channel close might look like this:

       C: MSG 0 2 . 235 71
       C: Content-Type: application/beep+xml
       C:
       C: <close number='1' code='200' />
       C: END
       S: ERR 0 2 . 392 79
       S: Content-Type: application/beep+xml
       S:
       S: <error code='550'>still working</error>
       S: END


























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


2.3.1.4 The OK Message

   When a BEEP peer agrees to close a channel (or release the BEEP
   session), it sends an "ok" element in a positive reply.

   The "ok" element has no attributes and no content.

2.3.1.5 The Error Message

   When a BEEP peer declines the creation of a channel, it sends an
   "error" element in a negative reply, e.g.,

       I: MSG 0 1 . 52 115
       I: Content-Type: application/beep+xml
       I:
       I: <start number='2'>
       I:    <profile uri='http://iana.org/beep/FOO' />
       I: </start>
       I: END
       L: ERR 0 1 . 221 105
       L: Content-Type: application/beep+xml
       L:
       L: <error code='550'>all requested profiles are
       L: unsupported</error>
       L: END

   The "error" element has a "code" attribute, an optional "xml:lang"
   attribute, and an optional textual diagnostic as its content:

   o  the "code" attribute is a three-digit reply code meaningful to
      programs (c.f., Section 8);

   o  the "xml:lang" attribute identifies the language that the
      element's content is written in (the value is suggested, but not
      mandated, by the "localize" attribute of the "greeting" element
      sent by the remote BEEP peer); and,

   o  the textual diagnostic (which may be multiline) is meaningful to
      implementers, perhaps administrators, and possibly even users, but
      never programs.

   Note that if the textual diagnostic is present, then the "xml:lang"
   attribute is absent only if the language indicated as the remote BEEP
   peer's first choice is used.







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


   In addition, a BEEP peer sends an "error" element whenever:

   o  it receives a "MSG" message containing a poorly-formed or
      unexpected element;

   o  it receives a "MSG" message asking to close a channel (or release
      the BEEP session) and it declines to do so; or

   o  a BEEP session is established, the BEEP peer is acting in the
      listening role, and that BEEP peer is unavailable (in this case,
      the BEEP acting in the listening role does not send a "greeting"
      element).

   In the final case, both BEEP peers terminate the session, and it is
   recommended that a diagnostic entry be logged by both BEEP peers.




































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


2.4 Session Establishment and Release

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

   Alternatively, if the BEEP peer acting in the listening role is
   unavailable, it sends a negative reply, e.g.,

       L: <wait for incoming connection>
       I: <open connection>
       L: ERR 0 0 . 0 60
       L: Content-Type: application/beep+xml
       L:
       L: <error code='421' />
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END
       I: <close connection>
       L: <close connection>
       L: <wait for next connection>

   and the "greeting" element sent by the BEEP peer acting in the
   initiating role is ignored.  It is recommended that a diagnostic
   entry be logged by both BEEP peers.







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


   Note that both of these examples imply 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.

   When a BEEP peer wants to release the BEEP session, it sends a
   "close" element with a zero-valued "number" attribute on channel
   zero.  The other BEEP peer indicates its willingness by sending an
   "ok" element in a positive reply, e.g.,

       C: MSG 0 1 . 52 60
       C: Content-Type: application/beep+xml
       C:
       C: <close code='200' />
       C: END
       S: RPY 0 1 . 264 46
       S: Content-Type: application/beep+xml
       S:
       S: <ok />
       S: END
       I: <close connection>
       L: <close connection>
       L: <wait for next connection>

   Alternatively, if the other BEEP doesn't want to release the BEEP
   session, the exchange might look like this:

       C: MSG 0 1 . 52 60
       C: Content-Type: application/beep+xml
       C:
       C: <close code='200' />
       C: END
       S: ERR 0 1 . 264 79
       S: Content-Type: application/beep+xml
       S:
       S: <error code='550'>still working</error>
       S: END

   If session release is declined, the BEEP session should not be
   terminated, if possible.











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


2.5 Transport Mappings

   All transport interactions occur in the context of a session -- a
   mapping onto a particular transport service.  Accordingly, this memo
   defines the requirements that must be satisfied by any document
   describing how a particular transport service realizes a BEEP
   session.

2.5.1 Session Management

   A BEEP session is connection-oriented.  A mapping document must
   define:

   o  how a BEEP session is established;

   o  how a BEEP peer is identified as acting in the listening role;

   o  how a BEEP peer is identified as acting in the initiating role;

   o  how a BEEP session is released; and,

   o  how a BEEP session is terminated.


2.5.2 Message Exchange

   A BEEP session is message-oriented.  A mapping document must define:

   o  how messages are reliably sent and received;

   o  how messages on the same channel are received in the same order as
      they were sent; and,

   o  how messages on different channels are sent without ordering
      constraint.