draft-ietf-beep-framework-11.txt   rfc3080.txt 
Network Working Group M.T. Rose Network Working Group M. Rose
Internet-Draft Invisible Worlds, Inc. Request For Comments: 3080 Invisible Worlds, Inc.
Expires: July 5, 2001 January 4, 2001 Category: Standards Track March 2001
The Blocks Extensible Exchange Protocol Core The Blocks Extensible Exchange Protocol Core
draft-ietf-beep-framework-11
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 5, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This memo describes a generic application protocol kernel for This memo describes a generic application protocol kernel for
connection-oriented, asynchronous interactions called BEEP. BEEP connection-oriented, asynchronous interactions called the BEEP
permits simultaneous and independent exchanges within the context of (Blocks Extensible Exchange Protocol) core. BEEP permits
a single application user-identity, supporting both textual and simultaneous and independent exchanges within the context of a single
binary messages. application user-identity, supporting both textual and binary
messages.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . 5 2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . . . . . 6 2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . . . . . 6
2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7 2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7
2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 4, line 11 skipping to change at page 4, line 11
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 57 B. IANA Considerations . . . . . . . . . . . . . . . . . . . 57
Full Copyright Statement . . . . . . . . . . . . . . . . . 58 Full Copyright Statement . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
This memo describes a generic application protocol kernel for This memo describes a generic application protocol kernel for
connection-oriented, asynchronous interactions called BEEP. connection-oriented, asynchronous interactions called BEEP.
At BEEP's core is a framing mechanism that permits simultaneous and At BEEP's core is a framing mechanism that permits simultaneous and
independent exchanges of messages between peers. Messages are independent exchanges of messages between peers. Messages are
arbitrary MIME[1] content, but are usually textual (structured using arbitrary MIME [1] content, but are usually textual (structured using
XML[2]). XML [2]).
All exchanges occur in the context of a channel -- a binding to a All exchanges occur in the context of a channel -- a binding to a
well-defined aspect of the application, such as transport security, well-defined aspect of the application, such as transport security,
user authentication, or data exchange. user authentication, or data exchange.
Each channel has an associated "profile" that defines the syntax and Each channel has an associated "profile" that defines the syntax and
semantics of the messages exchanged. Implicit in the operation of semantics of the messages exchanged. Implicit in the operation of
BEEP is the notion of channel management. In addition to defining BEEP is the notion of channel management. In addition to defining
BEEP's channel management profile, this document defines: BEEP's channel management profile, this document defines:
o the TLS[3] transport security profile; and, o the TLS [3] transport security profile; and,
o the SASL[4] family of profiles. o the SASL [4] family of profiles.
Other profiles, such as those used for data exchange, are defined by Other profiles, such as those used for data exchange, are defined by
an application protocol designer. an application protocol designer.
2. The BEEP Core 2. The BEEP Core
A BEEP session is mapped onto an underlying transport service. A A BEEP session is mapped onto an underlying transport service. A
separate series of documents describe how a particular transport separate series of documents describe how a particular transport
service realizes a BEEP session. For example, [5] describes how a service realizes a BEEP session. For example, [5] describes how a
BEEP session is mapped onto a single TCP[6] connection. BEEP session is mapped onto a single TCP [6] connection.
When a session is established, each BEEP peer advertises the profile When a session is established, each BEEP peer advertises the profiles
it supports. Later on, during the creation of a channel, the client it supports. Later on, during the creation of a channel, the client
supplies one or more proposed profiles for that channel. If the supplies one or more proposed profiles for that channel. If the
server creates the channel, it selects one of the profiles and sends 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 it in a reply; otherwise, it may indicate that none of the profiles
are acceptable, and decline creation of the channel. are acceptable, and decline creation of the channel.
Channel usage falls into one of two categories: Channel usage falls into one of two categories:
initial tuning: these are used by profiles that perform initial tuning: these are used by profiles that perform
initialization once the BEEP session is established (e.g., initialization once the BEEP session is established (e.g.,
negotiating the use of transport security); although several negotiating the use of transport security); although several
exchanges may be required to perform the initialization, these exchanges may be required to perform the initialization, these
skipping to change at page 6, line 7 skipping to change at page 6, line 7
continuous: these are used by profiles that support data exchange; continuous: these are used by profiles that support data exchange;
typically, these channels are created after the initial tuning typically, these channels are created after the initial tuning
channels have gone quiet. channels have gone quiet.
Note that because of their special nature, only one tuning channel Note that because of their special nature, only one tuning channel
may be established at any given time; in contrast, BEEP allows may be established at any given time; in contrast, BEEP allows
multiple data exchange channels to be simultaneously in use. multiple data exchange channels to be simultaneously in use.
2.1 Roles 2.1 Roles
Although BEEP is peer-to-peer, it is convenient to label each peer Although BEEP is peer-to-peer, it is convenient to label each peer in
in the context of the role it is performing at a given time: the context of the role it is performing at a given time:
o When a BEEP session is established, the peer that awaits new o When a BEEP session is established, the peer that awaits new
connections is acting in the listening role, and the other peer, connections is acting in the listening role, and the other peer,
which establishes a connection to the listener, is acting in the which establishes a connection to the listener, is acting in the
initiating role. In the examples which follow, these are referred initiating role. In the examples which follow, these are referred
to as "L:" and "I:", respectively. to as "L:" and "I:", respectively.
o A BEEP peer starting an exchange is termed the client; similarly, o A BEEP peer starting an exchange is termed the client; similarly,
the other BEEP peer is termed the server. In the examples which the other BEEP peer is termed the server. In the examples which
follow, these are referred to as "C:" and "S:", respectively. follow, these are referred to as "C:" and "S:", respectively.
Typically, a BEEP peer acting in the server role is also acting in a 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 listening role. However, because BEEP is peer-to-peer in nature, no
such requirement exists. such requirement exists.
2.1.1 Exchange Styles 2.1.1 Exchange Styles
BEEP allows three styles of exchange: BEEP allows three styles of exchange:
MSG/RPY: the client sends a "MSG" message asking the server to MSG/RPY: the client sends a "MSG" message asking the server to
perform some task, the server performs the task and replies with perform some task, the server performs the task and replies with a
a "RPY" message (termed a positive reply). "RPY" message (termed a positive reply).
MSG/ERR: the client sends a "MSG" message, the server does not MSG/ERR: the client sends a "MSG" message, the server does not
perform any task and replies with an "ERR" message (termed a perform any task and replies with an "ERR" message (termed a
negative reply). negative reply).
MSG/ANS: the client sends a "MSG" message, the server, during the MSG/ANS: the client sends a "MSG" message, the server, during the
course of performing some task, replies with zero or more "ANS" course of performing some task, replies with zero or more "ANS"
messages, and, upon completion of the task, sends a "NUL" messages, and, upon completion of the task, sends a "NUL" message,
message, which signifies the end of the reply. which signifies the end of the reply.
The first two styles are termed one-to-one exchanges, whilst the The first two styles are termed one-to-one exchanges, whilst the
third style is termed a one-to-many exchange. third style is termed a one-to-many exchange.
2.2 Messages and Frames 2.2 Messages and Frames
A message is structured according to the rules of MIME. Accordingly, A message is structured according to the rules of MIME. Accordingly,
each message may begin with "entity-headers" (c.f., MIME[1]'s each message may begin with "entity-headers" (c.f., MIME's Section 3
Section 3). If none, or only some, of the "entity-headers" are [1]). If none, or only some, of the "entity-headers" are present:
present:
o the default "Content-Type" is "application/octet-stream"; and, o the default "Content-Type" is "application/octet-stream"; and,
o the default "Content-Transfer-Encoding" is "binary". o the default "Content-Transfer-Encoding" is "binary".
Normally, a message is sent in a single frame. However, it may be Normally, a message is sent in a single frame. However, it may be
convenient or necesary to segment a message into multiple frames convenient or necessary to segment a message into multiple frames
(e.g., if only part of a message is ready to be sent). (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 Each frame consists of a header, the payload, and a trailer. The
header and trailer are each represented using printable ASCII header and trailer are each represented using printable ASCII
characters and are terminated with a CRLF pair. Between the header characters and are terminated with a CRLF pair. Between the header
and the trailer is the payload, consisting of zero or more octets. and the trailer is the payload, consisting of zero or more octets.
For example, here is a message contained in a single frame that For example, here is a message contained in a single frame that
contains a payload of 132 octets spread over 5 lines (each line is contains a payload of 120 octets spread over 5 lines (each line is
terminated with a CRLF pair): terminated with a CRLF pair):
C: MSG 0 1 . 52 132 C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start> C: </start>
C: END C: END
In this example, note that the entire message is represented in a In this example, note that the entire message is represented in a
single frame. single frame.
2.2.1 Frame Syntax 2.2.1 Frame Syntax
The ABNF[7] for a frame is: The ABNF [7] for a frame is:
frame = data / mapping frame = data / mapping
data = header payload trailer data = header payload trailer
header = msg / rpy / err / ans / nul header = msg / rpy / err / ans / nul
msg = "MSG" SP common CR LF msg = "MSG" SP common CR LF
rpy = "RPY" SP common CR LF rpy = "RPY" SP common CR LF
ans = "ANS" SP common SP ansno CR LF ans = "ANS" SP common SP ansno CR LF
skipping to change at page 9, line 9 skipping to change at page 9, line 9
payload = *OCTET payload = *OCTET
trailer = "END" CR LF trailer = "END" CR LF
mapping = ;; each transport mapping may define additional frames mapping = ;; each transport mapping may define additional frames
2.2.1.1 Frame Header 2.2.1.1 Frame Header
The frame header consists of a three-character keyword (one of: The frame header consists of a three-character keyword (one of:
"MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more
parameters. A single space character (decimal code 32, " ") parameters. A single space character (decimal code 32, " ")
separates each component. The header is terminated with a CRLF pair. separates each component. The header is terminated with a CRLF pair.
The channel number ("channel") must be a non-negative integer (in The channel number ("channel") must be a non-negative integer (in the
the range 0..2147483647). range 0..2147483647).
The message number ("msgno") must be a non-negative integer (in the The message number ("msgno") must be a non-negative integer (in the
range 0..2147483647) and have a different value than all other "MSG" range 0..2147483647) and have a different value than all other "MSG"
messages on the same channel for which a reply has not been messages on the same channel for which a reply has not been
completely received. completely received.
The continuation indicator ("more", one of: decimal code 42, "*", or The continuation indicator ("more", one of: decimal code 42, "*", or
decimal code 46, ".") specifies whether this is the final frame of decimal code 46, ".") specifies whether this is the final frame of
the message: the message:
skipping to change at page 9, line 36 skipping to change at page 9, line 36
complete ("."): this frame completes the message. complete ("."): this frame completes the message.
The sequence number ("seqno") must be a non-negative integer (in the The sequence number ("seqno") must be a non-negative integer (in the
range 0..4294967295) and specifies the sequence number of the first range 0..4294967295) and specifies the sequence number of the first
octet in the payload, for the associated channel (c.f., Section octet in the payload, for the associated channel (c.f., Section
2.2.1.2). 2.2.1.2).
The payload size ("size") must be a non-negative integer (in the The payload size ("size") must be a non-negative integer (in the
range 0..2147483647) and specifies the exact number of octets in the range 0..2147483647) and specifies the exact number of octets in the
payload. (This does not include either the header or trailer.) payload. (This does not include either the header or trailer.)
Note that a frame may have an empty payload, e.g., Note that a frame may have an empty payload, e.g.,
S: RPY 0 1 * 287 20 S: RPY 0 1 * 287 20
S: ... S: ...
S: ... S: ...
S: END S: END
S: RPY 0 1 . 307 0 S: RPY 0 1 . 307 0
S: END S: END
The answer number ("ansno") must be a non-negative integer (in the The answer number ("ansno") must be a non-negative integer (in the
range 0..4294967295) and must have a different value than all other range 0..4294967295) and must have a different value than all other
answers in progress for the message being replied to. answers in progress for the message being replied to.
There are two kinds of frames: data and mapping. each transport There are two kinds of frames: data and mapping. Each transport
mapping (c.f., Section 2.5) may define its own frames. For example, mapping (c.f., Section 2.5) may define its own frames. For example,
[5] defines the SEQ frame. The remainder of this section discusses [5] defines the SEQ frame. The remainder of this section discusses
data frames. data frames.
When a message is segmented and sent as several frames, those frames When a message is segmented and sent as several frames, those frames
must be sent sequentally, without any intervening frames from other must be sent sequentially, without any intervening frames from other
messages on the same channel. However, there are two exceptions: messages on the same channel. However, there are two exceptions:
first, no restriction is made with respect to the interleaving of first, no restriction is made with respect to the interleaving of
frames for other channels; and, second, in a one-to-many exchange, frames for other channels; and, second, in a one-to-many exchange,
multiple answers may be simultaneously in progress. Accordingly, multiple answers may be simultaneously in progress. Accordingly,
frames for "ANS" messages may be interleaved on the same channel -- frames for "ANS" messages may be interleaved on the same channel --
the answer number is used for collation, e.g., the answer number is used for collation, e.g.,
S: ANS 1 0 * 0 20 0 S: ANS 1 0 * 0 20 0
S: ... S: ...
S: ... S: ...
S: END S: END
S: ANS 1 0 * 20 20 1 S: ANS 1 0 * 20 20 1
S: ... S: ...
S: ... S: ...
S: END S: END
S: ANS 1 0 . 40 10 0 S: ANS 1 0 . 40 10 0
S: ... S: ...
S: END S: END
which shows two "ANS" messages interleaved on channel 1 as part of a 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 reply to message number 0. Note that the sequence number is advanced
for each frame sent on the channel, and is independent of the for each frame sent on the channel, and is independent of the
messages sent in those frames. messages sent in those frames.
There are several rules for identifying poorly-formed frames: There are several rules for identifying poorly-formed frames:
o if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or o if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or
"NUL"; "NUL";
o if any of the parameters in the header cannot be determined or o if any of the parameters in the header cannot be determined or are
are invalid (i.e., syntactically incorrect); invalid (i.e., syntactically incorrect);
o if the value of the channel number doesn't refer to an existing o if the value of the channel number doesn't refer to an existing
channel; channel;
o if the header starts with "MSG", and the message number refers to 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 a "MSG" message that has been completely received but for which a
reply has not been completely sent; reply has not been completely sent;
o if the header doesn't start with "MSG", and refers to a message o if the header doesn't start with "MSG", and refers to a message
number for which a reply has already been completely received; number for which a reply has already been completely received;
o if the header doesn't start with "MSG", and refers to a message o if the header doesn't start with "MSG", and refers to a message
number that has never been sent (except during session number that has never been sent (except during session
establishment, c.f., Section 2.3.1.1); establishment, c.f., Section 2.3.1.1);
o if the header starts with "MSG", "RPY", "ERR", or "ANS", and 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 refers to a message number for which at least one other frame has
been received, and the three-character keyword starting this been received, and the three-character keyword starting this frame
frame and the immediately-previous received frame for this and the immediately-previous received frame for this message
message number are not identical; number are not identical;
o if the header starts with "NUL", and refers to a message number 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 for which at least one other frame has been received, and the
keyword of of the immediately-previous received frame for this keyword of of the immediately-previous received frame for this
reply isn't "ANS"; reply isn't "ANS";
o if the continuation indicator of the previous frame received on o if the continuation indicator of the previous frame received on
the same channel was intermediate ("*"), and its message number the same channel was intermediate ("*"), and its message number
isn't identical to this frame's message number; isn't identical to this frame's message number;
o if the value of the sequence number doesn't correspond to the o if the value of the sequence number doesn't correspond to the
expected value for the associated channel (c.f., Section expected value for the associated channel (c.f., Section 2.2.1.2);
2.2.1.2); or, or,
o if the header starts with "NUL", and the continuation indicator o if the header starts with "NUL", and the continuation indicator is
is intermediate ("*") or the payload size is non-zero. intermediate ("*") or the payload size is non-zero.
If a frame is poorly-formed, then the session is terminated without If a frame is poorly-formed, then the session is terminated without
generating a response, and it is recommended that a diagnostic entry generating a response, and it is recommended that a diagnostic entry
be logged. be logged.
2.2.1.2 Frame Payload 2.2.1.2 Frame Payload
The frame payload consists of zero or more octets. The frame payload consists of zero or more octets.
Every payload octet sent in each direction on a channel has an Every payload octet sent in each direction on a channel has an
associated sequence number. Numbering of payload octets within a associated sequence number. Numbering of payload octets within a
frame is such that the first payload octet is the lowest numbered, frame is such that the first payload octet is the lowest numbered,
and the following payload octets are numbered consecutively. (When a and the following payload octets are numbered consecutively. (When a
channel is created, the sequence number associated with the first channel is created, the sequence number associated with the first
payload octet of the first frame is 0.) payload octet of the first frame is 0.)
The actual sequence number space is finite, though very large, The actual sequence number space is finite, though very large,
ranging from 0..4294967295 (2**32 - 1). Since the space is finite, ranging from 0..4294967295 (2**32 - 1). Since the space is finite,
all arithmetic dealing with sequence numbers is performed modulo all arithmetic dealing with sequence numbers is performed modulo
2**32. This unsigned arithmetic preserves the relationship of 2**32. This unsigned arithmetic preserves the relationship of
sequence numbers as they cycle from 2**32 - 1 to 0 again. Consult 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 Sections 2 through 5 of [8] for a discussion of the arithmetic
properties of sequence numbers. properties of sequence numbers.
When receiving a frame, the sum of its sequence number and payload When receiving a frame, the sum of its sequence number and payload
size, modulo 4294967296 (2**32), gives the expected sequence number size, modulo 4294967296 (2**32), gives the expected sequence number
associated with the first payload octet of the next frame received. associated with the first payload octet of the next frame received.
Accordingly, when receiving a frame if the sequence number isn't the Accordingly, when receiving a frame if the sequence number isn't the
expected value for this channel, then the BEEP peers have lost expected value for this channel, then the BEEP peers have lost
synchronization, then the session is terminated without generating a synchronization, then the session is terminated without generating a
response, and it is recommended that a diagnostic entry be logged. response, and it is recommended that a diagnostic entry be logged.
2.2.1.3 Frame Trailer 2.2.1.3 Frame Trailer
The frame trailer consists of "END" followed by a CRLF pair. The frame trailer consists of "END" followed by a CRLF pair.
When receiving a frame, if the characters immediately following the When receiving a frame, if the characters immediately following the
payload don't correspond to a trailer, then the session is payload don't correspond to a trailer, then the session is terminated
terminated without generating a response, and it is recommended that without generating a response, and it is recommended that a
a diagnostic entry be logged. diagnostic entry be logged.
2.2.2 Frame Semantics 2.2.2 Frame Semantics
The semantics of each message is channel-specific. Accordingly, the The semantics of each message is channel-specific. Accordingly, the
profile associated with a channel must define: profile associated with a channel must define:
o the initialization messages, if any, exchanged during channel o the initialization messages, if any, exchanged during channel
creation; creation;
o the messages that may be exchanged in the payload of the channel; o the messages that may be exchanged in the payload of the channel;
and, and,
o the semantics of these messages. o the semantics of these messages.
A profile registration template (Section 5.1) organizes this A profile registration template (Section 5.1) organizes this
information. information.
2.2.2.1 Poorly-formed Messages 2.2.2.1 Poorly-formed Messages
When defining the behavior of the profile, the template must specify When defining the behavior of the profile, the template must specify
how poorly-formed "MSG" messages are replied to. For example, the how poorly-formed "MSG" messages are replied to. For example, the
channel management profile sends a negative reply containing an channel management profile sends a negative reply containing an error
error message (c.f., Section 2.3.1.5). message (c.f., Section 2.3.1.5).
If a poorly-formed reply is received on channel zero, the session is If a poorly-formed reply is received on channel zero, the session is
terminated without generating a response, and it is recommended that terminated without generating a response, and it is recommended that
a diagnostic entry be logged. a diagnostic entry be logged.
If a poorly-formed reply is received on another channel, then the 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. channel must be closed using the procedure in Section 2.3.1.3.
2.3 Channel Management 2.3 Channel Management
When a BEEP session starts, only channel number zero is defined, When a BEEP session starts, only channel number zero is defined,
which is used for channel management. Section 6.1 contains the which is used for channel management. Section 6.1 contains the
profile registration for BEEP channel management. profile registration for BEEP channel management.
Channel management allows each BEEP peer to advertise the profiles 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 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 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 close any channels or release the BEEP session (c.f., Section
2.3.1.3). 2.3.1.3).
A BEEP peer should support at least 257 concurrent channels. A BEEP peer should support at least 257 concurrent channels.
2.3.1 Message Semantics 2.3.1 Message Semantics
2.3.1.1 The Greeting Message 2.3.1.1 The Greeting Message
When a BEEP session is established, each BEEP peer signifies its When a BEEP session is established, each BEEP peer signifies its
availability by immediately sending a positive reply with a message availability by immediately sending a positive reply with a message
number of zero that contains a "greeting" element, e.g., number of zero that contains a "greeting" element, e.g.,
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 122 L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml L: Content-Type: application/beep+xml
L: L:
L: <greeting> L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' /> L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RPY 0 0 . 0 52 I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
Note that this example implies that the BEEP peer in the initiating Note that this example implies that the BEEP peer in the initiating
role waits until the BEEP peer in the listening role sends its role waits until the BEEP peer in the listening role sends its
greeting -- this is an artifact of the presentation; in fact, both greeting -- this is an artifact of the presentation; in fact, both
BEEP peers send their replies independently. BEEP peers send their replies independently.
The "greeting" element has two optional attributes ("features" and The "greeting" element has two optional attributes ("features" and
"localize") and zero or more "profile" elements, one for each "localize") and zero or more "profile" elements, one for each profile
profile supported by the BEEP peer acting in a server role: supported by the BEEP peer acting in a server role:
o the "features" attribute, if present, contains one or more o the "features" attribute, if present, contains one or more feature
feature tokens, each indicating an optional feature of the tokens, each indicating an optional feature of the channel
channel management profile supported by the BEEP peer; management profile supported by the BEEP peer;
o the "localize" attribute, if present, contains one or more o the "localize" attribute, if present, contains one or more
language tokens (defined in [9]), each identifying a desirable language tokens (defined in [9]), each identifying a desirable
language tag to be used by the remote BEEP peer when generating language tag to be used by the remote BEEP peer when generating
textual diagnostics for the "close" and "error" elements (the textual diagnostics for the "close" and "error" elements (the
tokens are ordered from most to least desirable); and, tokens are ordered from most to least desirable); and,
o each "profile" element contained within the "greeting" element o each "profile" element contained within the "greeting" element
identifies a profile, and unlike the "profile" elements that identifies a profile, and unlike the "profile" elements that occur
occur within the "start" element, the content of each "profile" within the "start" element, the content of each "profile" element
element may not contain an optional initialization message. may not contain an optional initialization message.
Section 5.2 defines a registration template for optional features. Section 5.2 defines a registration template for optional features.
2.3.1.2 The Start Message 2.3.1.2 The Start Message
When a BEEP peer wants to create a channel, it sends a "start" When a BEEP peer wants to create a channel, it sends a "start"
element on channel zero, e.g., element on channel zero, e.g.,
C: MSG 0 1 . 52 132 C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start> C: </start>
C: END C: END
The "start" element has a "number" attribute, an optional The "start" element has a "number" attribute, an optional
"serverName" attribute, and one or more "profile" elements: "serverName" attribute, and one or more "profile" elements:
o the "number" attribute indicates the channel number (in the range o the "number" attribute indicates the channel number (in the range
1..2147483647) used to identify the channel in future messages; 1..2147483647) used to identify the channel in future messages;
o the "serverName" attribute, an arbitrary string, indicates the o the "serverName" attribute, an arbitrary string, indicates the
desired server name for this BEEP session; and, desired server name for this BEEP session; and,
o each "profile" element contained with the "start" element has a o each "profile" element contained with the "start" element has a
"uri" attribute, an optional "encoding" attribute, and arbitrary "uri" attribute, an optional "encoding" attribute, and arbitrary
character data as content: character data as content:
* the "uri" attribute authoritatively identifies the profile; * the "uri" attribute authoritatively identifies the profile;
* the "encoding" attribute, if present, specifies whether the * the "encoding" attribute, if present, specifies whether the
content of the "profile" element is represented as a content of the "profile" element is represented as a base64-
base64-encoded string; and, encoded string; and,
* the content of the "profile" element, if present, must be no * the content of the "profile" element, if present, must be no
longer than 4K octets in length and specifies an longer than 4K octets in length and specifies an initialization
initialization message given to the channel as soon as it is message given to the channel as soon as it is created.
created.
To avoid conflict in assigning channel numbers when requesting the To avoid conflict in assigning channel numbers when requesting the
creation of a channel, BEEP peers acting in the initiating role use creation of a channel, BEEP peers acting in the initiating role use
only positive integers that are odd-numbered; similarly, BEEP peers only positive integers that are odd-numbered; similarly, BEEP peers
acting in the listening role use only positive integers that are acting in the listening role use only positive integers that are
even-numbered. even-numbered.
The "serverName" attribute for the first successful "start" element The "serverName" attribute for the first successful "start" element
received by a BEEP peer is meaningful for the duration of the BEEP 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 session. If present, the BEEP peer decides whether to operate as the
indicated "serverName"; if not, an "error" element is sent in a indicated "serverName"; if not, an "error" element is sent in a
negative reply. negative reply.
When a BEEP peer receives a "start" element on channel zero, it When a BEEP peer receives a "start" element on channel zero, it
examines each of the proposed profiles, and decides whether to use examines each of the proposed profiles, and decides whether to use
one of them to create the channel. If so, the appropriate "profile" one of them to create the channel. If so, the appropriate "profile"
element is sent in a positive reply; otherwise, an "error" element element is sent in a positive reply; otherwise, an "error" element is
is sent in a negative reply. sent in a negative reply.
When creating the channel, the value of the "serverName" attribute When creating the channel, the value of the "serverName" attribute
from the first successful "start" element is consulted to provide from the first successful "start" element is consulted to provide
configuration information, e.g., the desired server-side certificate configuration information, e.g., the desired server-side certificate
when starting the TLS transport security profile (Section 3.1). when starting the TLS transport security profile (Section 3.1).
For example, a successful channel creation might look like this: For example, a successful channel creation might look like this:
C: MSG 0 1 . 52 209 C: MSG 0 1 . 52 178
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: <profile C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
C: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
C: </start> C: </start>
C: END C: END
S: RPY 0 1 . 264 99 S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> S: <profile uri='http://iana.org/beep/SASL/OTP' />
S: END S: END
Similarly, an unsuccessful channel creation might look like this: Similarly, an unsuccessful channel creation might look like this:
C: MSG 0 1 . 52 132 C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='2'> C: <start number='2'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start> C: </start>
C: END C: END
S: ERR 0 1 . 264 127 S: ERR 0 1 . 221 127
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <error code='501'>number attribute S: <error code='501'>number attribute
S: in &lt;start&gt; element must be odd-valued</error> S: in &lt;start&gt; element must be odd-valued</error>
S: END S: END
Finally, here's an example in which an initialization element is Finally, here's an example in which an initialization element is
exchanged during channel creation: exchanged during channel creation:
C: MSG 0 1 . 52 170 C: MSG 0 1 . 52 158
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'> C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready />]]> C: <![CDATA[<ready />]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RPY 0 1 . 122 133 S: RPY 0 1 . 110 121
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/TLS'> S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<proceed />]]> S: <![CDATA[<proceed />]]>
S: </profile> S: </profile>
S: END S: END
2.3.1.3 The Close Message 2.3.1.3 The Close Message
When a BEEP peer wants to close a channel, it sends a "close" When a BEEP peer wants to close a channel, it sends a "close" element
element on channel zero, e.g., on channel zero, e.g.,
C: MSG 0 2 . 247 71 C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <close number='1' code='200' /> C: <close number='1' code='200' />
C: END C: END
The "close" element has a "number" attribute, a "code" attribute, an The "close" element has a "number" attribute, a "code" attribute, an
optional "xml:lang" attribute, and an optional textual diagnostic as optional "xml:lang" attribute, and an optional textual diagnostic as
its content: its content:
o the "number" attribute indicates the channel number; o the "number" attribute indicates the channel number;
o the "code" attribute is a three-digit reply code meaningful to o the "code" attribute is a three-digit reply code meaningful to
programs (c.f., Section 8); programs (c.f., Section 8);
o the "xml:lang" attribute identifies the language that the o the "xml:lang" attribute identifies the language that the
element's content is written in (the value is suggested, but not element's content is written in (the value is suggested, but not
mandated, by the "localize" attribute of the "greeting" element mandated, by the "localize" attribute of the "greeting" element
sent by the remote BEEP peer); and, sent by the remote BEEP peer); and,
o the textual diagnostic (which may be multiline) is meaningful to o the textual diagnostic (which may be multiline) is meaningful to
implementers, perhaps administrators, and possibly even users, implementers, perhaps administrators, and possibly even users, but
but never programs. never programs.
Note that if the textual diagnostic is present, then the "xml:lang" Note that if the textual diagnostic is present, then the "xml:lang"
attribute is absent only if the language indicated as the remote attribute is absent only if the language indicated as the remote BEEP
BEEP peer's first choice is used. peer's first choice is used.
If the value of the "number" attribute is zero, then the BEEP peer 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 wants to release the BEEP session (c.f., Section 2.4) -- otherwise
the value of the "number" attribute refers to an existing channel, the value of the "number" attribute refers to an existing channel,
and the remainder of this section applies. and the remainder of this section applies.
A BEEP peer may send a "close" message for a channel whenever all A BEEP peer may send a "close" message for a channel whenever all
"MSG" messages it has sent on that channel have been acknowledged. "MSG" messages it has sent on that channel have been acknowledged.
(Acknowledgement consists of the first frame of a reply being (Acknowledgement consists of the first frame of a reply being
received by the BEEP peer that sent the MSG "message".) received by the BEEP peer that sent the MSG "message".)
After sending the "close" message, that BEEP peer must not send any After sending the "close" message, that BEEP peer must not send any
more "MSG" messages on that channel being closed until the reply to more "MSG" messages on that channel being closed until the reply to
the "close" message has been received (either by an "error" message the "close" message has been received (either by an "error" message
rejecting the request to close the channel, or by an "ok" message rejecting the request to close the channel, or by an "ok" message
subsequently followed by the channel being successfully started). subsequently followed by the channel being successfully started).
NOTE WELL: until a positive reply to the request to close the NOTE WELL: until a positive reply to the request to close the channel
channel is received, the BEEP peer must be prepared to process any is received, the BEEP peer must be prepared to process any "MSG"
"MSG" messages that it receives on that channel. messages that it receives on that channel.
When a BEEP peer receives a "close" message for a channel, it may, When a BEEP peer receives a "close" message for a channel, it may, at
at any time, reject the request to close the channel by sending an any time, reject the request to close the channel by sending an
"error" message in a negative reply. "error" message in a negative reply.
Otherwise, before accepting the request to close the channel, and Otherwise, before accepting the request to close the channel, and
sending an "ok" message in a positive reply, it must: sending an "ok" message in a positive reply, it must:
o finish sending any queued "MSG" messages on that channel of its o finish sending any queued "MSG" messages on that channel of its
own; own;
o await complete replies to any outstanding "MSG" messages it has o await complete replies to any outstanding "MSG" messages it has
sent on that channel; and, sent on that channel; and,
o finish sending complete replies to any outstanding "MSG" messages o finish sending complete replies to any outstanding "MSG" messages
it has received on that channel, and ensure that the final frames it has received on that channel, and ensure that the final frames
of those replies have been successfully delivered, i.e., of those replies have been successfully delivered, i.e.,
* for transport mappings that guarantee inter-channel ordering * for transport mappings that guarantee inter-channel ordering of
of messages, the replies must be sent prior to sending the messages, the replies must be sent prior to sending the "ok"
"ok" message in a positive reply; otherwise, message in a positive reply; otherwise,
* the replies must be sent and subsequently acknowledged by the * the replies must be sent and subsequently acknowledged by the
underlying transport service prior to sending the "ok" message underlying transport service prior to sending the "ok" message
in a positive reply. in a positive reply.
Briefly, a successful channel close might look like this: Briefly, a successful channel close might look like this:
C: MSG 0 2 . 247 71 C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <close number='1' code='200' /> C: <close number='1' code='200' />
C: END C: END
S: RPY 0 2 . 447 46 S: RPY 0 2 . 392 46
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <ok /> S: <ok />
S: END S: END
Similarly, an unsuccessful channel close might look like this: Similarly, an unsuccessful channel close might look like this:
C: MSG 0 2 . 247 71 C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <close number='1' code='200' /> C: <close number='1' code='200' />
C: END C: END
S: ERR 0 2 . 447 79 S: ERR 0 2 . 392 79
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <error code='550'>still working</error> S: <error code='550'>still working</error>
S: END S: END
2.3.1.4 The OK Message 2.3.1.4 The OK Message
When a BEEP peer agrees to close a channel (or release the BEEP When a BEEP peer agrees to close a channel (or release the BEEP
session), it sends an "ok" element in a positive reply. session), it sends an "ok" element in a positive reply.
The "ok" element has no attributes and no content. The "ok" element has no attributes and no content.
2.3.1.5 The Error Message 2.3.1.5 The Error Message
When a BEEP peer declines the creation of a channel, it sends an When a BEEP peer declines the creation of a channel, it sends an
"error" element in a negative reply, e.g., "error" element in a negative reply, e.g.,
I: MSG 0 1 . 52 127 I: MSG 0 1 . 52 115
I: Content-Type: application/beep+xml I: Content-Type: application/beep+xml
I: I:
I: <start number='2'> I: <start number='2'>
I: <profile uri='http://xml.resource.org/profiles/FOO' /> I: <profile uri='http://iana.org/beep/FOO' />
I: </start> I: </start>
I: END I: END
L: ERR 0 1 . 264 105 L: ERR 0 1 . 221 105
L: Content-Type: application/beep+xml L: Content-Type: application/beep+xml
L: L:
L: <error code='550'>all requested profiles are L: <error code='550'>all requested profiles are
L: unsupported</error> L: unsupported</error>
L: END L: END
The "error" element has a "code" attribute, an optional "xml:lang" The "error" element has a "code" attribute, an optional "xml:lang"
attribute, and an optional textual diagnostic as its content: attribute, and an optional textual diagnostic as its content:
o the "code" attribute is a three-digit reply code meaningful to o the "code" attribute is a three-digit reply code meaningful to
programs (c.f., Section 8); programs (c.f., Section 8);
o the "xml:lang" attribute identifies the language that the o the "xml:lang" attribute identifies the language that the
element's content is written in (the value is suggested, but not element's content is written in (the value is suggested, but not
mandated, by the "localize" attribute of the "greeting" element mandated, by the "localize" attribute of the "greeting" element
sent by the remote BEEP peer); and, sent by the remote BEEP peer); and,
o the textual diagnostic (which may be multiline) is meaningful to o the textual diagnostic (which may be multiline) is meaningful to
implementers, perhaps administrators, and possibly even users, implementers, perhaps administrators, and possibly even users, but
but never programs. never programs.
Note that if the textual diagnostic is present, then the "xml:lang" Note that if the textual diagnostic is present, then the "xml:lang"
attribute is absent only if the language indicated as the remote attribute is absent only if the language indicated as the remote BEEP
BEEP peer's first choice is used. peer's first choice is used.
In addition, a BEEP peer sends an "error" element whenever: In addition, a BEEP peer sends an "error" element whenever:
o it receives a "MSG" message containing a poorly-formed or o it receives a "MSG" message containing a poorly-formed or
unexpected element; unexpected element;
o it receives a "MSG" message asking to close a channel (or release o it receives a "MSG" message asking to close a channel (or release
the BEEP session) and it declines to do so; or the BEEP session) and it declines to do so; or
o a BEEP session is established, the BEEP peer is acting in the o a BEEP session is established, the BEEP peer is acting in the
skipping to change at page 25, line 14 skipping to change at page 25, line 14
2.4 Session Establishment and Release 2.4 Session Establishment and Release
When a BEEP session is established, each BEEP peer signifies its When a BEEP session is established, each BEEP peer signifies its
availability by immediately sending a positive reply with a message availability by immediately sending a positive reply with a message
number of zero on channel zero that contains a "greeting" element, number of zero on channel zero that contains a "greeting" element,
e.g., e.g.,
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 122 L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml L: Content-Type: application/beep+xml
L: L:
L: <greeting> L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' /> L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RPY 0 0 . 0 52 I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
Alternatively, if the BEEP peer acting in the listening role is Alternatively, if the BEEP peer acting in the listening role is
unavailable, it sends a negative reply, e.g., unavailable, it sends a negative reply, e.g.,
skipping to change at page 25, line 47 skipping to change at page 25, line 47
I: RPY 0 0 . 0 52 I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I: <close connection> I: <close connection>
L: <close connection> L: <close connection>
L: <wait for next connection> L: <wait for next connection>
and the "greeting" element sent by the BEEP peer acting in the and the "greeting" element sent by the BEEP peer acting in the
initiating role is ignored. It is recommended that a diagnostic initiating role is ignored. It is recommended that a diagnostic
entry be logged by both BEEP peers. entry be logged by both BEEP peers.
Note that both of these examples imply that the BEEP peer in the Note that both of these examples imply that the BEEP peer in the
initiating role waits until the BEEP peer in the listening role initiating role waits until the BEEP peer in the listening role sends
sends its greeting -- this is an artifact of the presentation; in its greeting -- this is an artifact of the presentation; in fact,
fact, both BEEP peers send their replies independently. both BEEP peers send their replies independently.
When a BEEP peer wants to release the BEEP session, it sends a When a BEEP peer wants to release the BEEP session, it sends a
"close" element with a zero-valued "number" attribute on channel "close" element with a zero-valued "number" attribute on channel
zero. The other BEEP peer indicates its willingness by sending an zero. The other BEEP peer indicates its willingness by sending an
"ok" element in a positive reply, e.g., "ok" element in a positive reply, e.g.,
C: MSG 0 1 . 52 60 C: MSG 0 1 . 52 60
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <close code='200' /> C: <close code='200' />
C: END C: END
S: RPY 0 1 . 264 46 S: RPY 0 1 . 264 46
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
skipping to change at page 27, line 8 skipping to change at page 27, line 8
S: S:
S: <error code='550'>still working</error> S: <error code='550'>still working</error>
S: END S: END
If session release is declined, the BEEP session should not be If session release is declined, the BEEP session should not be
terminated, if possible. terminated, if possible.
2.5 Transport Mappings 2.5 Transport Mappings
All transport interactions occur in the context of a session -- a All transport interactions occur in the context of a session -- a
mapping onto a particular transport service. Accordingly, this memo mapping onto a particular transport service. Accordingly, this memo
defines the requirements that must be satisified by any document defines the requirements that must be satisfied by any document
describing how a particular transport service realizes a BEEP describing how a particular transport service realizes a BEEP
session. session.
2.5.1 Session Management 2.5.1 Session Management
A BEEP session is connection-oriented. A mapping document must A BEEP session is connection-oriented. A mapping document must
define: define:
o how a BEEP session is established; 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 listening role;
o how a BEEP peer is identified as acting in the initiating 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 released; and,
o how a BEEP session is terminated. o how a BEEP session is terminated.
2.5.2 Message Exchange 2.5.2 Message Exchange
A BEEP session is message-oriented. A mapping document must define: A BEEP session is message-oriented. A mapping document must define:
o how messages are reliably sent and received; o how messages are reliably sent and received;
o how messages on the same channel are received in the same order o how messages on the same channel are received in the same order as
as they were sent; and, they were sent; and,
o how messages on different channels are sent without ordering o how messages on different channels are sent without ordering
constraint. constraint.
2.6 Asynchrony 2.6 Asynchrony
BEEP accomodates asynchronous interactions, both within a single BEEP accommodates asynchronous interactions, both within a single
channel and between separate channels. This feature allows channel and between separate channels. This feature allows
pipelining (intra-channel) and parallelism (inter-channel). pipelining (intra-channel) and parallelism (inter-channel).
2.6.1 Within a Single Channel 2.6.1 Within a Single Channel
A BEEP peer acting in the client role may send multiple "MSG" A BEEP peer acting in the client role may send multiple "MSG"
messages on the same channel without waiting to receive the messages on the same channel without waiting to receive the
corresponding replies. This provides pipelining within a single corresponding replies. This provides pipelining within a single
channel. channel.
A BEEP peer acting in the server role must process all "MSG" A BEEP peer acting in the server role must process all "MSG" messages
messages for a given channel in the same order as they are received. for a given channel in the same order as they are received. As a
As a consequence, the BEEP peer must generate replies in the same consequence, the BEEP peer must generate replies in the same order as
order as the corresponding "MSG" messages are received on a given the corresponding "MSG" messages are received on a given channel.
channel.
Note that in one-to-many exchanges (c.f., Section 2.1.1), the reply 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 to the "MSG" message consists of zero or more "ANS" messages followed
followed by a "NUL" message. In this style of exchange, the "ANS" by a "NUL" message. In this style of exchange, the "ANS" messages
messages comprising the reply may be interleaved. When the BEEP peer comprising the reply may be interleaved. When the BEEP peer acting
acting in the server role signifies the end of the reply by in the server role signifies the end of the reply by generating the
generating the "NUL" message, it may then process the next "MSG" "NUL" message, it may then process the next "MSG" message received
message received for that channel. for that channel.
2.6.2 Between Different Channels 2.6.2 Between Different Channels
A BEEP peer acting in the client role may send multiple "MSG" A BEEP peer acting in the client role may send multiple "MSG"
messages on different channels without waiting to receive the messages on different channels without waiting to receive the
corresponding replies. The channels operate independently, in corresponding replies. The channels operate independently, in
parallel. parallel.
A BEEP peer acting in the server role may process "MSG" messages A BEEP peer acting in the server role may process "MSG" messages
received on different channels in any order it chooses. As a received on different channels in any order it chooses. As a
consequence, although the replies for a given channel appear to be consequence, although the replies for a given channel appear to be
generated in the same order in which the corresponding "MSG" generated in the same order in which the corresponding "MSG" messages
messages are received, there is no ordering constraint for replies are received, there is no ordering constraint for replies on
on different channels. different channels.
2.6.3 Pre-emptive Replies 2.6.3 Pre-emptive Replies
A BEEP peer acting in the server role may send a negative reply 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 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 so, that BEEP peer is obliged to ignore any subsequent "MSG" frames
for that message, up to and including the final "MSG" frame. for that message, up to and including the final "MSG" frame.
If a BEEP peer acting in the client role receives a negative reply 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 before it sends the final "MSG" frame for a message, then it is
required to send a "MSG" frame with a continuation status of required to send a "MSG" frame with a continuation status of complete
complete (".") and having a zero-length payload. (".") and having a zero-length payload.
2.6.4 Interference 2.6.4 Interference
If the processing of a particular message has sequencing impacts on If the processing of a particular message has sequencing impacts on
other messages (either intra-channel or inter-channel), then the other messages (either intra-channel or inter-channel), then the
corresponding profile should define this behavior, e.g., a profile corresponding profile should define this behavior, e.g., a profile
whose messages alter the underlying transport mapping. whose messages alter the underlying transport mapping.
2.7 Peer-to-Peer Behavior 2.7 Peer-to-Peer Behavior
BEEP is peer-to-peer -- as such both peers must be prepared to BEEP is peer-to-peer -- as such both peers must be prepared to
receive all messages defined in this memo. Accordingly, an receive all messages defined in this memo. Accordingly, an
initiating BEEP peer capable of acting only in the client role must initiating BEEP peer capable of acting only in the client role must
behave gracefully if it receives a "MSG" message. Accordingly, all behave gracefully if it receives a "MSG" message. Accordingly, all
profiles must provide an appropriate error message for replying to profiles must provide an appropriate error message for replying to
unexpected "MSG" messages. unexpected "MSG" messages.
As a consequence of the peer-to-peer nature of BEEP, message numbers As a consequence of the peer-to-peer nature of BEEP, message numbers
are unidirectionally-significant. That is, the message numbers in are unidirectionally-significant. That is, the message numbers in
"MSG" messages sent by a BEEP peer acting in the initiating role are "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 unrelated to the message numbers in "MSG" messages sent by a BEEP
peer acting in the listening role. peer acting in the listening role.
For example, these two messages For example, these two messages
I: MSG 0 1 . 52 132 I: MSG 0 1 . 52 120
I: Content-Type: application/beep+xml I: Content-Type: application/beep+xml
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> I: <profile uri='http://iana.org/beep/SASL/OTP' />
I: </start> I: </start>
I: END I: END
L: MSG 0 1 . 264 128 L: MSG 0 1 . 221 116
L: Content-Type: application/beep+xml L: Content-Type: application/beep+xml
L: L:
L: <start number='2'> L: <start number='2'>
L: <profile uri='http://xml.resource.org/profiles/IMXP' /> L: <profile uri='http://iana.org/beep/APEX' />
L: </start> L: </start>
L: END L: END
refer to different messages sent on channel zero. refer to different messages sent on channel zero.
3. Transport Security 3. Transport Security
When a BEEP session is established, plaintext transfer, without When a BEEP session is established, plaintext transfer, without
privacy, is provided. Accordingly, transport security in BEEP is privacy, is provided. Accordingly, transport security in BEEP is
achieved using an initial tuning profile. achieved using an initial tuning profile.
This document defines one profile: This document defines one profile:
o the TLS transport security profile, based on TLS version one[3]. o the TLS transport security profile, based on TLS version one [3].
Other profiles may be defined and deployed on a bilateral basis. Other profiles may be defined and deployed on a bilateral basis.
Note that because of their intimate relationship with the transport Note that because of their intimate relationship with the transport
service, a given transport security profile tends to be relevant to service, a given transport security profile tends to be relevant to a
a single transport mapping (c.f., Section 2.5). single transport mapping (c.f., Section 2.5).
When a channel associated with transport security begins the When a channel associated with transport security begins the
underlying negotiation process, all channels (including channel underlying negotiation process, all channels (including channel zero)
zero) are closed on the BEEP session. Accordingly, upon completion are closed on the BEEP session. Accordingly, upon completion of the
of the negotiation process, regardless of its outcome, a new negotiation process, regardless of its outcome, a new greeting is
greeting is issued by both BEEP peers. (If the negotiation process issued by both BEEP peers. (If the negotiation process fails, then
fails, then either BEEP peer may instead terminate the session, and either BEEP peer may instead terminate the session, and it is
it is recommended that a diagnostic entry be logged.) recommended that a diagnostic entry be logged.)
A BEEP peer may choose to issue different greetings based on whether A BEEP peer may choose to issue different greetings based on whether
privacy is in use, e.g., privacy is in use, e.g.,
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 122 L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml L: Content-Type: application/beep+xml
L: L:
L: <greeting> L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' /> L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RPY 0 0 . 0 52 I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I: MSG 0 1 . 52 170 I: MSG 0 1 . 52 158
I: Content-Type: application/beep+xml I: Content-Type: application/beep+xml
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/TLS'> I: <profile uri='http://iana.org/beep/TLS'>
I: <![CDATA[<ready />]]> I: <![CDATA[<ready />]]>
I: </profile> I: </profile>
I: </start> I: </start>
I: END I: END
L: RPY 0 1 . 122 133 L: RPY 0 1 . 110 121
L: Content-Type: application/beep+xml L: Content-Type: application/beep+xml
L: L:
L: <profile uri='http://xml.resource.org/profiles/TLS'> L: <profile uri='http://iana.org/beep/TLS'>
L: <![CDATA[<proceed />]]> L: <![CDATA[<proceed />]]>
L: </profile> L: </profile>
L: END L: END
... successful transport security negotiation ... ... successful transport security negotiation ...
L: RPY 0 0 . 0 264 L: RPY 0 0 . 0 221
L: Content-Type: application/beep+xml L: Content-Type: application/beep+xml
L: L:
L: <greeting> L: <greeting>
L: <profile L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' /> L: <profile uri='http://iana.org/beep/SASL/OTP' />
L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> L: <profile uri='http://iana.org/beep/APEX' />
L: <profile uri='http://xml.resource.org/profiles/IMXP' />
L: </greeting> L: </greeting>
L: END L: END
I: RPY 0 0 . 0 52 I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
Of course, not all BEEP peers need be as single-minded: Of course, not all BEEP peers need be as single-minded:
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 323 L: RPY 0 0 . 0 268
L: Content-Type: application/beep+xml L: Content-Type: application/beep+xml
L: L:
L: <greeting> L: <greeting>
L: <profile L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' /> L: <profile uri='http://iana.org/beep/SASL/OTP' />
L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> L: <profile uri='http://iana.org/beep/APEX' />
L: <profile uri='http://xml.resource.org/profiles/IMXP' /> L: <profile uri='http://iana.org/beep/TLS' />
L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RPY 0 0 . 0 52 I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I: MSG 0 1 . 52 170 I: MSG 0 1 . 52 158
I: Content-Type: application/beep+xml I: Content-Type: application/beep+xml
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/TLS'> I: <profile uri='http://iana.org/beep/TLS'>
I: <![CDATA[<ready />]]> I: <![CDATA[<ready />]]>
I: </profile> I: </profile>
I: </start> I: </start>
I: END I: END
L: RPY 0 1 . 323 133 L: RPY 0 1 . 268 121
L: Content-Type: application/beep+xml L: Content-Type: application/beep+xml
L: L:
L: <profile uri='http://xml.resource.org/profiles/TLS'> L: <profile uri='http://iana.org/beep/TLS'>
L: <![CDATA[<proceed />]]> L: <![CDATA[<proceed />]]>
L: </profile> L: </profile>
L: END L: END
... failed transport security negotiation ... ... failed transport security negotiation ...
L: RPY 0 0 . 0 323 L: RPY 0 0 . 0 268
L: Content-Type: application/beep+xml L: Content-Type: application/beep+xml
L: L:
L: <greeting> L: <greeting>
L: <profile L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' /> L: <profile uri='http://iana.org/beep/SASL/OTP' />
L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> L: <profile uri='http://iana.org/beep/APEX' />
L: <profile uri='http://xml.resource.org/profiles/IMXP' /> L: <profile uri='http://iana.org/beep/TLS' />
L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RPY 0 0 . 0 52 I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
3.1 The TLS Transport Security Profile 3.1 The TLS Transport Security Profile
Section 6.2 contains the registration for this profile. Section 6.2 contains the registration for this profile.
3.1.1 Profile Identification and Initialization 3.1.1 Profile Identification and Initialization
The TLS transport security profile is identified as: The TLS transport security profile is identified as:
http://xml.resource.org/profiles/TLS http://iana.org/beep/TLS
in the BEEP "profile" element during channel creation. in the BEEP "profile" element during channel creation.
During channel creation, the corresponding "profile" element in the During channel creation, the corresponding "profile" element in the
BEEP "start" element may contain a "ready" element. If channel BEEP "start" element may contain a "ready" element. If channel
creation is successful, then before sending the corresponding reply, creation is successful, then before sending the corresponding reply,
the BEEP peer processes the "ready" element and includes the the BEEP peer processes the "ready" element and includes the
resulting response in the reply, e.g., resulting response in the reply, e.g.,
C: MSG 0 1 . 52 170 C: MSG 0 1 . 52 158
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'> C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready />]]> C: <![CDATA[<ready />]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RPY 0 1 . 122 133 S: RPY 0 1 . 110 121
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/TLS'> S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<proceed />]]> S: <![CDATA[<proceed />]]>
S: </profile> S: </profile>
S: END S: END
Note that it is possible for the channel to be created, but for the Note that it is possible for the channel to be created, but for the
encapsulated operation to fail, e.g., encapsulated operation to fail, e.g.,
C: MSG 0 1 . 52 185 C: MSG 0 1 . 52 173
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'> C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready version="oops" />]]> C: <![CDATA[<ready version="oops" />]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RPY 0 1 . 122 205 S: RPY 0 1 . 110 193
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/TLS'> S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<error code='501'>version attribute S: <![CDATA[<error code='501'>version attribute
S: poorly formed in &lt;ready&gt; element</error>]]> S: poorly formed in &lt;ready&gt; element</error>]]>
S: </profile> S: </profile>
S: END S: END
In this case, a positive reply is sent (as channel creation In this case, a positive reply is sent (as channel creation
succeeded), but the encapsulated response contains an indication as succeeded), but the encapsulated response contains an indication as
to why the operation failed. to why the operation failed.
3.1.2 Message Syntax 3.1.2 Message Syntax
skipping to change at page 36, line 18 skipping to change at page 36, line 18
The "ready" element has an optional "version" attribute and no The "ready" element has an optional "version" attribute and no
content: content:
o the "version" element defines the earliest version of TLS o the "version" element defines the earliest version of TLS
acceptable for use. acceptable for use.
When a BEEP peer sends the "ready" element, it must not send any When a BEEP peer sends the "ready" element, it must not send any
further traffic on the underlying transport service until a further traffic on the underlying transport service until a
corresponding reply ("proceed" or "error") is received; similarly, corresponding reply ("proceed" or "error") is received; similarly,
the receiving BEEP peer must wait until any pending replies have the receiving BEEP peer must wait until any pending replies have been
been generated and sent before it processes a "ready" element. generated and sent before it processes a "ready" element.
3.1.3.2 The Proceed Message 3.1.3.2 The Proceed Message
The "proceed" element has no attributes and no content. It is sent The "proceed" element has no attributes and no content. It is sent
as a reply to the "ready" element. as a reply to the "ready" element.
When a BEEP peer receives the "ready" element, it must not send any When a BEEP peer receives the "ready" element, it must not send any
further traffic on the underlying transport service until it further traffic on the underlying transport service until it
generates a corresponding reply. If the BEEP peer decides to allow generates a corresponding reply. If the BEEP peer decides to allow
transport security negotation, it implicitly closes all channels transport security negotiation, it implicitly closes all channels
(including channel zero), and sends the "proceed" element, and (including channel zero), and sends the "proceed" element, and awaits
awaits the underlying negotiation process for transport security. the underlying negotiation process for transport security.
When a BEEP peer receives a "proceed" element in reply to its When a BEEP peer receives a "proceed" element in reply to its "ready"
"ready" message, it implicitly closes all channels (including message, it implicitly closes all channels (including channel zero),
channel zero), and immediately begins the underlying negotiation and immediately begins the underlying negotiation process for
process for transport security. transport security.
4. User Authentication 4. User Authentication
When a BEEP session is established, anonymous access, without trace When a BEEP session is established, anonymous access, without trace
information, is provided. Accordingly, user authentication in BEEP information, is provided. Accordingly, user authentication in BEEP
is achieved using an initial tuning profile. is achieved using an initial tuning profile.
This document defines a family of profiles based on SASL mechanisms: This document defines a family of profiles based on SASL mechanisms:
o each mechanism in the IANA SASL registry[15] has an associated o each mechanism in the IANA SASL registry [15] has an associated
profile. profile.
Other profiles may be defined and deployed on a bilateral basis. Other profiles may be defined and deployed on a bilateral basis.
Whenever a successful authentication occurs, on any channel, the Whenever a successful authentication occurs, on any channel, the
authenticated identity is updated for all existing and future authenticated identity is updated for all existing and future
channels on the BEEP session; further, no additional attempts at channels on the BEEP session; further, no additional attempts at
authentication are allowed. authentication are allowed.
Note that regardless of transport security and user authentication, Note that regardless of transport security and user authentication,
authorization is an internal matter for each BEEP peer. As such, authorization is an internal matter for each BEEP peer. As such,
each peer may choose to restrict the operations it allows based on each peer may choose to restrict the operations it allows based on
the authentication credentials provided (i.e., unauthorized the authentication credentials provided (i.e., unauthorized
operations might be rejected with error code 530). operations might be rejected with error code 530).
4.1 The SASL Family of Profiles 4.1 The SASL Family of Profiles
Section 6.3 contains the registration for this profile. Section 6.3 contains the registration for this profile.
Note that SASL may provide both user authentication and transport Note that SASL may provide both user authentication and transport
security. Once transport security is successfully negotiated for a security. Once transport security is successfully negotiated for a
BEEP session, then a SASL security layer must not be negotiated; BEEP session, then a SASL security layer must not be negotiated;
similarly, once any SASL negotiation is successful, a transport similarly, once any SASL negotiation is successful, a transport
security profile must not begin its underlying negotiation process. security profile must not begin its underlying negotiation process.
Section 4 of the SASL specification[4] requires the following Section 4 of the SASL specification [4] requires the following
information be supplied by a protocol definition: information be supplied by a protocol definition:
service name: "beep" service name: "beep"
initiation sequence: Creating a channel using a BEEP profile initiation sequence: Creating a channel using a BEEP profile
corresponding to a SASL mechanism starts the exchange. An corresponding to a SASL mechanism starts the exchange. An
optional parameter corresponding to the "initial response" sent optional parameter corresponding to the "initial response" sent by
by the client is carried within a "blob" element during channel the client is carried within a "blob" element during channel
creation. creation.
exchange sequence: "Challenges" and "responses" are carried in exchange sequence: "Challenges" and "responses" are carried in
exchanges of the "blob" element. The "status" attribute of the exchanges of the "blob" element. The "status" attribute of the
"blob" element is used both by a server indicating a successful "blob" element is used both by a server indicating a successful
completion of the exchange, and a client aborting the exchange, completion of the exchange, and a client aborting the exchange,
The server indicates failure of the exchange by sending an The server indicates failure of the exchange by sending an "error"
"error" element. element.
security layer negotiation: When a security layer starts security layer negotiation: When a security layer starts negotiation,
negotiation, all channels (including channel zero) are closed on all channels (including channel zero) are closed on the BEEP
the BEEP session. Accordingly, upon completion of the negotiation session. Accordingly, upon completion of the negotiation process,
process, regardless of its outcome, a new greeting is issued by regardless of its outcome, a new greeting is issued by both BEEP
both BEEP peers. peers.
If a security layer is successfully negotiated, it takes effect If a security layer is successfully negotiated, it takes effect
immediately following the message that concludes the server's immediately following the message that concludes the server's
successful completion reply. successful completion reply.
use of the authorization identity: This is made available to all use of the authorization identity: This is made available to all
channels for the duration of the BEEP session. channels for the duration of the BEEP session.
4.1.1 Profile Identification and Initialization 4.1.1 Profile Identification and Initialization
Each SASL mechanism registered with the IANA is identified as: Each SASL mechanism registered with the IANA is identified as:
http://xml.resource.org/profiles/sasl/MECHANISM http://iana.org/beep/SASL/mechanism
where "MECHANISM" is the token assigned to that mechanism by the where "MECHANISM" is the token assigned to that mechanism by the
IANA. IANA.
Note that during channel creation, a BEEP peer may provide multiple Note that during channel creation, a BEEP peer may provide multiple
profiles to the remote peer, e.g., profiles to the remote peer, e.g.,
C: MSG 0 1 . 52 209 C: MSG 0 1 . 52 178
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
C: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' /> C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start> C: </start>
C: END C: END
S: RPY 0 1 . 264 99 S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> S: <profile uri='http://iana.org/beep/SASL/OTP' />
S: END S: END
During channel creation, the corresponding "profile" element in the During channel creation, the corresponding "profile" element in the
BEEP "start" element may contain a "blob" element. Note that it is BEEP "start" element may contain a "blob" element. Note that it is
possible for the channel to be created, but for the encapsulated possible for the channel to be created, but for the encapsulated
operation to fail, e.g., operation to fail, e.g.,
C: MSG 0 1 . 52 195 C: MSG 0 1 . 52 183
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> C: <profile uri='http://iana.org/beep/SASL/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]> C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RPY 0 1 . 264 190 S: RPY 0 1 . 221 178
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> S: <profile uri='http://iana.org/beep/SASL/OTP'>
S: <![CDATA[<error code='534'>authentication mechanism is S: <![CDATA[<error code='534'>authentication mechanism is
S: too weak</error>]]> S: too weak</error>]]>
S: </profile> S: </profile>
S: END S: END
In this case, a positive reply is sent (as channel creation In this case, a positive reply is sent (as channel creation
succeeded), but the encapsulated response contains an indication as succeeded), but the encapsulated response contains an indication as
to why the operation failed. to why the operation failed.
Otherwise, the server sends a challenge (or signifies success), e.g., Otherwise, the server sends a challenge (or signifies success), e.g.,
C: MSG 0 1 . 52 195 C: MSG 0 1 . 52 183
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> C: <profile uri='http://iana.org/beep/SASL/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]> C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RPY 0 1 . 264 183 S: RPY 0 1 . 221 171
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> S: <profile uri='http://iana.org/beep/SASL/OTP'>
S: <![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ= S: <![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
</blob>]]> </blob>]]>
S: </profile> S: </profile>
S: END S: END
Note that this example implies that the "blob" element in the Note that this example implies that the "blob" element in the
server's reply appears on two lines -- this is an artifact of the server's reply appears on two lines -- this is an artifact of the
presentation; in fact, only one line is used. presentation; in fact, only one line is used.
If a challenge is received, then the client responds and awaits If a challenge is received, then the client responds and awaits
skipping to change at page 41, line 31 skipping to change at page 41, line 34
sending "<blob status='abort' />" instead. sending "<blob status='abort' />" instead.
Alternatively, the server might reject the response with an error: Alternatively, the server might reject the response with an error:
e.g., e.g.,
C: MSG 1 0 . 0 97 C: MSG 1 0 . 0 97
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob> C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END C: END
S: ERR 1 1 . 0 60 S: ERR 1 0 . 0 60
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <error code='535' /> S: <error code='535' />
S: END S: END
Finally, depending on the SASL mechanism, an initialization element Finally, depending on the SASL mechanism, an initialization element
may be exchanged unidirectionally during channel creation, e.g., may be exchanged unidirectionally during channel creation, e.g.,
C: MSG 0 1 . 52 145 C: MSG 0 1 . 52 125
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile C: <profile uri='http://iana.org/beep/SASL/CRAM-MD5' />
C: uri='http://xml.resource.org/profiles/sasl/CRAM-MD5' />
C: </start> C: </start>
C: END C: END
S: RPY 0 1 . 264 197 S: RPY 0 1 . 221 185
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/sasl/CRAM-MD5'> S: <profile uri='http://iana.org/beep/SASL/CRAM-MD5'>
S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1 S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
jaS5uZXQ+</blob>]]> jaS5uZXQ+</blob>]]>
S: </profile> S: </profile>
S: END S: END
Note that this example implies that the "blob" element in the Note that this example implies that the "blob" element in the
server's reply appears on two lines -- this is an artifact of the server's reply appears on two lines -- this is an artifact of the
presentation; in fact, only one line is used. presentation; in fact, only one line is used.
4.1.2 Message Syntax 4.1.2 Message Syntax
skipping to change at page 43, line 27 skipping to change at page 43, line 27
continue: used by either a client or server, otherwise. continue: used by either a client or server, otherwise.
Finally, note that SASL's EXTERNAL mechanism works with an "external Finally, note that SASL's EXTERNAL mechanism works with an "external
authentication" service, which is provided by one of: authentication" service, which is provided by one of:
o a transport security profile, capable of providing authentication o a transport security profile, capable of providing authentication
information (e.g., Section 3.1), being active on the connection; information (e.g., Section 3.1), being active on the connection;
o a network service, capable of providing strong authentication o a network service, capable of providing strong authentication
(e.g., IPSec[12]), underlying the connection; or, (e.g., IPSec [12]), underlying the connection; or,
o a locally-defined security service. o a locally-defined security service.
For authentication to succeed, two conditions must hold: For authentication to succeed, two conditions must hold:
o an external authentication service must be active; and, o an external authentication service must be active; and,
o if present, the authentication identity must be consistent with o if present, the authentication identity must be consistent with
the credentials provided by the external authentication service the credentials provided by the external authentication service
(if the authentication identity is empty, then an authorization (if the authentication identity is empty, then an authorization
identity is automatically derived from the credentials provided identity is automatically derived from the credentials provided by
by the external authentication service). the external authentication service).
5. Registration Templates 5. Registration Templates
5.1 Profile Registration Template 5.1 Profile Registration Template
When a profile is registered, the following information is supplied: When a profile is registered, the following information is supplied:
Profile Identification: specify a URI[10] that authoritatively Profile Identification: specify a URI [10] that authoritatively
identifies this profile. identifies this profile.
Message Exchanged during Channel Creation: specify the datatypes Message Exchanged during Channel Creation: specify the datatypes that
that may be exchanged during channel creation. may be exchanged during channel creation.
Messages starting one-to-one exchanges: specify the datatypes that Messages starting one-to-one exchanges: specify the datatypes that
may be present when an exchange starts. may be present when an exchange starts.
Messages in positive replies: specify the datatypes that may be Messages in positive replies: specify the datatypes that may be
present in a positive reply. present in a positive reply.
Messages in negative replies: specify the datatypes that may be Messages in negative replies: specify the datatypes that may be
present in a negative reply. present in a negative reply.
skipping to change at page 44, line 44 skipping to change at page 44, line 44
Contact Information: specify the postal and electronic contact Contact Information: specify the postal and electronic contact
information for the author of the profile. information for the author of the profile.
5.2 Feature Registration Template 5.2 Feature Registration Template
When a feature for the channel management profile is registered, the When a feature for the channel management profile is registered, the
following information is supplied: following information is supplied:
Feature Identification: specify a string that identifies this Feature Identification: specify a string that identifies this
feature. Unless the feature is registered with the IANA, the feature. Unless the feature is registered with the IANA, the
feature's identification must start with "x-". feature's identification must start with "x-".
Feature Semantics: specify the semantics of the feature. Feature Semantics: specify the semantics of the feature.
Contact Information: specify the postal and electronic contact Contact Information: specify the postal and electronic contact
information for the author of the feature. information for the author of the feature.
6. Initial Registrations 6. Initial Registrations
6.1 Registration: BEEP Channel Management 6.1 Registration: BEEP Channel Management
skipping to change at page 45, line 30 skipping to change at page 45, line 30
Message Syntax: c.f., Section 7.1 Message Syntax: c.f., Section 7.1
Message Semantics: c.f., Section 2.3.1 Message Semantics: c.f., Section 2.3.1
Contact Information: c.f., the "Author's Address" section of this Contact Information: c.f., the "Author's Address" section of this
memo memo
6.2 Registration: TLS Transport Security Profile 6.2 Registration: TLS Transport Security Profile
Profile Identification: http://xml.resource.org/profiles/TLS Profile Identification: http://iana.org/beep/TLS
Messages exchanged during Channel Creation: "ready" Messages exchanged during Channel Creation: "ready"
Messages starting one-to-one exchanges: "ready" Messages starting one-to-one exchanges: "ready"
Messages in positive replies: "proceed" Messages in positive replies: "proceed"
Messages in negative replies: "error" Messages in negative replies: "error"
Messages in one-to-many exchanges: none Messages in one-to-many exchanges: none
Message Syntax: c.f., Section 7.2 Message Syntax: c.f., Section 7.2
Message Semantics: c.f., Section 3.1.3 Message Semantics: c.f., Section 3.1.3
Contact Information: c.f., the "Author's Address" section of this Contact Information: c.f., the "Author's Address" section of this
memo memo
6.3 Registration: SASL Family of Profiles 6.3 Registration: SASL Family of Profiles
Profile Identification: Profile Identification: http://iana.org/beep/SASL/mechanism, where
http://xml.resource.org/profiles/sasl/MECHANISM, where "mechanism" is a token registered with the IANA
"MECHANISM" is a token registered with the IANA[16]
Messages exchanged during Channel Creation: "blob" Messages exchanged during Channel Creation: "blob"
Messages starting one-to-one exchanges: "blob" Messages starting one-to-one exchanges: "blob"
Messages in positive replies: "blob" Messages in positive replies: "blob"
Messages in negative replies: "error" Messages in negative replies: "error"
Messages in one-to-many exchanges: none Messages in one-to-many exchanges: none
skipping to change at page 47, line 13 skipping to change at page 47, line 13
memo memo
6.4 Registration: application/beep+xml 6.4 Registration: application/beep+xml
MIME media type name: application MIME media type name: application
MIME subtype name: beep+xml MIME subtype name: beep+xml
Required parameters: none Required parameters: none
Optional parameters: charset (defaults to "UTF-8"[13]) Optional parameters: charset (defaults to "UTF-8" [13])
Encoding considerations: This media type may contain binary content; Encoding considerations: This media type may contain binary content;
accordingly, when used over a transport that does not permit accordingly, when used over a transport that does not permit
binary transfer, an appropriate encoding must be applied binary transfer, an appropriate encoding must be applied
Security considerations: none, per se; however, any BEEP profile Security considerations: none, per se; however, any BEEP profile
which uses this media type must describe its relevant security which uses this media type must describe its relevant security
considerations considerations
Interoperability considerations: n/a Interoperability considerations: n/a
Published specification: This media type is a proper subset of the Published specification: This media type is a proper subset of the
the XML 1.0 specification[2]. Two restrictions are made. the XML 1.0 specification [2]. Two restrictions are made.
First, no entity references other than the five predefined First, no entity references other than the five predefined general
general entities references ("&amp;", "&lt;", "&gt;", "&apos;", entities references ("&amp;", "&lt;", "&gt;", "&apos;", and
and "&quot;") and numeric entity references may be present. "&quot;") and numeric entity references may be present.
Second, neither the "XML" declaration (e.g., <?xml version="1.0" Second, neither the "XML" declaration (e.g., <?xml version="1.0"
?>) nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) may be ?>) nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) may be
present. (Accordingly, if another character set other than UTF-8 present. (Accordingly, if another character set other than UTF-8
is desired, then the "charset" parameter must be present.) is desired, then the "charset" parameter must be present.)
All other XML 1.0 instructions (e.g., CDATA blocks, processing All other XML 1.0 instructions (e.g., CDATA blocks, processing
instructions, and so on) are allowed. instructions, and so on) are allowed.
Applications which use this media type: any BEEP profile wishing to Applications which use this media type: any BEEP profile wishing to
make use of this XML 1.0 subset make use of this XML 1.0 subset
Additional Information: none Additional Information: none
Contact for further information: c.f., the "Author's Address" Contact for further information: c.f., the "Author's Address" section
section of this memo of this memo
Intended usage: limited use Intended usage: limited use
Author/Change controller: the IESG Author/Change controller: the IESG
7. DTDs 7. DTDs
7.1 BEEP Channel Management DTD 7.1 BEEP Channel Management DTD
<!-- <!--
DTD for BEEP Channel Management, as of 2000-10-29 DTD for BEEP Channel Management, as of 2000-10-29
Refer to this DTD as: Refer to this DTD as:
<!ENTITY % BEEP PUBLIC "-//Blocks//DTD BEEP//EN" <!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN"
"http://xml.resource.org/profiles/BEEP/beep.dtd"> "http://xml.resource.org/profiles/BEEP/beep.dtd">
%BEEP; %BEEP;
--> -->
<!-- <!--
DTD data types: DTD data types:
entity syntax/reference example entity syntax/reference example
====== ================ ======= ====== ================ =======
a channel number a channel number
CHAN 1..2147483647 1 CHAN 1..2147483647 1
authoritative profile identification authoritative profile identification
URI c.f., [RFC-2396] http://invisible.net/ URI c.f., [RFC-2396] http://invisible.net/
one or more feature tokens, seperated by space one or more feature tokens, separated by space
FTRS NMTOKENS "magic" FTRS NMTOKENS "magic"
a language tag a language tag
LANG c.f., [RFC-1766] "en", "en-US", etc. LANG c.f., [RFC-1766] "en", "en-US", etc.
zero or more language tags zero or more language tags
LOCS NMTOKENS "en-US" LOCS NMTOKENS "en-US"
a 3-digit reply code a 3-digit reply code
XYZ [1-5][0-9][0-9] 500 XYZ [1-5][0-9][0-9] 500
skipping to change at page 49, line 7 skipping to change at page 49, line 7
<!ENTITY % CHAN "CDATA"> <!ENTITY % CHAN "CDATA">
<!ENTITY % URI "CDATA"> <!ENTITY % URI "CDATA">
<!ENTITY % FTRS "NMTOKENS"> <!ENTITY % FTRS "NMTOKENS">
<!ENTITY % LANG "NMTOKEN"> <!ENTITY % LANG "NMTOKEN">
<!ENTITY % LOCS "NMTOKEN"> <!ENTITY % LOCS "NMTOKEN">
<!ENTITY % XYZ "CDATA"> <!ENTITY % XYZ "CDATA">
<!-- <!--
BEEP messages, exchanged as application/beep+xml BEEP messages, exchanged as application/beep+xml
role MSG RSP ERR role MSG RPY ERR
======= === === === ======= === === ===
I and L greeting error I and L greeting error
I or L start profile error I or L start profile error
I or L close ok error I or L close ok error
--> -->
<!ELEMENT greeting (profile)*> <!ELEMENT greeting (profile)*>
<!ATTLIST greeting <!ATTLIST greeting
skipping to change at page 50, line 12 skipping to change at page 50, line 12
code %XYZ; #REQUIRED code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED> xml:lang %LANG; #IMPLIED>
7.2 TLS Transport Security Profile DTD 7.2 TLS Transport Security Profile DTD
<!-- <!--
DTD for the TLS Transport Security Profile, as of 2000-09-04 DTD for the TLS Transport Security Profile, as of 2000-09-04
Refer to this DTD as: Refer to this DTD as:
<!ENTITY % TLS PUBLIC "-//Blocks//DTD TLS//EN" <!ENTITY % TLS PUBLIC "-//IETF//DTD TLS//EN"
"http://xml.resource.org/profiles/TLS/tls.dtd"> "http://xml.resource.org/profiles/TLS/tls.dtd">
%TLS; %TLS;
--> -->
<!-- <!--
TLS messages, exchanged as application/beep+xml TLS messages, exchanged as application/beep+xml
role MSG RSP ERR role MSG RPY ERR
====== === === === ====== === === ===
I or L ready proceed error I or L ready proceed error
--> -->
<!ELEMENT ready EMPTY> <!ELEMENT ready EMPTY>
<!ATTLIST ready <!ATTLIST ready
version CDATA "1"> version CDATA "1">
<!ELEMENT proceed EMPTY> <!ELEMENT proceed EMPTY>
7.3 SASL Family of Profiles DTD 7.3 SASL Family of Profiles DTD
<!-- <!--
DTD for the SASL Family of Profiles, as of 2000-09-04 DTD for the SASL Family of Profiles, as of 2000-09-04
Refer to this DTD as: Refer to this DTD as:
<!ENTITY % SASL PUBLIC "-//Blocks//DTD SASL//EN" <!ENTITY % SASL PUBLIC "-//IETF//DTD SASL//EN"
"http://xml.resource.org/profiles/sasl/sasl.dtd"> "http://xml.resource.org/profiles/sasl/sasl.dtd">
%SASL; %SASL;
--> -->
<!-- <!--
SASL messages, exchanged as application/beep+xml SASL messages, exchanged as application/beep+xml
role MSG RSP ERR role MSG RPY ERR
====== === === === ====== === === ===
I or L blob blob error I or L blob blob error
--> -->
<!ELEMENT blob (#PCDATA)> <!ELEMENT blob (#PCDATA)>
<!ATTLIST blob <!ATTLIST blob
xml:space (default|preserve) xml:space (default|preserve)
"preserve" "preserve"
status (abort|complete|continue) status (abort|complete|continue)
"continue"> "continue">
skipping to change at page 53, line 19 skipping to change at page 53, line 19
varying degrees of assurance: varying degrees of assurance:
1. If one of the profiles from the SASL family is used, refer to 1. If one of the profiles from the SASL family is used, refer to
[4]'s Section 9 for a discussion of security considerations. [4]'s Section 9 for a discussion of security considerations.
2. If the TLS transport security profile is used (or if a SASL 2. If the TLS transport security profile is used (or if a SASL
security layer is negotiated), then: security layer is negotiated), then:
1. A man-in-the-middle may remove the security-related profiles 1. A man-in-the-middle may remove the security-related profiles
from the BEEP greeting or generate a negative reply to the from the BEEP greeting or generate a negative reply to the
"ready" element of the TLS transport security profile. A "ready" element of the TLS transport security profile. A
BEEP peer may be configurable to refuse to proceed without BEEP peer may be configurable to refuse to proceed without an
an acceptable level of privacy. acceptable level of privacy.
2. A man-in-the-middle may cause a down-negotiation to the 2. A man-in-the-middle may cause a down-negotiation to the
weakest cipher suite available. A BEEP peer should be weakest cipher suite available. A BEEP peer should be
configurable to refuse weak cipher suites. configurable to refuse weak cipher suites.
3. A man-in-the-middle may modify any protocol exchanges prior 3. A man-in-the-middle may modify any protocol exchanges prior
to a successful negotiation. Upon completing the to a successful negotiation. Upon completing the
negotiation, a BEEP peer must discard previously cached negotiation, a BEEP peer must discard previously cached
information about the BEEP session. information about the BEEP session.
As different TLS ciphersuites provide varying levels of As different TLS ciphersuites provide varying levels of security,
security, administrators should carefully choose which administrators should carefully choose which ciphersuites are
ciphersuites are provisioned. provisioned.
As BEEP is peer-to-peer in nature, before performing any task As BEEP is peer-to-peer in nature, before performing any task
associated with a message, each channel should apply the appropriate associated with a message, each channel should apply the appropriate
access control based on the authenticated identity and privacy level access control based on the authenticated identity and privacy level
associated with the BEEP session. associated with the BEEP session.
References References
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message Bodies",
Bodies", RFC 2045, November 1996. RFC 2045, November 1996.
[2] World Wide Web Consortium, "Extensible Markup Language (XML) [2] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-
<http://www.w3.org/TR/1998/REC-xml-19980210>. xml-19980210>.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A. [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246, P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
January 1999. 1999.
[4] Myers, J.G., "Simple Authentication and Security Layer [4] Myers, J., "Simple Authentication and Security Layer (SASL)",
(SASL)", RFC 2222, October 1997. RFC 2222, October 1997.
[5] Rose, M.T., "Mapping the BEEP Core onto TCP", [5] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
draft-ietf-beep-tcpmapping-06 (work in progress), January 2001. 2001.
[6] Postel, J., "Transmission Control Protocol", RFC 793, STD 7, [6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
Sep 1981. September 1981.
[7] Crocker, D. H. and P. Overell, "Augmented BNF for Syntax [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[8] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [8] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[9] Alvestrand, H., "Tags for the Identification of Languages", [9] Alvestrand, H., "Tags for the Identification of Languages", RFC
RFC 1766, March 1995. BCP 47, RFC 3066, January 2001.
[10] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform [10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998. 1998.
[11] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, [11] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
October 1998. October 1998.
[12] Kent, S. and R. Atkinson, "Security Architecture for the [12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
RFC 2279, January 1998. 2279, January 1998.
[14] Linn, J., "Generic Security Service Application Program [14] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997. Interface, Version 2", RFC 2078, January 1997.
[15] <http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms> [15] <http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms>
[16] <http://www.iana.org/>
Author's Address Author's Address
Marshall T. Rose Marshall T. Rose
Invisible Worlds, Inc. Invisible Worlds, Inc.
1179 North McDowell Boulevard 1179 North McDowell Boulevard
Petaluma, CA 94954-6559 Petaluma, CA 94954-6559
US US
Phone: +1 707 789 3700 Phone: +1 707 789 3700
EMail: mrose@invisible.net EMail: mrose@invisible.net
URI: http://invisible.net/ URI: http://invisible.net/
Appendix A. Acknowledgements Appendix A. Acknowledgements
The author gratefully acknowledges the contributions of: David The author gratefully acknowledges the contributions of: David Clark,
Clark, Dave Crocker, Steve Deering, Wesley Michael Eddy, Huston Dave Crocker, Steve Deering, Wesley Michael Eddy, Huston Franklin,
Franklin, Marco Gazzetta, Danny Goodman, Steve Harris, Robert Marco Gazzetta, Danny Goodman, Steve Harris, Robert Herriot, Ken
Herriot, Ken Hirsch, Greg Hudson, Ben Laurie, Carl Malamud, Michael Hirsch, Greg Hudson, Ben Laurie, Carl Malamud, Michael Mealling,
Mealling, Keith McCloghrie, Paul Mockapetris, RL 'Bob' Morgan, Frank Keith McCloghrie, Paul Mockapetris, RL 'Bob' Morgan, Frank Morton,
Morton, Darren New, Chris Newman, Joe Touch, Paul Vixie, Gabe Darren New, Chris Newman, Joe Touch, Paul Vixie, Gabe Wachob, Daniel
Wachob, Daniel Woods, and, James Woodyatt. In particular, Dave Woods, and, James Woodyatt. In particular, Dave Crocker provided
Crocker provided helpful suggestions on the nature of segmentation helpful suggestions on the nature of segmentation in the framing
in the framing mechanism. mechanism.
Appendix B. IANA Considerations Appendix B. IANA Considerations
The IANA registers "beep" as a GSSAPI[14] service name, as specified The IANA registers "beep" as a GSSAPI [14] service name, as specified
in Section 4.1. in Section 4.1.
The IANA maintains a list of: The IANA maintains a list of:
o standards-track BEEP profiles, c.f., Section 5.1; and, o standards-track BEEP profiles, c.f., Section 5.1; and,
o standards-track features for the channel management profile, o standards-track features for the channel management profile, c.f.,
c.f., Section 5.2. Section 5.2.
For each list, the IESG is responsible for assigning a designated For each list, the IESG is responsible for assigning a designated
expert to review the specification prior to the IANA making the expert to review the specification prior to the IANA making the
assignment. As a courtesy to developers of non-standards track BEEP assignment. As a courtesy to developers of non-standards track BEEP
profiles and channel management features, the mailing list profiles and channel management features, the mailing list
bxxpwg@invisible.net may be used to solicit commentary. bxxpwg@invisible.net may be used to solicit commentary.
The IANA makes the registrations specified in Section 6.2 and The IANA makes the registrations specified in Section 6.2 and Section
Section 6.3. It is recommended that the IANA register these profiles 6.3. It is recommended that the IANA register these profiles using
using the IANA as a URI-prefix, and populate those URIs with the the IANA as a URI-prefix, and populate those URIs with the respective
respective profile registrations. profile registrations.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 214 change blocks. 
370 lines changed or deleted 345 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/