rfc3080.txt

最新的RFC

Network Working Group                                            M. Rose
Request For Comments: 3080                        Invisible Worlds, Inc.
Category: Standards Track                                     March 2001


              The Blocks Extensible Exchange Protocol Core

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This memo describes a generic application protocol kernel for
   connection-oriented, asynchronous interactions called the BEEP
   (Blocks Extensible Exchange Protocol) core.  BEEP permits
   simultaneous and independent exchanges within the context of a single
   application user-identity, supporting both textual and binary
   messages.
























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


Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  4
   2.      The BEEP Core  . . . . . . . . . . . . . . . . . . . . . .  5
   2.1     Roles  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.1.1   Exchange Styles  . . . . . . . . . . . . . . . . . . . . .  6
   2.2     Messages and Frames  . . . . . . . . . . . . . . . . . . .  7
   2.2.1   Frame Syntax . . . . . . . . . . . . . . . . . . . . . . .  8
   2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . .  9
   2.2.1.2 Frame Payload  . . . . . . . . . . . . . . . . . . . . . . 12
   2.2.1.3 Frame Trailer  . . . . . . . . . . . . . . . . . . . . . . 13
   2.2.2   Frame Semantics  . . . . . . . . . . . . . . . . . . . . . 14
   2.2.2.1 Poorly-formed Messages . . . . . . . . . . . . . . . . . . 14
   2.3     Channel Management . . . . . . . . . . . . . . . . . . . . 15
   2.3.1   Message Semantics  . . . . . . . . . . . . . . . . . . . . 16
   2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16
   2.3.1.2 The Start Message  . . . . . . . . . . . . . . . . . . . . 17
   2.3.1.3 The Close Message  . . . . . . . . . . . . . . . . . . . . 20
   2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 23
   2.3.1.5 The Error Message  . . . . . . . . . . . . . . . . . . . . 23
   2.4     Session Establishment and Release  . . . . . . . . . . . . 25
   2.5     Transport Mappings . . . . . . . . . . . . . . . . . . . . 27
   2.5.1   Session Management . . . . . . . . . . . . . . . . . . . . 27
   2.5.2   Message Exchange . . . . . . . . . . . . . . . . . . . . . 27
   2.6     Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . 28
   2.6.1   Within a Single Channel  . . . . . . . . . . . . . . . . . 28
   2.6.2   Between Different Channels . . . . . . . . . . . . . . . . 28
   2.6.3   Pre-emptive Replies  . . . . . . . . . . . . . . . . . . . 29
   2.6.4   Interference . . . . . . . . . . . . . . . . . . . . . . . 29
   2.7     Peer-to-Peer Behavior  . . . . . . . . . . . . . . . . . . 30
   3.      Transport Security . . . . . . . . . . . . . . . . . . . . 31
   3.1     The TLS Transport Security Profile . . . . . . . . . . . . 34
   3.1.1   Profile Identification and Initialization  . . . . . . . . 34
   3.1.2   Message Syntax . . . . . . . . . . . . . . . . . . . . . . 35
   3.1.3   Message Semantics  . . . . . . . . . . . . . . . . . . . . 36
   3.1.3.1 The Ready Message  . . . . . . . . . . . . . . . . . . . . 36
   3.1.3.2 The Proceed Message  . . . . . . . . . . . . . . . . . . . 36
   4.      User Authentication  . . . . . . . . . . . . . . . . . . . 37
   4.1     The SASL Family of Profiles  . . . . . . . . . . . . . . . 38
   4.1.1   Profile Identification and Initialization  . . . . . . . . 39
   4.1.2   Message Syntax . . . . . . . . . . . . . . . . . . . . . . 42
   4.1.3   Message Semantics  . . . . . . . . . . . . . . . . . . . . 43
   5.      Registration Templates . . . . . . . . . . . . . . . . . . 44
   5.1     Profile Registration Template  . . . . . . . . . . . . . . 44
   5.2     Feature Registration Template  . . . . . . . . . . . . . . 44
   6.      Initial Registrations  . . . . . . . . . . . . . . . . . . 45
   6.1     Registration: BEEP Channel Management  . . . . . . . . . . 45
   6.2     Registration: TLS Transport Security Profile . . . . . . . 45



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


   6.3     Registration: SASL Family of Profiles  . . . . . . . . . . 46
   6.4     Registration: application/beep+xml . . . . . . . . . . . . 47
   7.      DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
   7.1     BEEP Channel Management DTD  . . . . . . . . . . . . . . . 48
   7.2     TLS Transport Security Profile DTD . . . . . . . . . . . . 50
   7.3     SASL Family of Profiles DTD  . . . . . . . . . . . . . . . 51
   8.      Reply Codes  . . . . . . . . . . . . . . . . . . . . . . . 52
   9.      Security Considerations  . . . . . . . . . . . . . . . . . 53
           References . . . . . . . . . . . . . . . . . . . . . . . . 54
           Author's Address . . . . . . . . . . . . . . . . . . . . . 55
   A.      Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56
   B.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 57
           Full Copyright Statement . . . . . . . . . . . . . . . . . 58






































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


1. Introduction

   This memo describes a generic application protocol kernel for
   connection-oriented, asynchronous interactions called BEEP.

   At BEEP's core is a framing mechanism that permits simultaneous and
   independent exchanges of messages between peers.  Messages are
   arbitrary MIME [1] content, but are usually textual (structured using
   XML [2]).

   All exchanges occur in the context of a channel -- a binding to a
   well-defined aspect of the application, such as transport security,
   user authentication, or data exchange.

   Each channel has an associated "profile" that defines the syntax and
   semantics of the messages exchanged.  Implicit in the operation of
   BEEP is the notion of channel management.  In addition to defining
   BEEP's channel management profile, this document defines:

   o  the TLS [3] transport security profile; and,

   o  the SASL [4] family of profiles.

   Other profiles, such as those used for data exchange, are defined by
   an application protocol designer.


























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


2. The BEEP Core

   A BEEP session is mapped onto an underlying transport service.  A
   separate series of documents describe how a particular transport
   service realizes a BEEP session.  For example, [5] describes how a
   BEEP session is mapped onto a single TCP [6] connection.

   When a session is established, each BEEP peer advertises the profiles
   it supports.  Later on, during the creation of a channel, the client
   supplies one or more proposed profiles for that channel.  If the
   server creates the channel, it selects one of the profiles and sends
   it in a reply; otherwise, it may indicate that none of the profiles
   are acceptable, and decline creation of the channel.

   Channel usage falls into one of two categories:

   initial tuning: these are used by profiles that perform
      initialization once the BEEP session is established (e.g.,
      negotiating the use of transport security); although several
      exchanges may be required to perform the initialization, these
      channels become inactive early in the BEEP session and remain so
      for the duration.

   continuous: these are used by profiles that support data exchange;
      typically, these channels are created after the initial tuning
      channels have gone quiet.

   Note that because of their special nature, only one tuning channel
   may be established at any given time; in contrast, BEEP allows
   multiple data exchange channels to be simultaneously in use.





















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


2.1 Roles

   Although BEEP is peer-to-peer, it is convenient to label each peer in
   the context of the role it is performing at a given time:

   o  When a BEEP session is established, the peer that awaits new
      connections is acting in the listening role, and the other peer,
      which establishes a connection to the listener, is acting in the
      initiating role.  In the examples which follow, these are referred
      to as "L:" and "I:", respectively.

   o  A BEEP peer starting an exchange is termed the client; similarly,
      the other BEEP peer is termed the server.  In the examples which
      follow, these are referred to as "C:" and "S:", respectively.

   Typically, a BEEP peer acting in the server role is also acting in a
   listening role.  However, because BEEP is peer-to-peer in nature, no
   such requirement exists.

2.1.1 Exchange Styles

   BEEP allows three styles of exchange:

   MSG/RPY: the client sends a "MSG" message asking the server to
      perform some task, the server performs the task and replies with a
      "RPY" message (termed a positive reply).

   MSG/ERR: the client sends a "MSG" message, the server does not
      perform any task and replies with an "ERR" message (termed a
      negative reply).

   MSG/ANS: the client sends a "MSG" message, the server, during the
      course of performing some task, replies with zero or more "ANS"
      messages, and, upon completion of the task, sends a "NUL" message,
      which signifies the end of the reply.

   The first two styles are termed one-to-one exchanges, whilst the
   third style is termed a one-to-many exchange.













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


2.2 Messages and Frames

   A message is structured according to the rules of MIME.  Accordingly,
   each message may begin with "entity-headers" (c.f., MIME's Section 3
   [1]).  If none, or only some, of the "entity-headers" are present:

   o  the default "Content-Type" is "application/octet-stream"; and,

   o  the default "Content-Transfer-Encoding" is "binary".

   Normally, a message is sent in a single frame.  However, it may be
   convenient or necessary to segment a message into multiple frames
   (e.g., if only part of a message is ready to be sent).

   Each frame consists of a header, the payload, and a trailer.  The
   header and trailer are each represented using printable ASCII
   characters and are terminated with a CRLF pair.  Between the header
   and the trailer is the payload, consisting of zero or more octets.

   For example, here is a message contained in a single frame that
   contains a payload of 120 octets spread over 5 lines (each line is
   terminated with a CRLF pair):

       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

   In this example, note that the entire message is represented in a
   single frame.


















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


2.2.1 Frame Syntax

   The ABNF [7] for a frame is:

   frame      = data / mapping

   data       = header payload trailer

   header     = msg / rpy / err / ans / nul

   msg        = "MSG" SP common          CR LF
   rpy        = "RPY" SP common          CR LF
   ans        = "ANS" SP common SP ansno CR LF
   err        = "ERR" SP common          CR LF
   nul        = "NUL" SP common          CR LF

   common     = channel SP msgno SP more SP seqno SP size
   channel    = 0..2147483647
   msgno      = 0..2147483647
   more       = "." / "*"
   seqno      = 0..4294967295
   size       = 0..2147483647
   ansno      = 0..2147483647

   payload    = *OCTET

   trailer    = "END" CR LF

   mapping    = ;; each transport mapping may define additional frames






















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


2.2.1.1 Frame Header

   The frame header consists of a three-character keyword (one of:
   "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more
   parameters.  A single space character (decimal code 32, " ")
   separates each component.  The header is terminated with a CRLF pair.

   The channel number ("channel") must be a non-negative integer (in the
   range 0..2147483647).

   The message number ("msgno") must be a non-negative integer (in the
   range 0..2147483647) and have a different value than all other "MSG"
   messages on the same channel for which a reply has not been
   completely received.

   The continuation indicator ("more", one of: decimal code 42, "*", or
   decimal code 46, ".") specifies whether this is the final frame of
   the message:

      intermediate ("*"): at least one other frame follows for the
      message; or,

      complete ("."): this frame completes the message.

   The sequence number ("seqno") must be a non-negative integer (in the
   range 0..4294967295) and specifies the sequence number of the first
   octet in the payload, for the associated channel (c.f., Section
   2.2.1.2).

   The payload size ("size") must be a non-negative integer (in the
   range 0..2147483647) and specifies the exact number of octets in the
   payload.  (This does not include either the header or trailer.)

   Note that a frame may have an empty payload, e.g.,

       S: RPY 0 1 * 287 20
       S:     ...
       S:     ...
       S: END
       S: RPY 0 1 . 307 0
       S: END

   The answer number ("ansno") must be a non-negative integer (in the
   range 0..4294967295) and must have a different value than all other
   answers in progress for the message being replied to.