As per Relevance of the word standards, we have this rfc below:
Network Working Group M.
Request For Comments: 3080 Invisible Worlds, Inc
Category: Standards Track March 2001
The Blocks Extensible Exchange Protocol
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This memo describes a generic application protocol kernel
connection-oriented, asynchronous interactions called the
(Blocks Extensible Exchange Protocol) core. BEEP
simultaneous and independent exchanges within the context of a
application user-identity, supporting both textual and
messages
Rose Standards Track [Page 1]
RFC 3080 The BEEP Core March 2001
Table of
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.
This memo describes a generic application protocol kernel
connection-oriented, asynchronous interactions called BEEP
At BEEP's core is a framing mechanism that permits simultaneous
independent exchanges of messages between peers. Messages
arbitrary MIME [1] content, but are usually textual (structured
XML [2]).
All exchanges occur in the context of a channel -- a binding to
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
semantics of the messages exchanged. Implicit in the operation
BEEP is the notion of channel management. In addition to
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
an application protocol designer
Rose Standards Track [Page 4]
RFC 3080 The BEEP Core March 2001
2. The BEEP
A BEEP session is mapped onto an underlying transport service.
separate series of documents describe how a particular
service realizes a BEEP session. For example, [5] describes how
BEEP session is mapped onto a single TCP [6] connection
When a session is established, each BEEP peer advertises the
it supports. Later on, during the creation of a channel, the
supplies one or more proposed profiles for that channel. If
server creates the channel, it selects one of the profiles and
it in a reply; otherwise, it may indicate that none of the
are acceptable, and decline creation of the channel
Channel usage falls into one of two categories
initial tuning: these are used by profiles that
initialization once the BEEP session is established (e.g.,
negotiating the use of transport security); although
exchanges may be required to perform the initialization,
channels become inactive early in the BEEP session and remain
for the duration
continuous: these are used by profiles that support data exchange
typically, these channels are created after the initial
channels have gone quiet
Note that because of their special nature, only one tuning
may be established at any given time; in contrast, BEEP
multiple data exchange channels to be simultaneously in use
Rose Standards Track [Page 5]
RFC 3080 The BEEP Core March 2001
2.1
Although BEEP is peer-to-peer, it is convenient to label each peer
the context of the role it is performing at a given time
o When a BEEP session is established, the peer that awaits
connections is acting in the listening role, and the other peer
which establishes a connection to the listener, is acting in
initiating role. In the examples which follow, these are
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
follow, these are referred to as "C:" and "S:", respectively
Typically, a BEEP peer acting in the server role is also acting in
listening role. However, because BEEP is peer-to-peer in nature,
such requirement exists
2.1.1 Exchange
BEEP allows three styles of exchange
MSG/RPY: the client sends a "MSG" message asking the server
perform some task, the server performs the task and replies with
"RPY" message (termed a positive reply).
MSG/ERR: the client sends a "MSG" message, the server does
perform any task and replies with an "ERR" message (termed
negative reply).
MSG/ANS: the client sends a "MSG" message, the server, during
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
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
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
convenient or necessary to segment a message into multiple
(e.g., if only part of a message is ready to be sent).
Each frame consists of a header, the payload, and a trailer.
header and trailer are each represented using printable
characters and are terminated with a CRLF pair. Between the
and the trailer is the payload, consisting of zero or more octets
For example, here is a message contained in a single frame
contains a payload of 120 octets spread over 5 lines (each line
terminated with a CRLF pair):
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+
C
C:
C:
C:
C:
In this example, note that the entire message is represented in
single frame
Rose Standards Track [Page 7]
RFC 3080 The BEEP Core March 2001
2.2.1 Frame
The ABNF [7] for a frame is
frame = data /
data = header payload
header = msg / rpy / err / ans /
msg = "MSG" SP common CR
rpy = "RPY" SP common CR
ans = "ANS" SP common SP ansno CR
err = "ERR" SP common CR
nul = "NUL" SP common CR
common = channel SP msgno SP more SP seqno SP
channel = 0..2147483647
msgno = 0..2147483647
more = "." / "*"
seqno = 0..4294967295
size = 0..2147483647
ansno = 0..2147483647
payload = *
trailer = "END" CR
mapping = ;; each transport mapping may define additional
Rose Standards Track [Page 8]
RFC 3080 The BEEP Core March 2001
2.2.1.1 Frame
The frame header consists of a three-character keyword (one of
"MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or
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
range 0..2147483647).
The message number ("msgno") must be a non-negative integer (in
range 0..2147483647) and have a different value than all other "MSG
messages on the same channel for which a reply has not
completely received
The continuation indicator ("more", one of: decimal code 42, "*",
decimal code 46, ".") specifies whether this is the final frame
the message
intermediate ("*"): at least one other frame follows for
message; or
complete ("."): this frame completes the message
The sequence number ("seqno") must be a non-negative integer (in
range 0..4294967295) and specifies the sequence number of the
octet in the payload, for the associated channel (c.f.,
2.2.1.2).
The payload size ("size") must be a non-negative integer (in
range 0..2147483647) and specifies the exact number of octets in
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:
S: RPY 0 1 . 307 0
S:
The answer number ("ansno") must be a non-negative integer (in
range 0..4294967295) and must have a different value than all
answers in progress for the message being replied to
Rose Standards Track [Page 9]
RFC 3080 The BEEP Core March 2001
There are two kinds of frames: data and mapping. Each
mapping (c.f., Section 2.5) may define its own frames. For example
[5] defines the SEQ frame. The remainder of this section
data frames
When a message is segmented and sent as several frames, those
must be sent sequentially, without any intervening frames from
messages on the same channel. However, there are two exceptions
first, no restriction is made with respect to the interleaving
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:
S: ANS 1 0 * 20 20 1
S: ...
S: ...
S:
S: ANS 1 0 . 40 10 0
S: ...
S:
which shows two "ANS" messages interleaved on channel 1 as part of
reply to message number 0. Note that the sequence number is
for each frame sent on the channel, and is independent of
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",
"NUL";
o if any of the parameters in the header cannot be determined or
invalid (i.e., syntactically incorrect);
o if the value of the channel number doesn't refer to an
channel
o if the header starts with "MSG", and the message number refers
a "MSG" message that has been completely received but for which
reply has not been completely sent
o if the header doesn't start with "MSG", and refers to a
number for which a reply has already been completely received
o if the header doesn't start with "MSG", and refers to a
number that has never been sent (except during
establishment, c.f., Section 2.3.1.1);
o if the header starts with "MSG", "RPY", "ERR", or "ANS",
refers to a message number for which at least one other frame
been received, and the three-character keyword starting this
and the immediately-previous received frame for this
number are not identical
o if the header starts with "NUL", and refers to a message
for which at least one other frame has been received, and
keyword of of the immediately-previous received frame for
reply isn't "ANS";
o if the continuation indicator of the previous frame received
the same channel was intermediate ("*"), and its message
isn't identical to this frame's message number
o if the value of the sequence number doesn't correspond to
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
intermediate ("*") or the payload size is non-zero
If a frame is poorly-formed, then the session is terminated
generating a response, and it is recommended that a diagnostic
be logged
Rose Standards Track [Page 11]
RFC 3080 The BEEP Core March 2001
2.2.1.2 Frame
The frame payload consists of zero or more octets
Every payload octet sent in each direction on a channel has
associated sequence number. Numbering of payload octets within
frame is such that the first payload octet is the lowest numbered
and the following payload octets are numbered consecutively. (When
channel is created, the sequence number associated with the
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
2**32. This unsigned arithmetic preserves the relationship
sequence numbers as they cycle from 2**32 - 1 to 0 again.
Sections 2 through 5 of [8] for a discussion of the
properties of sequence numbers
When receiving a frame, the sum of its sequence number and
size, modulo 4294967296 (2**32), gives the expected sequence
associated with the first payload octet of the next frame received
Accordingly, when receiving a frame if the sequence number isn't
expected value for this channel, then the BEEP peers have
synchronization, then the session is terminated without generating
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
The frame trailer consists of "END" followed by a CRLF pair
When receiving a frame, if the characters immediately following
payload don't correspond to a trailer, then the session is
without generating a response, and it is recommended that
diagnostic entry be logged
Rose Standards Track [Page 13]
RFC 3080 The BEEP Core March 2001
2.2.2 Frame
The semantics of each message is channel-specific. Accordingly,
profile associated with a channel must define
o the initialization messages, if any, exchanged during
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
information
2.2.2.1 Poorly-formed
When defining the behavior of the profile, the template must
how poorly-formed "MSG" messages are replied to. For example,
channel management profile sends a negative reply containing an
message (c.f., Section 2.3.1.5).
If a poorly-formed reply is received on channel zero, the session
terminated without generating a response, and it is recommended
a diagnostic entry be logged
If a poorly-formed reply is received on another channel, then
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
When a BEEP session starts, only channel number zero is defined
which is used for channel management. Section 6.1 contains
profile registration for BEEP channel management
Channel management allows each BEEP peer to advertise the
that it supports (c.f., Section 2.3.1.1), bind an instance of one
those profiles to a channel (c.f., Section 2.3.1.2), and then
close any channels or release the BEEP session (c.f.,
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
2.3.1.1 The Greeting
When a BEEP session is established, each BEEP peer signifies
availability by immediately sending a positive reply with a
number of zero that contains a "greeting" element, e.g.,
L: incoming connection
I: connection
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+
L
L:
L:
L:
L:
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+
I
I:
I:
Note that this example implies that the BEEP peer in the
role waits until the BEEP peer in the listening role sends
greeting -- this is an artifact of the presentation; in fact,
BEEP peers send their replies independently
The "greeting" element has two optional attributes ("features"
"localize") and zero or more "profile" elements, one for each
supported by the BEEP peer acting in a server role
o the "features" attribute, if present, contains one or more
tokens, each indicating an optional feature of the
management profile supported by the BEEP peer
o the "localize" attribute, if present, contains one or
language tokens (defined in [9]), each identifying a
language tag to be used by the remote BEEP peer when
textual diagnostics for the "close" and "error" elements (
tokens are ordered from most to least desirable); and
o each "profile" element contained within the "greeting"
identifies a profile, and unlike the "profile" elements that
within the "start" element, the content of each "profile"
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
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+
C
C:
C:
C:
C:
The "start" element has a "number" attribute, an
"serverName" attribute, and one or more "profile" elements
o the "number" attribute indicates the channel number (in the
1..2147483647) used to identify the channel in future messages
o the "serverName" attribute, an arbitrary string, indicates
desired server name for this BEEP session; and
o each "profile" element contained with the "start" element has
"uri" attribute, an optional "encoding" attribute, and
character data as content
* the "uri" attribute authoritatively identifies the profile
* the "encoding" attribute, if present, specifies whether
content of the "profile" element is represented as a base64-
encoded string; and
* the content of the "profile" element, if present, must be
longer than 4K octets in length and specifies an
message given to the channel as soon as it is created
To avoid conflict in assigning channel numbers when requesting
creation of a channel, BEEP peers acting in the initiating role
only positive integers that are odd-numbered; similarly, BEEP
acting in the listening role use only positive integers that
even-numbered
The "serverName" attribute for the first successful "start"
received by a BEEP peer is meaningful for the duration of the
session. If present, the BEEP peer decides whether to operate as
indicated "serverName"; if not, an "error" element is sent in
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,
examines each of the proposed profiles, and decides whether to
one of them to create the channel. If so, the appropriate "profile
element is sent in a positive reply; otherwise, an "error" element
sent in a negative reply
When creating the channel, the value of the "serverName"
from the first successful "start" element is consulted to
configuration information, e.g., the desired server-side
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+
C
C:
C:
C:
C:
C:
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+
S
S:
S:
Similarly, an unsuccessful channel creation might look like this
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+
C
C:
C:
C:
C:
S: ERR 0 1 . 221 127
S: Content-Type: application/beep+
S
S: number
S: in <start> element must be odd-valued
S:
Rose Standards Track [Page 18]
RFC 3080 The BEEP Core March 2001
Finally, here's an example in which an initialization element
exchanged during channel creation
C: MSG 0 1 . 52 158
C: Content-Type: application/beep+
C
C:
C:
C: ]]>
C:
C:
C:
S: RPY 0 1 . 110 121
S: Content-Type: application/beep+
S
S:
S: ]]>
S:
S:
Rose Standards Track [Page 19]
RFC 3080 The BEEP Core March 2001
2.3.1.3 The Close
When a BEEP peer wants to close a channel, it sends a "close"
on channel zero, e.g.,
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+
C
C:
C:
The "close" element has a "number" attribute, a "code" attribute,
optional "xml:lang" attribute, and an optional textual diagnostic
its content
o the "number" attribute indicates the channel number
o the "code" attribute is a three-digit reply code meaningful
programs (c.f., Section 8);
o the "xml:lang" attribute identifies the language that
element's content is written in (the value is suggested, but
mandated, by the "localize" attribute of the "greeting"
sent by the remote BEEP peer); and
o the textual diagnostic (which may be multiline) is meaningful
implementers, perhaps administrators, and possibly even users,
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
peer's first choice is used
If the value of the "number" attribute is zero, then the BEEP
wants to release the BEEP session (c.f., Section 2.4) --
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
"MSG" messages it has sent on that channel have been acknowledged
(Acknowledgement consists of the first frame of a reply
received by the BEEP peer that sent the MSG "message".)
After sending the "close" message, that BEEP peer must not send
more "MSG" messages on that channel being closed until the reply
the "close" message has been received (either by an "error"
rejecting the request to close the channel, or by an "ok"
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
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,
any time, reject the request to close the channel by sending
"error" message in a negative reply
Otherwise, before accepting the request to close the channel,
sending an "ok" message in a positive reply, it must
o finish sending any queued "MSG" messages on that channel of
own
o await complete replies to any outstanding "MSG" messages it
sent on that channel; and
o finish sending complete replies to any outstanding "MSG"
it has received on that channel, and ensure that the final
of those replies have been successfully delivered, i.e.,
* for transport mappings that guarantee inter-channel ordering
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
underlying transport service prior to sending the "ok"
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+
C
C:
C:
S: RPY 0 2 . 392 46
S: Content-Type: application/beep+
S
S:
S:
Similarly, an unsuccessful channel close might look like this
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+
C
C:
C:
S: ERR 0 2 . 392 79
S: Content-Type: application/beep+
S
S: still working
S:
Rose Standards Track [Page 22]
RFC 3080 The BEEP Core March 2001
2.3.1.4 The OK
When a BEEP peer agrees to close a channel (or release the
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
When a BEEP peer declines the creation of a channel, it sends
"error" element in a negative reply, e.g.,
I: MSG 0 1 . 52 115
I: Content-Type: application/beep+
I
I:
I:
I:
I:
L: ERR 0 1 . 221 105
L: Content-Type: application/beep+
L
L: all requested profiles
L: unsupported
L:
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
programs (c.f., Section 8);
o the "xml:lang" attribute identifies the language that
element's content is written in (the value is suggested, but
mandated, by the "localize" attribute of the "greeting"
sent by the remote BEEP peer); and
o the textual diagnostic (which may be multiline) is meaningful
implementers, perhaps administrators, and possibly even users,
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
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
unexpected element
o it receives a "MSG" message asking to close a channel (or
the BEEP session) and it declines to do so;
o a BEEP session is established, the BEEP peer is acting in
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
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
When a BEEP session is established, each BEEP peer signifies
availability by immediately sending a positive reply with a
number of zero on channel zero that contains a "greeting" element
e.g.,
L: incoming connection
I: connection
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+
L
L:
L:
L:
L:
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+
I
I:
I:
Alternatively, if the BEEP peer acting in the listening role
unavailable, it sends a negative reply, e.g.,
L: incoming connection
I: connection
L: ERR 0 0 . 0 60
L: Content-Type: application/beep+
L
L:
L:
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+
I
I:
I:
I: connection
L: connection
L: connection
and the "greeting" element sent by the BEEP peer acting in
initiating role is ignored. It is recommended that a
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
initiating role waits until the BEEP peer in the listening role
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
"close" element with a zero-valued "number" attribute on
zero. The other BEEP peer indicates its willingness by sending
"ok" element in a positive reply, e.g.,
C: MSG 0 1 . 52 60
C: Content-Type: application/beep+
C
C:
C:
S: RPY 0 1 . 264 46
S: Content-Type: application/beep+
S
S:
S:
I: connection
L: connection
L: connection
Alternatively, if the other BEEP doesn't want to release the
session, the exchange might look like this
C: MSG 0 1 . 52 60
C: Content-Type: application/beep+
C
C:
C:
S: ERR 0 1 . 264 79
S: Content-Type: application/beep+
S
S: still working
S:
If session release is declined, the BEEP session should not
terminated, if possible
Rose Standards Track [Page 26]
RFC 3080 The BEEP Core March 2001
2.5 Transport
All transport interactions occur in the context of a session --
mapping onto a particular transport service. Accordingly, this
defines the requirements that must be satisfied by any
describing how a particular transport service realizes a
session
2.5.1 Session
A BEEP session is connection-oriented. A mapping document
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
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
they were sent; and
o how messages on different channels are sent without
constraint
Rose Standards Track [Page 27]
RFC 3080 The BEEP Core March 2001
2.6
BEEP accommodates asynchronous interactions, both within a
channel and between separate channels. This feature
pipelining (intra-channel) and parallelism (inter-channel).
2.6.1 Within a Single
A BEEP peer acting in the client role may send multiple "MSG
messages on the same channel without waiting to receive
corresponding replies. This provides pipelining within a
channel
A BEEP peer acting in the server role must process all "MSG"
for a given channel in the same order as they are received. As
consequence, the BEEP peer must generate replies in the same order
the corresponding "MSG" messages are received on a given channel
Note that in one-to-many exchanges (c.f., Section 2.1.1), the
to the "MSG" message consists of zero or more "ANS" messages
by a "NUL" message. In this style of exchange, the "ANS"
comprising the reply may be interleaved. When the BEEP peer
in the server role signifies the end of the reply by generating
"NUL" message, it may then process the next "MSG" message
for that channel
2.6.2 Between Different
A BEEP peer acting in the client role may send multiple "MSG
messages on different channels without waiting to receive
corresponding replies. The channels operate independently,
parallel
A BEEP peer acting in the server role may process "MSG"
received on different channels in any order it chooses. As
consequence, although the replies for a given channel appear to
generated in the same order in which the corresponding "MSG"
are received, there is no ordering constraint for replies
different channels
Rose Standards Track [Page 28]
RFC 3080 The BEEP Core March 2001
2.6.3 Pre-emptive
A BEEP peer acting in the server role may send a negative
before it receives the final "MSG" frame of a message. If it
so, that BEEP peer is obliged to ignore any subsequent "MSG"
for that message, up to and including the final "MSG" frame
If a BEEP peer acting in the client role receives a negative
before it sends the final "MSG" frame for a message, then it
required to send a "MSG" frame with a continuation status of
(".") and having a zero-length payload
2.6.4
If the processing of a particular message has sequencing impacts
other messages (either intra-channel or inter-channel), then
corresponding profile should define this behavior, e.g., a
whose messages alter the underlying transport mapping
Rose Standards Track [Page 29]
RFC 3080 The BEEP Core March 2001
2.7 Peer-to-Peer
BEEP is peer-to-peer -- as such both peers must be prepared
receive all messages defined in this memo. Accordingly,
initiating BEEP peer capable of acting only in the client role
behave gracefully if it receives a "MSG" message. Accordingly,
profiles must provide an appropriate error message for replying
unexpected "MSG" messages
As a consequence of the peer-to-peer nature of BEEP, message
are unidirectionally-significant. That is, the message numbers
"MSG" messages sent by a BEEP peer acting in the initiating role
unrelated to the message numbers in "MSG" messages sent by a
peer acting in the listening role
For example, these two
I: MSG 0 1 . 52 120
I: Content-Type: application/beep+
I
I:
I:
I:
I:
L: MSG 0 1 . 221 116
L: Content-Type: application/beep+
L
L:
L:
L:
L:
refer to different messages sent on channel zero
Rose Standards Track [Page 30]
RFC 3080 The BEEP Core March 2001
3. Transport
When a BEEP session is established, plaintext transfer,
privacy, is provided. Accordingly, transport security in BEEP
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
service, a given transport security profile tends to be relevant to
single transport mapping (c.f., Section 2.5).
When a channel associated with transport security begins
underlying negotiation process, all channels (including channel zero
are closed on the BEEP session. Accordingly, upon completion of
negotiation process, regardless of its outcome, a new greeting
issued by both BEEP peers. (If the negotiation process fails,
either BEEP peer may instead terminate the session, and it
recommended that a diagnostic entry be logged.)
A BEEP peer may choose to issue different greetings based on
privacy is in use, e.g.,
L: incoming connection
I: connection
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+
L
L:
L:
L:
L:
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+
I
I:
I:
I: MSG 0 1 . 52 158
I: Content-Type: application/beep+
I
Rose Standards Track [Page 31]
RFC 3080 The BEEP Core March 2001
I:
I:
I: ]]>
I:
I:
I:
L: RPY 0 1 . 110 121
L: Content-Type: application/beep+
L
L:
L: ]]>
L:
L:
... successful transport security negotiation ...
L: RPY 0 0 . 0 221
L: Content-Type: application/beep+
L
L:
L:
L:
L:
L:
L:
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+
I
I:
I:
Of course, not all BEEP peers need be as single-minded
L: incoming connection
I: connection
L: RPY 0 0 . 0 268
L: Content-Type: application/beep+
L
L:
L:
L:
L:
L:
L:
L:
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+
I
Rose Standards Track [Page 32]
RFC 3080 The BEEP Core March 2001
I:
I:
I: MSG 0 1 . 52 158
I: Content-Type: application/beep+
I
I:
I:
I: ]]>
I:
I:
I:
L: RPY 0 1 . 268 121
L: Content-Type: application/beep+
L
L:
L: ]]>
L:
L:
... failed transport security negotiation ...
L: RPY 0 0 . 0 268
L: Content-Type: application/beep+
L
L:
L:
L:
L:
L:
L:
L:
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+
I
I:
I:
Rose Standards Track [Page 33]
RFC 3080 The BEEP Core March 2001
3.1 The TLS Transport Security
Section 6.2 contains the registration for this profile
3.1.1 Profile Identification and
The TLS transport security profile is identified as
http://iana.org/beep/
in the BEEP "profile" element during channel creation
During channel creation, the corresponding "profile" element in
BEEP "start" element may contain a "ready" element. If
creation is successful, then before sending the corresponding reply
the BEEP peer processes the "ready" element and includes
resulting response in the reply, e.g.,
C: MSG 0 1 . 52 158
C: Content-Type: application/beep+
C
C:
C:
C: ]]>
C:
C:
C:
S: RPY 0 1 . 110 121
S: Content-Type: application/beep+
S
S:
S: ]]>
S:
S:
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
encapsulated operation to fail, e.g.,
C: MSG 0 1 . 52 173
C: Content-Type: application/beep+
C
C:
C:
C: ]]>
C:
C:
C:
S: RPY 0 1 . 110 193
S: Content-Type: application/beep+
S
S:
S: version
S: poorly formed in <ready> element]]>
S:
S:
In this case, a positive reply is sent (as channel
succeeded), but the encapsulated response contains an indication
to why the operation failed
3.1.2 Message
Section 7.2 defines the messages that are used in the TLS
security profile
Rose Standards Track [Page 35]
RFC 3080 The BEEP Core March 2001
3.1.3 Message
3.1.3.1 The Ready
The "ready" element has an optional "version" attribute and
content
o the "version" element defines the earliest version of
acceptable for use
When a BEEP peer sends the "ready" element, it must not send
further traffic on the underlying transport service until
corresponding reply ("proceed" or "error") is received; similarly
the receiving BEEP peer must wait until any pending replies have
generated and sent before it processes a "ready" element
3.1.3.2 The Proceed
The "proceed" element has no attributes and no content. It is
as a reply to the "ready" element
When a BEEP peer receives the "ready" element, it must not send
further traffic on the underlying transport service until
generates a corresponding reply. If the BEEP peer decides to
transport security negotiation, it implicitly closes all
(including channel zero), and sends the "proceed" element, and
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),
and immediately begins the underlying negotiation process
transport security
Rose Standards Track [Page 36]
RFC 3080 The BEEP Core March 2001
4. User
When a BEEP session is established, anonymous access, without
information, is provided. Accordingly, user authentication in
is achieved using an initial tuning profile
This document defines a family of profiles based on SASL mechanisms
o each mechanism in the IANA SASL registry [15] has an
profile
Other profiles may be defined and deployed on a bilateral basis
Whenever a successful authentication occurs, on any channel,
authenticated identity is updated for all existing and
channels on the BEEP session; further, no additional attempts
authentication are allowed
Note that regardless of transport security and user authentication
authorization is an internal matter for each BEEP peer. As such
each peer may choose to restrict the operations it allows based
the authentication credentials provided (i.e.,
operations might be rejected with error code 530).
Rose Standards Track [Page 37]
RFC 3080 The BEEP Core March 2001
4.1 The SASL Family of
Section 6.3 contains the registration for this profile
Note that SASL may provide both user authentication and
security. Once transport security is successfully negotiated for
BEEP session, then a SASL security layer must not be negotiated
similarly, once any SASL negotiation is successful, a
security profile must not begin its underlying negotiation process
Section 4 of the SASL specification [4] requires the
information be supplied by a protocol definition
service name: "beep
initiation sequence: Creating a channel using a BEEP
corresponding to a SASL mechanism starts the exchange.
optional parameter corresponding to the "initial response" sent
the client is carried within a "blob" element during
creation
exchange sequence: "Challenges" and "responses" are carried
exchanges of the "blob" element. The "status" attribute of
"blob" element is used both by a server indicating a
completion of the exchange, and a client aborting the exchange
The server indicates failure of the exchange by sending an "error
element
security layer negotiation: When a security layer starts negotiation
all channels (including channel zero) are closed on the
session. Accordingly, upon completion of the negotiation process
regardless of its outcome, a new greeting is issued by both
peers
If a security layer is successfully negotiated, it takes
immediately following the message that concludes the server'
successful completion reply
use of the authorization identity: This is made available to
channels for the duration of the BEEP session
Rose Standards Track [Page 38]
RFC 3080 The BEEP Core March 2001
4.1.1 Profile Identification and
Each SASL mechanism registered with the IANA is identified as
http://iana.org/beep/SASL/
where "MECHANISM" is the token assigned to that mechanism by
IANA
Note that during channel creation, a BEEP peer may provide
profiles to the remote peer, e.g.,
C: MSG 0 1 . 52 178
C: Content-Type: application/beep+
C
C:
C:
C:
C:
C:
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+
S
S:
S:
Rose Standards Track [Page 39]
RFC 3080 The BEEP Core March 2001
During channel creation, the corresponding "profile" element in
BEEP "start" element may contain a "blob" element. Note that it
possible for the channel to be created, but for the
operation to fail, e.g.,
C: MSG 0 1 . 52 183
C: Content-Type: application/beep+
C
C:
C:
C: AGJsb2NrbWFzdGVy]]>
C:
C:
C:
S: RPY 0 1 . 221 178
S: Content-Type: application/beep+
S
S:
S: authentication mechanism
S: too weak]]>
S:
S:
In this case, a positive reply is sent (as channel
succeeded), but the encapsulated response contains an indication
to why the operation failed
Otherwise, the server sends a challenge (or signifies success), e.g.,
C: MSG 0 1 . 52 183
C: Content-Type: application/beep+
C
C:
C:
C: AGJsb2NrbWFzdGVy]]>
C:
C:
C:
S: RPY 0 1 . 221 171
S: Content-Type: application/beep+
S
S:
S: b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ
]]>
S:
S:
Rose Standards Track [Page 40]
RFC 3080 The BEEP Core March 2001
Note that this example implies that the "blob" element in
server's reply appears on two lines -- this is an artifact of
presentation; in fact, only one line is used
If a challenge is received, then the client responds and
another reply, e.g.,
C: MSG 1 0 . 0 97
C: Content-Type: application/beep+
C
C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
C:
S: RPY 1 0 . 0 66
S: Content-Type: application/beep+
S
S:
S:
Of course, the client could abort the authentication process
sending "" instead
Alternatively, the server might reject the response with an error
e.g.,
C: MSG 1 0 . 0 97
C: Content-Type: application/beep+
C
C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
C:
S: ERR 1 0 . 0 60
S: Content-Type: application/beep+
S
S:
S:
Rose Standards Track [Page 41]
RFC 3080 The BEEP Core March 2001
Finally, depending on the SASL mechanism, an initialization
may be exchanged unidirectionally during channel creation, e.g.,
C: MSG 0 1 . 52 125
C: Content-Type: application/beep+
C
C:
C:
C:
C:
S: RPY 0 1 . 221 185
S: Content-Type: application/beep+
S
S:
S: PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm
jaS5uZXQ+]]>
S:
S:
Note that this example implies that the "blob" element in
server's reply appears on two lines -- this is an artifact of
presentation; in fact, only one line is used
4.1.2 Message
Section 7.3 defines the messages that are used for each profile
the SASL family
Note that because many SASL mechanisms exchange binary data,
content of the "blob" element is always a base64-encoded string
Rose Standards Track [Page 42]
RFC 3080 The BEEP Core March 2001
4.1.3 Message
The "blob" element has an optional "status" attribute, and
octets as its content
o the "status" attribute, if present, takes one of three values
abort: used by a client to indicate that it is aborting
authentication process
complete: used by a server to indicate that the exchange
complete and successful; or
continue: used by either a client or server, otherwise
Finally, note that SASL's EXTERNAL mechanism works with an "
authentication" service, which is provided by one of
o a transport security profile, capable of providing
information (e.g., Section 3.1), being active on the connection
o a network service, capable of providing strong
(e.g., IPSec [12]), underlying the connection; or
o a locally-defined security service
For authentication to succeed, two conditions must hold
o an external authentication service must be active; and
o if present, the authentication identity must be consistent
the credentials provided by the external authentication
(if the authentication identity is empty, then an
identity is automatically derived from the credentials provided
the external authentication service).
Rose Standards Track [Page 43]
RFC 3080 The BEEP Core March 2001
5. Registration
5.1 Profile Registration
When a profile is registered, the following information is supplied
Profile Identification: specify a URI [10] that
identifies this profile
Message Exchanged during Channel Creation: specify the datatypes
may be exchanged during channel creation
Messages starting one-to-one exchanges: specify the datatypes
may be present when an exchange starts
Messages in positive replies: specify the datatypes that may
present in a positive reply
Messages in negative replies: specify the datatypes that may
present in a negative reply
Messages in one-to-many exchanges: specify the datatypes that may
present in a one-to-many exchange
Message Syntax: specify the syntax of the datatypes exchanged by
profile
Message Semantics: specify the semantics of the datatypes
by the profile
Contact Information: specify the postal and electronic
information for the author of the profile
5.2 Feature Registration
When a feature for the channel management profile is registered,
following information is supplied
Feature Identification: specify a string that identifies
feature. Unless the feature is registered with the IANA,
feature's identification must start with "x-".
Feature Semantics: specify the semantics of the feature
Contact Information: specify the postal and electronic
information for the author of the feature
Rose Standards Track [Page 44]
RFC 3080 The BEEP Core March 2001
6. Initial
6.1 Registration: BEEP Channel
Profile Identification: not
Messages exchanged during Channel Creation: not
Messages starting one-to-one exchanges: "start" or "close
Messages in positive replies: "greeting", "profile", or "ok
Messages in negative replies: "error
Messages in one-to-many exchanges:
Message Syntax: c.f., Section 7.1
Message Semantics: c.f., Section 2.3.1
Contact Information: c.f., the "Author's Address" section of
6.2 Registration: TLS Transport Security
Profile Identification: http://iana.org/beep/
Messages exchanged during Channel Creation: "ready
Messages starting one-to-one exchanges: "ready
Messages in positive replies: "proceed
Messages in negative replies: "error
Messages in one-to-many exchanges:
Message Syntax: c.f., Section 7.2
Message Semantics: c.f., Section 3.1.3
Contact Information: c.f., the "Author's Address" section of
Rose Standards Track [Page 45]
RFC 3080 The BEEP Core March 2001
6.3 Registration: SASL Family of
Profile Identification: http://iana.org/beep/SASL/mechanism,
"mechanism" is a token registered with the
Messages exchanged during Channel Creation: "blob
Messages starting one-to-one exchanges: "blob
Messages in positive replies: "blob
Messages in negative replies: "error
Messages in one-to-many exchanges:
Message Syntax: c.f., Section 7.3
Message Semantics: c.f., Section 4.1.3
Contact Information: c.f., the "Author's Address" section of
Rose Standards Track [Page 46]
RFC 3080 The BEEP Core March 2001
6.4 Registration: application/beep+
MIME media type name:
MIME subtype name: beep+
Required parameters:
Optional parameters: charset (defaults to "UTF-8" [13])
Encoding considerations: This media type may contain binary content
accordingly, when used over a transport that does not
binary transfer, an appropriate encoding must be
Securi