draft-ietf-beep-framework-00.txt   draft-ietf-beep-framework-01.txt 
Network Working Group M.T. Rose Network Working Group M.T. Rose
Internet-Draft Invisible Worlds, Inc. Internet-Draft Invisible Worlds, Inc.
Expires: February 20, 2001 August 22, 2000 Expires: March 12, 2001 September 11, 2000
The Blocks eXtensible eXchange Protocol Framework The Blocks eXtensible eXchange Protocol Framework
draft-ietf-beep-framework-00 draft-ietf-beep-framework-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 20, 2001. This Internet-Draft will expire on March 12, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
This memo describes a generic application protocol framework for This memo describes a generic application protocol framework for
connection-oriented, asynchronous request/response interactions. The connection-oriented, asynchronous interactions. The framework
framework permits parallel independent request/response streams permits simultaneous and independent exchanges within the context of
within the context of a single application user-identity, supporting a single application user-identity, supporting both textual and
both textual and binary messages. binary messages.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. The BXXP Framework . . . . . . . . . . . . . . . . . . . . 5 2. The BXXP Framework . . . . . . . . . . . . . . . . . . . . 5
2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 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
2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 13 2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 14 2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 14
2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15 2.2.2.1 Poorly-formed Messages . . . . . . . . . . . . . . . . . . 14
2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 16 2.2.2.2 XML-based Profiles . . . . . . . . . . . . . . . . . . . . 15
2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 17
2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 17
2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 18 2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 18
2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 20 2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 20
2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 21 2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 22 2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 22
2.4 Session Establishment and Release . . . . . . . . . . . . 24 2.4 Session Establishment and Release . . . . . . . . . . . . 24
2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 26 2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 26
2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 26 2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 26
2.5.2 Data Exchange . . . . . . . . . . . . . . . . . . . . . . 26 2.5.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . 26
2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 27 2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 27
2.6.1 Within a single channel . . . . . . . . . . . . . . . . . 27 2.6.1 Within a Single Channel . . . . . . . . . . . . . . . . . 27
2.6.2 Between different channels . . . . . . . . . . . . . . . . 27 2.6.2 Between Different Channels . . . . . . . . . . . . . . . . 27
2.6.3 Pre-emptive responses . . . . . . . . . . . . . . . . . . 27 2.6.3 Pre-emptive Replies . . . . . . . . . . . . . . . . . . . 27
2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 27
2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 28 2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 28
3. Transport Security . . . . . . . . . . . . . . . . . . . . 29 3. Transport Security . . . . . . . . . . . . . . . . . . . . 29
3.1 The TLS Transport Security Profile . . . . . . . . . . . . 32 3.1 The TLS Transport Security Profile . . . . . . . . . . . . 32
3.1.1 Profile Identification and Initialization . . . . . . . . 32 3.1.1 Profile Identification and Initialization . . . . . . . . 32
3.1.2 Request and Response Messages . . . . . . . . . . . . . . 33 3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 33
3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 34 3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 33
3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 34 3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 33
3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 34 3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 33
4. User Authentication . . . . . . . . . . . . . . . . . . . 35 4. User Authentication . . . . . . . . . . . . . . . . . . . 35
4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 36 4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 36
4.1.1 Profile Identification and Initialization . . . . . . . . 37 4.1.1 Profile Identification and Initialization . . . . . . . . 37
4.1.2 Request and Response Messages . . . . . . . . . . . . . . 39 4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 39
4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 40 4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 40
5. Profile Registration Template . . . . . . . . . . . . . . 41 5. Profile Registration Template . . . . . . . . . . . . . . 41
6. Initial Profile Registrations . . . . . . . . . . . . . . 42 6. Initial Profile Registrations . . . . . . . . . . . . . . 42
6.1 BXXP Channel Management . . . . . . . . . . . . . . . . . 42 6.1 BXXP Channel Management . . . . . . . . . . . . . . . . . 42
6.2 BXXP Channel Management DTD . . . . . . . . . . . . . . . 43 6.2 BXXP Channel Management DTD . . . . . . . . . . . . . . . 43
6.3 Registration: TLS Transport Security Profile . . . . . . . 46 6.3 Registration: TLS Transport Security Profile . . . . . . . 45
6.4 TLS Transport Security Profile DTD . . . . . . . . . . . . 47 6.4 TLS Transport Security Profile DTD . . . . . . . . . . . . 46
6.5 Registration: SASL Family of Profiles . . . . . . . . . . 48 6.5 Registration: SASL Family of Profiles . . . . . . . . . . 47
6.6 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 49 6.6 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 48
7. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 50 7. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 49
8. Security Considerations . . . . . . . . . . . . . . . . . 51 8. Security Considerations . . . . . . . . . . . . . . . . . 50
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 52 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 51
References . . . . . . . . . . . . . . . . . . . . . . . . 53 References . . . . . . . . . . . . . . . . . . . . . . . . 52
Author's Address . . . . . . . . . . . . . . . . . . . . . 54 Author's Address . . . . . . . . . . . . . . . . . . . . . 53
A. Changes from draft-mrose-bxxp-framework-01 . . . . . . . . 55 A. Changes from draft-ietf-beep-framework-00 . . . . . . . . 54
B. Changes from draft-mrose-bxxp-framework-00 . . . . . . . . 56 B. Changes from draft-mrose-bxxp-framework-01 . . . . . . . . 55
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 57 C. Changes from draft-mrose-bxxp-framework-00 . . . . . . . . 56
D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 57
Full Copyright Statement . . . . . . . . . . . . . . . . . 58 Full Copyright Statement . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
This memo describes a generic application protocol framework for This memo describes a generic application protocol framework for
connection-oriented, asynchronous request/response interactions. connection-oriented, asynchronous interactions. Consult [1] for a
Consult [1] for a description of the framework's design principles. description of the framework's design principles.
At the core of the BXXP framework is a framing mechanism that allows At the core of the BXXP framework is a framing mechanism that
for peer-to-peer exchanges of requests and responses. The framing permits simultaneous and independent exchanges of messages between
mechanism permits multiple simultaneous and independent exchanges. peers. Messages are arbitrary MIME[2] content, but are usually
Requests and responses are arbitrary MIME[3] content, but are textual (structured using XML[3]).
usually textual (structured using XML[2]).
Frames are exchanged in the context of a "channel". Each channel has Frames are exchanged in the context of a "channel". Each channel has
an associated "profile" that defines the syntax and semantics of the an associated "profile" that defines the syntax and semantics of the
messages exchanged. Implicit in the operation of BXXP is the notion messages exchanged. Implicit in the operation of BXXP is the notion
of channel management. In addition to defining BXXP's channel of channel management. In addition to defining BXXP's channel
management profile, this document defines: management profile, this document defines:
o the TLS[4] transport security profile; and, o the TLS[4] transport security profile; and,
o the SASL[5] family of profiles. o the SASL[5] 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. A registration template is an application protocol designer. A registration template is
provided for this purpose. provided for this purpose.
2. The BXXP Framework 2. The BXXP Framework
The BXXP framework is message-oriented. Arbitrary octets are The BXXP framework is message-oriented. All exchanges occur in the
encapsulated within a frame and tagged as either a request or a context of a channel -- a binding to a well-defined aspect of the
response. All interactions occur in the context of a channel -- a application, such as transport security, user authentication, or
binding to a well-defined aspect of the application, such as data exchange.
transport security, user authentication, or data exchange.
A BXXP session is mapped onto an underlying transport service. A A BXXP 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 BXXP session. For example, [6] describes how a service realizes a BXXP session. For example, [6] describes how a
BXXP session is mapped onto a single TCP[7] connection. BXXP session is mapped onto a single TCP[7] connection.
During the creation of a channel, the requestor supplies one or more During the creation of a channel, the client supplies one or more
proposed profiles for that channel. If the responder creates the proposed profiles for that channel. If the server creates the
channel, it selects one of the profiles and returns it in a channel, it selects one of the profiles and sends it in a reply;
response; otherwise, it may indicate that none of the profiles are otherwise, it may indicate that none of the profiles are acceptable,
acceptable, and decline creation of the channel. 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 BXXP session is established (e.g., initialization once the BXXP session is established (e.g.,
negotiating the use of transport security); although several negotiating the use of transport security); although several
request/response exchanges may be required to perform the exchanges may be required to perform the initialization, these
initialization, these channels become inactive early in the BXXP channels become inactive early in the BXXP session and remain so
session and remain so for the duration. for the duration.
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.
A BXXP peer should support at least 257 concurrently opened channels.
2.1 Roles 2.1 Roles
Although BXXP is peer-to-peer, it is convenient to label each peer Although BXXP is peer-to-peer, it is convenient to label each peer
in the context of the role it is performing at a given time: in the context of the role it is performing at a given time:
o When a BXXP session is established, we designate the peer that o When a BXXP session is established, the peer that awaits new
awaits new connections as acting in the listening role, and the connections is acting in the listening role, and the other peer,
other peer, which establishes a connection to the listener, as which establishes a connection to the listener, is acting in the
acting in the initiating role. In the examples which follow, initiating role. In the examples which follow, these are referred
these are referred to as "I:" and "L:", respectively. to as "L:" and "I:", respectively.
o We designate a BXXP peer making a request as a client (or o A BXXP peer starting an exchange is termed the client; similarly,
requestor); similarly, we designate the other BXXP peer as a the other BXXP peer is termed the server. In the examples which
server (or responder). In the examples which follow, these are follow, these are referred to as "C:" and "S:", respectively.
referred to as "C:" and "S:", respectively.
Typically, a BXXP peer acting in the server role is also acting in a Typically, a BXXP peer acting in the server role is also acting in a
listening role. However, because BXXP is peer-to-peer in nature, no listening role. However, because BXXP is peer-to-peer in nature, no
such requirement exists. such requirement exists.
2.1.1 Exchange Styles
BXXP allows three styles of exchange:
MSG/RPY: the client sends a "MSG" message asking the server to
perform some task, the server performs the task and replies with
a "RPY" message (termed a positive reply).
MSG/ERR: the client sends a "MSG" message, the server does not
perform any task and replies with an "ERR" message (termed a
negative reply).
MSG/ANS: the client sends a "MSG" message, the server, during the
course of performing some task, replies with zero or more "ANS"
messages, and, upon completion of the task, sends a "NUL"
message, which signifies the end of the reply.
The first two styles are termed one-to-one exchanges, whilst the
third style is termed a one-to-many exchange.
2.2 Messages and Frames 2.2 Messages and Frames
In BXXP, there are two kinds of messages: requests and responses. A message is structured according to the rules of MIME. Accordingly,
the payload may begin with "entity-headers" (c.f., MIME[2]'s Section
3). If none, or only some, of the "entity-headers" are present:
Each message conveys data content. Normally, a message is sent in a o the default "Content-Type" is "text/xml"; and,
single frame. However, it may be convenient or necesary to segment
the data content of a message into multiple frames. (e.g., if only o the default "Content-Transfer-Encoding" is "binary".
part of a message is ready to be sent). When a message is segmented
and sent as several frames, those frames must be sent sequentally, Hence, in the absence of typing information, a message is a
without any intervening frames from other messages on the same well-formed XML[3] document.
channel.
Normally, a message is sent in a single frame. However, it may be
convenient or necesary to segment a message into multiple frames
(e.g., if only part of a message is ready to be sent).
Each frame consists of a header, the payload, and a trailer. The 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 request message whose data is contained in a For example, here is a message contained in a single frame that
single frame that contains a payload of 94 octets spread over 3 contains a payload of 96 octets spread over 4 lines (each line is
lines (each line of the data is terminated with a CRLF pair): terminated with a CRLF pair):
C: REQ . 1 14 94 0 C: MSG 0 1 . 16 96
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start> C: </start>
C: END C: END
Note that the header is two lines long (the second line is blank Note that the message starts with a blank line, signifying a lack of
signifying a lack of explicit MIME typing information). explicit MIME typing information. Also note that in this example,
the message is represented as a single payload.
2.2.1 Frame Syntax 2.2.1 Frame Syntax
The ABNF for a message is: The ABNF for a frame is:
frame = header payload trailer / mapping frame = header payload trailer / mapping
header = req / rsp header = msg / rpy / err / ans / nul
req = "REQ" SP more SP serial SP seqno SP size SP channel msg = "MSG" SP common CR LF
CR LF [mime] CR LF
rsp = "RSP" SP more SP serial SP seqno SP size SP status rpy = "RPY" SP common CR LF
CR LF [mime] CR LF
more = "." / "*" ans = "ANS" SP common SP ansno CR LF
; use of 0 for <serial> is reserved for the initial greeting err = "ERR" SP common CR LF
serial = 0..2147483647
seqno = 0..4294967295 nul = "NUL" SP common CR LF
size = 0..2147483647 common = channel SP msgno SP more SP seqno SP size
; use of 0 for <channel> is reserved for BXXP channel management
channel = 0..2147483647 channel = 0..2147483647
; defaults are: msgno = 0..2147483647
;
; Content-Type: text/xml
; Content-Transfer-Encoding: binary
;
mime = <MIME Content {entity-headers} from RFC 2045>
status = "+" / "-" more = "." / "*"
seqno = 0..4294967295
size = 0..2147483647
ansno = 0..2147483647
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:
"REQ" or "RSP"), followed by a continuation indicator, a serial "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more
number, a sequence number, a payload size, and one additional parameters. A single space character (decimal code 32, " ")
parameter. A single space character (decimal code 32, " ") separates separates each component. The header is terminated with a CRLF pair.
each component. The header is terminated with a CRLF pair.
The "REQ" keyword indicates that this frame is part of a request The channel number ("channel") must be a non-negative integer (in
message. Following the "REQ" keyword, the continuation indicator, the range 0..2147483647).
the serial number, the sequence number, and the payload size is the
channel number for the request.
The "RSP" keyword indicates that this frame is part of a response The message number ("msgno") must be a non-negative integer (in the
message. Following the "RSP" keyword, the continuation indicator, range 0..2147483647) and have a different value than all other "MSG"
the serial number, the sequence number, and the payload size is the messages for which a reply has not been completely received.
status indicator for the response.
The continuation indicator (one of: decimal code 42, "*", or decimal The continuation indicator ("more", one of: decimal code 42, "*", or
code 46, ".") specifies whether this is the final frame of the decimal code 46, ".") specifies whether this is the final frame of
message: the message:
intermediate ("*"): at least one other frame follows for the intermediate ("*"): at least one other frame follows for the
message; or, message; or,
complete ("."): this frame completes the data for the message. complete ("."): this frame completes the message.
The serial number must be a non-negative integer (in the range The sequence number ("seqno") must be a non-negative integer (in the
0..2147483647) and have a different value than all other outstanding range 0..4294967295) and specifies the sequence number of the first
request messages (regardless of channel number). octet in the payload, for the associated channel.
The sequence number must be a non-negative integer (in the range The payload size ("size") must be a non-negative integer (in the
0..4294967295) and specifies the sequence number of the first octet range 0..2147483647) and specifies the exact number of octets in the
in the payload, for the associated channel. payload. (This does not include either the header or trailer.)
The payload size must be a non-negative integer (in the range Note that a frame may have an empty payload, e.g.,
0..2147483647) and specifies the exact number of octets in the
payload. (This does not include the trailer.)
The status indicator (one of: decimal code 43, "+", or decimal code S: RPY 0 1 * 287 27
45, "-"), specifies whether the request corresponding to this S:
response was performed: S: ...
S: ...
S: ...
S: END
S: RPY 0 1 . 314 0
S: END
positive ("+"): the request was performed and the response's data The answer number ("ansno") must be a non-negative integer (in the
contains the corresponding the results; or, range 0..4294967295) and must have a different value than all other
answers in progress for the message being replied to.
negative ("-"): the request could not be performed (either for When a message is segmented and sent as several frames, those frames
transient or permanent reasons) and the response's data contains must be sent sequentally, without any intervening frames from other
the corresponding error information. messages on the same channel. However, there are two exceptions:
first, no restriction is made with respect to the interleaving of
frames for other channels; and, second, in a one-to-many exchange,
multiple answers may be simultaneously in progress.
Accordingly, frames for "ANS" messages may be interleaved on the
same channel -- the answer number is used for collation, e.g.,
S: ANS 1 0 * 0 10 0
S:
S: ...
S: END
S: ANS 1 0 * 10 20 1
S:
S: ...
S: ...
S: END
S: ANS 1 0 . 30 10 0
S: ...
S: END
which shows two "ANS" messages interleaved on channel 1 as part of a
reply to message number 0. Note that the sequence number is advanced
for each frame sent on the channel, and is independent of the
messages sent in those frames.
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 "REQ" or "RSP"; o if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or
"NUL";
o if the header starts with "REQ" or "RSP", but any of the o if any of the parameters in the header cannot be determined or
continuation indicator, serial number, sequence number, or are invalid (i.e., syntactically incorrect);
payload size cannot be determined or is invalid;
o if the header starts with "REQ", but the channel number cannot be o if the value of the channel number doesn't refer to an existing
determined or is invalid; channel;
o if the header starts with "RSP", but the status indicator cannot o if the header starts with "MSG", and the message number refers to
be determined or is invalid; a "MSG" message that has been completely received but for which a
reply has not been completely sent;
o if the header starts with "RSP", but the serial number does not o if the header doesn't start with "MSG", and refers to a message
refer to an outstanding request message; number for which a reply has not been completely received;
o if the header doesn't start with "MSG", and refers to a message
number that has never been sent (except during session
establishment, c.f., Section 2.3.1.1);
o if the header starts with "MSG", "ERR", or "ANS", and refers to a
message number for which at least one other frame has been
received, and the three-character keyword starting this frame and
the immediately-previous received frame for this reply are not
identical;
o if the header starts with "NUL", and refers to a message number
for which at least one other frame has been received, and the
keyword of of the immediately-previous received frame for this
reply isn't "ANS";
o if the continuation indicator of the previous frame received on o if the continuation indicator of the previous frame received on
the same channel was intermediate ("*"), and if its serial number the same channel was intermediate ("*"), and its message number
isn't identical to this frame's serial 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 2.2.1.2); expected value for the associated channel (c.f., Section 2.2.1.2);
o if the header starts with "REQ" and refers to a message for which o if the header starts with "NUL", and the continuation indicator
at least one other "REQ" frame has been received, and if the is intermediate ("*") or the payload size is non-zero;
continuation indicator of the immediately-previous received frame
for this message is intermediate ("*"), and if the channel
numbers aren't identical;
o if the header starts with "RSP" and refers to a message for which
at least one other "RSP" frame has been received, and if the
status indicator of this frame and the immediately-previous
received frame for this message are not identical; or,
o if the header refers to a mesage for which no other frames has o if the header doesn't start with "NUL", and the continuation
been received, and if the "entity-headers" portion of the header indicator is complete ("."), and the total size of the
is present and poorly-formed; or, (re-assembled) message is less than two octets; or,
o if the header refers to a mesage for which at least one other o if the header doesn't start with "NUL", and the continuation
frame has been received, and if the "entity-headers" portion of indicator is complete ("."), and "entity-headers" are present but
the header is present. poorly-formed in the (re-assembled) message.
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.
The final frame in a message has a continuation indicator of
complete ("."), whilst all earlier frames (if any) have a
continuation indicator of intermediate ("*"). Note that any of these
frames may have an empty payload, e.g.,
S: RSP * 1 284 25 +
S:
S: ...
S: ...
S: ...
S: END
S: RSP . 1 309 0 +
S:
S: END
The data conveyed with a message is structured according to the
rules of MIME. Accordingly, the header of the first frame for a
message may include "entity-headers" (c.f., MIME[3]'s Section 3). If
none, or only some, of the entity-headers are present:
o the default "Content-Type" is "text/xml"; and,
o the default "Content-Transfer-Encoding" is "binary".
Hence, in the absence of typing information, a message's data is a
well-formed XML[2] document.
Note that the "entity-headers" (and the empty line that follows) are
part of the of the header, not the payload. Thus, they do not
contribute to the size of the payload.
Finally, note that the use of "entity-headers" is intended to convey
top-level tagging information about the payload. Accordingly, the
headers present should reflect this. Regardless, the size of the
"entity-headers" in a frame header is may not exceed 1024 octets.
2.2.1.2 Frame Payload 2.2.1.2 Frame Payload
The frame payload consists of zero or more octets.
Every payload octet sent in each direction on a channel has an 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
skipping to change at page 14, line 7 skipping to change at page 14, line 7
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 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.
2.2.2 Frame Semantics 2.2.2 Frame Semantics
The semantics of the payload of each frame is channel-specific. The semantics of each message is channel-specific. Accordingly, the
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 set of request and response messages may be carried in the o the messages that may be exchanged in the payload of the channel;
payload of the channel; and, and,
o the semantics of these messages. o the semantics of these messages.
A profile registration template (Section 5) organizes this A profile registration template (Section 5) organizes this
information. information.
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 requests are responded to, e.g., with an negative how poorly-formed "MSG" messages are replied to. For example, the
response containing an error message. However, if a poorly-formed channel management profile sends a negative reply containing an
response is received, then the channel must be closed (c.f., Section error message (c.f., Section 2.3.1.5).
2.3.1.3), unless this occurs on channel 0, in which case the session
is terminated without generating a response, and it is recommended
that a diagnostic entry be logged.
Note that if a profile uses XML to structure its messages, then only If a poorly-formed reply is received on channel zero, the session is
XML's baseline facilities (as described in the XML 1.0 terminated without generating a response, and it is recommended that
specification[2]) are allowed. Additional XML features (e.g., a diagnostic entry be logged.
namespaces) are made available only by being referenced and allowed
in a given profile's specification. 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.
2.2.2.2 XML-based Profiles
If a profile uses XML to structure its messages, then only XML's
baseline facilities (as described in the XML 1.0 specification[3])
are allowed. Additional XML features (e.g., namespaces) are made
available only by being explicitly discussed in a given profile's
specification.
In particular this limitation allows use of only the five predefined In particular this limitation allows use of only the five predefined
general entities references ("&amp;", "&lt;", "&gt;", "&apos;", and general entities references ("&amp;", "&lt;", "&gt;", "&apos;", and
"&quot;") and numeric entity references in the messages exchanged. "&quot;") and numeric entity references in the messages exchanged.
Finally, because the profile registration template defines the Further, because the profile registration template defines the
messages exchanged over a channel, the XML documents exchanged in messages exchanged over a channel, the XML documents exchanged in
each message needn't have either a "XML" declaration (e.g., <?xml each message needn't have either a "XML" declaration (e.g., <?xml
version="1.0" ?>) or a "DOCTYPE" declaration (e.g., <!DOCTYPE ...>). version="1.0" ?>) or a "DOCTYPE" declaration (e.g., <!DOCTYPE ...>).
Of course, all other XML 1.0 instructions (e.g., CDATA blocks, All other XML 1.0 instructions (e.g., CDATA blocks, processing
processing instructions, and so on) are allowed. instructions, and so on) are allowed.
Because the "XML" declaration isn't present, the default character Finally, because the "XML" declaration isn't present, the default
set for XML-based profiles is UTF-8. If another character set is character set for XML-based profiles is UTF-8. If another character
desired, a "Content-Type" entity-header should be used to specify set is desired, a "Content-Type" entity-header should be used to
the character set in question. specify the character set in question.
2.3 Channel Management 2.3 Channel Management
When a BXXP session starts, only channel number 0 is defined, which When a BXXP session starts, only channel number zero is defined,
is used for channel management. Section 6.1 contains the profile which is used for channel management. Section 6.1 contains the
registration for BXXP channel management. profile registration for BXXP channel management.
Channel management allows each BXXP peer to advertise the profiles Channel management allows each BXXP peer to advertise the profiles
that it supports (using the greeting message), bind an instance of that it supports (c.f., Section 2.3.1.1), bind an instance of one of
one of those profiles to a channel (using the start message), and those profiles to a channel (c.f., Section 2.3.1.2), and then later
then later close any channels (using the close message). close any channels or release the BXXP session (c.f., Section
2.3.1.3).
A BXXP 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 BXXP session is established, each BXXP peer signifies its When a BXXP session is established, each BXXP peer signifies its
availability by immediately sending a positive "RSP" message with a availability by immediately sending a positive reply with a message
serial 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: RSP . 0 0 84 + L: RPY 0 0 . 0 86
L: L:
L: <greeting> L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' /> L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RSP . 0 0 14 + I: RPY 0 0 . 0 16
I: I:
I: <greeting /> I: <greeting />
I: END I: END
Note that this example implies that the BXXP peer in the initiating Note that this example implies that the BXXP peer in the initiating
role waits until the BXXP peer in the listening role sends its role waits until the BXXP 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
BXXP peers send their response messages independently. BXXP 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 supported by the BXXP peer acting in a server role: profile supported by the BXXP 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 tokens, each indicating an optional feature of the feature tokens, each indicating an optional feature of the
channel management profile supported by the BXXP peer; channel management profile supported by the BXXP peer;
o the "localize" attribute, if present, contains one or more o the "localize" attribute, if present, contains one or more
language tokens, each identifying a desirable language tag to be language tokens (defined in [8]), each identifying a desirable
used by the remote BXXP peer when generating textual diagnostics language tag to be used by the remote BXXP peer when generating
for the "close" and "error" elements (the tokens are ordered from textual diagnostics for the "close" and "error" elements (the
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 within the "start" element, the content of each "profile" occur within the "start" element, the content of each "profile"
element may not contain an optional initialization element. element may not contain an optional initialization element.
At present, there are no optional features defined for the channel At present, there are no optional features defined for the channel
management profile. management profile.
Each token in the value of the "localize" attribute is defined
according to [8]. If not present, the default is "i-default".
2.3.1.2 The Start Message 2.3.1.2 The Start Message
When a BXXP peer wants to create a channel, it sends a "start" When a BXXP peer wants to create a channel, it sends a "start"
element as data on channel 0, e.g., element on channel zero, e.g.,
I: REQ . 1 14 94 0 I: MSG 0 1 . 16 96
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
I: </start> I: </start>
I: END I: 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
skipping to change at page 18, line 37 skipping to change at page 18, line 37
identifies a profile, and, optionally, contains an XML element identifies a profile, and, optionally, contains an XML element
exchanged during channel creation as its content. exchanged during channel creation as its content.
To avoid conflict in assigning channel numbers when requesting the To avoid conflict in assigning channel numbers when requesting the
creation of a channel, BXXP peers acting in the initiating role use creation of a channel, BXXP peers acting in the initiating role use
only positive integers that are odd-numbered; similarly, BXXP peers only positive integers that are odd-numbered; similarly, BXXP 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 BXXP peer is memorable. (If the attribute isn't received by a BXXP peer is meaningful for the duration of the BXXP
present or it's value is empty, then the sending BXXP peer is session. (If the attribute isn't present or it's value is empty,
requesting a configuration-specific default value.) The BXXP peer then the sending BXXP peer is requesting a configuration-specific
decides whether to operate as the indicated "serverName"; if not, an default value.) The BXXP peer decides whether to operate as the
"error" element is returned as data in a negative "RSP" message. indicated "serverName"; if not, an "error" element is sent in a
negative reply.
When a BXXP peer receives a "start" element as data on channel 0, it When a BXXP 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 returned as data in a positive "RSP" message; otherwise, element is sent in a positive reply; otherwise, an "error" element
an "error" element is returned as data in a negative "RSP" message. is 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:
I: REQ . 1 14 171 0 I: MSG 0 1 . 16 173
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
I: <profile I: <profile
I: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' /> I: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
I: </start> I: </start>
I: END I: END
L: RSP . 1 284 61 + L: RPY 0 1 . 287 63
L: L:
L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
L: END L: END
Similarly, an unsuccessful channel creation might look like this: Similarly, an unsuccessful channel creation might look like this:
I: REQ . 1 14 94 0 I: MSG 0 1 . 16 96
I: I:
I: <start number='2'> I: <start number='2'>
I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
I: </start> I: </start>
I: END I: END
L: RSP . 1 284 89 - L: ERR 0 1 . 287 91
L: L:
L: <error code='501'>number attribute L: <error code='501'>number attribute
L: in &lt;start&gt; element must be odd-valued</error> L: in &lt;start&gt; element must be odd-valued</error>
L: END L: 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: REQ . 1 14 120 0 C: MSG 0 1 . 16 122
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'> C: <profile uri='http://xml.resource.org/profiles/TLS'>
C: <ready /> C: <ready />
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RSP . 1 84 83 + S: RPY 0 1 . 86 85
S: S:
S: <profile uri='http://xml.resource.org/profiles/TLS'> S: <profile uri='http://xml.resource.org/profiles/TLS'>
S: <proceed /> S: <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 BXXP peer wants to close a channel, it sends a "close" When a BXXP peer wants to close a channel, it sends a "close"
element on channel 0, e.g., element on channel zero, e.g.,
I: REQ . 1 185 33 0 I: MSG 0 2 . 163 35
I: I:
I: <close number='1' code='200' /> I: <close number='1' code='200' />
I: END I: 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;
skipping to change at page 20, line 35 skipping to change at page 20, line 35
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 BXXP peer); and, sent by the remote BXXP 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 never programs. but 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
BXXP's first choice is used. BXXP peer's first choice is used.
When a BXXP peer receives a "close" element as data on channel 0, it If the value of the "number" attribute is zero, then the BXXP peer
wants to release the BXXP session (c.f., Section 2.4) -- otherwise
the value of the "number" attribute refers to an existing channel.
When a BXXP peer receives a "close" element on channel zero, it
decides whether it is willing to close the channel. If so, an "ok" decides whether it is willing to close the channel. If so, an "ok"
element is returned as data in a positive "RSP" message; otherwise, element is sent in a positive reply; otherwise, an "error" element
an "error" element is returned as data in a negative "RSP" message. is sent in a negative reply.
For example, a successful channel close might look like this: For example, a successful channel close might look like this:
I: REQ . 1 185 33 0 I: MSG 0 2 . 163 35
I: I:
I: <close number='1' code='200' /> I: <close number='1' code='200' />
I: END I: END
L: RSP . 1 345 8 + L: RPY 0 2 . 429 10
L: L:
L: <ok /> L: <ok />
L: END L: END
Similarly, an unsuccessful channel creation might look like this:
I: REQ . 1 185 33 0 Similarly, an unsuccessful channel close might look like this:
I: MSG 0 2 . 163 35
I: I:
I: <close number='1' code='200' /> I: <close number='1' code='200' />
I: END I: END
L: RSP . 1 345 41 - L: ERR 0 2 . 429 43
L: L:
L: <error code='550'>still working</error> L: <error code='550'>still working</error>
L: END L: END
2.3.1.4 The OK Message 2.3.1.4 The OK Message
When a BXXP peer agrees to close a channel, it returns an "ok" When a BXXP peer agrees to close a channel (or release the BXXP
element as data in a positive "RSP" message. 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 BXXP peer declines the creation of a channel, it returns an When a BXXP peer declines the creation of a channel, it sends an
"error" element as data in a negative "RSP" message, e.g., "error" element in a negative reply, e.g.,
I: REQ . 1 14 89 0 I: MSG 0 1 . 16 91
I: I:
I: <start number='2'> I: <start number='2'>
I: <profile uri='http://xml.resource.org/profiles/FOO' /> I: <profile uri='http://xml.resource.org/profiles/FOO' />
I: </start> I: </start>
I: END I: END
L: RSP . 1 284 67 - L: ERR 0 1 . 287 69
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 7); programs (c.f., Section 7);
skipping to change at page 22, line 39 skipping to change at page 22, line 46
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 BXXP peer); and, sent by the remote BXXP 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 never programs. but 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
BXXP's first choice is used. BXXP peer's first choice is used.
In addition, a BXXP peer returns an "error" element whenever: In addition, a BXXP peer sends an "error" element whenever:
o it receives a "REQ" message containing poorly-formed request; o it receives a "MSG" message containing a poorly-formed or
unexpected element;
o it receives a "REQ" message asking to close a channel and it o it receives a "MSG" message asking to close a channel (or release
declines to do so; or the BXXP session) and it declines to do so; or
o a BXXP session is established, the BXXP peer is acting in the o a BXXP session is established, the BXXP peer is acting in the
listening role, and that BXXP peer is unavailable (in this case, listening role, and that BXXP peer is unavailable (in this case,
the BXXP acting in the listening role does not send a "greeting" the BXXP acting in the listening role does not send a "greeting"
element). element).
In the final case, both BXXP peers terminate the session, and it is In the final case, both BXXP peers terminate the session, and it is
recommended that a diagnostic entry be logged by both BXXP peers. recommended that a diagnostic entry be logged by both BXXP peers.
2.4 Session Establishment and Release 2.4 Session Establishment and Release
When a BXXP session is established, each BXXP peer signifies its When a BXXP session is established, each BXXP peer signifies its
availability by immediately sending a positive "RSP" message with a availability by immediately sending a positive reply with a message
serial number of zero that contains a "greeting" element, e.g., number of zero on channel 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: RSP . 0 0 84 + L: RPY 0 0 . 0 86
L: L:
L: <greeting> L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' /> L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RSP . 0 0 14 + I: RPY 0 0 . 0 16
I: I:
I: <greeting /> I: <greeting />
I: END I: END
which, for the BXXP peer acting in the listening role, indicates
that it is available.
Alternatively, if the BXXP peer acting in the listening role is Alternatively, if the BXXP peer acting in the listening role is
unavailable, it returns a negative response, e.g., unavailable, it sends a negative reply, e.g.,
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RSP . 0 0 22 - L: ERR 0 0 . 0 24
L: L:
L: <error code='421' /> L: <error code='421' />
L: END L: END
I: RPY 0 0 . 0 16
I:
I: <greeting />
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 BXXP peer acting in the and the "greeting" element sent by the BXXP 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 BXXP peers. entry be logged by both BXXP peers.
When a BXXP peer wants to release the BXXP session, it sends a "REQ" Note that both of these examples imply that the BXXP peer in the
message on channel 0 with no data. The other BXXP peer may accept initiating role waits until the BXXP peer in the listening role
the request (by sending a positive "RSP" message), e.g., sends its greeting -- this is an artifact of the presentation; in
fact, both BXXP peers send their replies independently.
C: REQ . 1 14 0 0 When a BXXP peer wants to release the BXXP session, it sends a
"close" element with a zero-valued "number" attribute on channel
zero. The other BXXP peer indicates its willingness by sending an
"ok" element in a positive reply, e.g.,
C: MSG 0 1 . 16 24
C: C:
C: <close code='200' />
C: END C: END
S: RSP . 1 284 0 + S: RPY 0 1 . 287 10
S: S:
S: <ok />
S: END S: END
C: <close connection> I: <close connection>
S: <close connection> L: <close connection>
L: <wait for next connection> L: <wait for next connection>
If the other BXXP peer sends a negative "RSP" message, then the BXXP Alternatively, if the other BXXP doesn't want to release the BXXP
session should not be terminated, if possible. session, the exchange might look like this:
2.5 Transport Mappings C: MSG 0 1 . 16 24
C:
C: <close code='200' />
C: END
S: ERR 0 1 . 287 43
S:
S: <error code='550'>still working</error>
L: END
The BXXP framework isn't tied to a particular transport protocol. If session release is declined, the BXXP session should not be
terminated, if possible.
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 satisified by any document
describing how a particular transport service realizes a BXXP describing how a particular transport service realizes a BXXP
session. session.
2.5.1 Session Management 2.5.1 Session Management
A BXXP session is connection-oriented. A mapping document must A BXXP session is connection-oriented. A mapping document must
skipping to change at page 26, line 30 skipping to change at page 26, line 28
o how a BXXP session is established; o how a BXXP session is established;
o how a BXXP peer is identified as acting in the listening role; o how a BXXP peer is identified as acting in the listening role;
o how a BXXP peer is identified as acting in the initiating role; o how a BXXP peer is identified as acting in the initiating role;
o how a BXXP session is released; and, o how a BXXP session is released; and,
o how a BXXP session is terminated. o how a BXXP session is terminated.
2.5.2 Data Exchange 2.5.2 Message Exchange
A BXXP session is message-oriented. A mapping document must define: A BXXP 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 they were sent; and, as 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 Parallelism 2.6 Parallelism
2.6.1 Within a single channel 2.6.1 Within a Single Channel
A BXXP peer acting in the client role may send multiple "REQ" A BXXP peer acting in the client role may send multiple "MSG"
messages for the same channel without waiting to receive the messages on the same channel without waiting to receive the
corresponding "RSP" messages. A BXXP peer acting in the server role corresponding replies.
must process all "REQ" messages for a given channel in the same
order as they are received. As a consequence, that BXXP peer must
generate the corresponding "RSP" messages in the same order as the
"REQ" messages are received.
2.6.2 Between different channels A BXXP peer acting in the server role must process all "MSG"
messages for a given channel in the same order as they are received.
As a consequence, the BXXP peer must generate replies in the same
order as the corresponding "MSG" messages are received on a given
channel.
A BXXP peer acting in the client role may send multiple "REQ" 2.6.2 Between Different Channels
messages for different channels without waiting to receive the
corresponding "RSP" messages. A BXXP peer acting in the server role
may process "REQ" messages received for different channels in
parallel. As a consequence, although the "RSP" messages for a given
channel are generating according to the order in which the
corresponding "REQ" messages are received, there is no ordering
constraint between "RSP" messages for different channels.
2.6.3 Pre-emptive responses A BXXP peer acting in the client role may send multiple "MSG"
messages on different channels without waiting to receive the
corresponding replies.
A BXXP peer acting in the server role may send a negative response A BXXP peer acting in the server role may process "MSG" messages
to a request before it receives the final "REQ" frame of a request. received on different channels in any order it chooses. As a
If it does so, that BXXP peer is obliged to ignore any subsequent consequence, although the replies for a given channel appear to be
"REQ" frames for that request, up to and including the final "REQ" generated in the same order in which the corresponding "MSG"
frame. messages are received, there is no ordering constraint for replies
on different channels.
If a BXXP peer acting in the client role receives a negative "RSP" 2.6.3 Pre-emptive Replies
frame before it sends the final "REQ" frame for a request, then it
is required to send a "REQ" frame with a continuation status of A BXXP peer acting in the server role may send a negative reply
before it receives the final "MSG" frame of a message. If it does
so, that BXXP peer is obliged to ignore any subsequent "MSG" frames
for that message, up to and including the final "MSG" frame.
If a BXXP peer acting in the client role receives a negative reply
before it sends the final "MSG" frame for a message, then it is
required to send a "MSG" frame with a continuation status of
complete (".") and having a zero-length payload. complete (".") and having a zero-length payload.
2.6.4 Interference 2.6.4 Interference
If the processing of a particular frame has sequencing impacts on If the processing of a particular message has sequencing impacts on
other frames (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
BXXP is peer-to-peer -- as such both peers must be prepared to BXXP is peer-to-peer -- as such both peers must be prepared to
receive both "REQ" and "RSP" frames. Accordingly, an initiating BXXP receive all messages defined in this memo. Accordingly, an
peer capable of acting only in the client role must behave initiating BXXP peer capable of acting only in the client role must
gracefully if it receives a "REQ" message. Accordingly, all profiles behave gracefully if it receives a "MSG" message. Accordingly, all
must provide an appropriate error message for responding to unwanted profiles must provide an appropriate error message for replying to
requests. unexpected "MSG" messages.
As a consequence of the peer-to-peer nature of BXXP, serial numbers As a consequence of the peer-to-peer nature of BXXP, message numbers
are unidirectionally-significant. That is, the serial numbers in are unidirectionally-significant. That is, the message numbers in
"REQ" messages sent by a BXXP peer acting in the initiating role are "MSG" messages sent by a BXXP peer acting in the initiating role are
unrelated to the serial numbers in "REQ" messages sent by a BXXP unrelated to the message numbers in "MSG" messages sent by a BXXP
peer acting in the listening role. peer acting in the listening role.
For example, these two frames For example, these two messages
I: REQ . 1 14 94 0 I: MSG 0 1 . 16 96
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
I: </start> I: </start>
I: END I: END
L: REQ . 1 284 89 0 L: MSG 0 1 . 287 92
L: L:
L: <start number='2'> L: <start number='2'>
L: <profile uri='http://xml.resource.org/profiles/SEP' /> L: <profile uri='http://xml.resource.org/profiles/IMXP' />
L: </start> L: </start>
L: END L: END
have no fundamental relationship to each other. refer to different messages sent on channel zero.
3. Transport Security 3. Transport Security
When a BXXP session is established, plaintext transfer, without When a BXXP session is established, plaintext transfer, without
privacy, is provided. Accordingly, transport security in BXXP is privacy, is provided. Accordingly, transport security in BXXP 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[4]. o the TLS transport security profile, based on TLS version one[4].
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 tranpsort Note that because of their intimate relationship with the tranpsort
service, a given transport security profile tends to be relevant to service, a given transport security profile tends to be relevant to
a single transort mapping (c.f., Section 2.5). a single transort 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 0), underlying negotiation process, all channels (including channel
are closed on the BXXP session. Upon completion of the negotiation zero) are closed on the BXXP session. Accordingly, upon completion
process, regardless of its outcome, a new greeting is issued by both of the negotiation process, regardless of its outcome, a new
BXXP peers. greeting is issued by both BXXP peers.
A BXXP peer may choose to issue different greetings based on whether A BXXP 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: RSP . 0 0 84 + L: RPY 0 0 . 0 86
L: L:
L: <greeting> L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' /> L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RSP . 0 0 14 + I: RPY 0 0 . 0 16
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I: REQ . 1 14 120 0 I: MSG 0 1 . 16 122
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/TLS'> I: <profile uri='http://xml.resource.org/profiles/TLS'>
I: <ready /> I: <ready />
I: </profile> I: </profile>
I: </start> I: </start>
I: END I: END
L: RSP . 1 84 83 + L: RPY 0 1 . 86 85
L: L:
L: <profile uri='http://xml.resource.org/profiles/TLS'> L: <profile uri='http://xml.resource.org/profiles/TLS'>
L: <proceed /> L: <proceed />
L: </profile> L: </profile>
L: END L: END
... successful transport security negotiation ... ... successful transport security negotiation ...
L: RSP . 0 0 224 + L: RPY 0 0 . 0 227
L: L:
L: <greeting> L: <greeting>
L: <profile L: <profile
L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' /> L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
L: <profile uri='http://xml.resource.org/profiles/SEP' /> L: <profile uri='http://xml.resource.org/profiles/IMXP' />
L: </greeting> L: </greeting>
L: END L: END
I: RSP . 0 0 14 + I: RPY 0 0 . 0 16
I: I:
I: <greeting /> I: <greeting />
I: END I: END
Of course, not all BXXP peers need be as single-minded: Of course, not all BXXP peers need be as single-minded:
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RSP . 0 0 284 + L: RPY 0 0 . 0 287
L: L:
L: <greeting> L: <greeting>
L: <profile L: <profile
L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' /> L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
L: <profile uri='http://xml.resource.org/profiles/SEP' /> L: <profile uri='http://xml.resource.org/profiles/IMXP' />
L: <profile uri='http://xml.resource.org/profiles/TLS' /> L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RSP . 0 0 14 + I: RPY 0 0 . 0 16
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I: REQ . 1 14 120 0 I: MSG 0 1 . 16 122
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/TLS'> I: <profile uri='http://xml.resource.org/profiles/TLS'>
I: <ready /> I: <ready />
I: </profile> I: </profile>
I: </start> I: </start>
I: END I: END
L: RSP . 1 284 83 + L: RPY 0 1 . 287 85
L: L:
L: <profile uri='http://xml.resource.org/profiles/TLS'> L: <profile uri='http://xml.resource.org/profiles/TLS'>
L: <proceed /> L: <proceed />
L: </profile> L: </profile>
L: END L: END
... failed transport security negotiation ... ... failed transport security negotiation ...
L: RSP . 0 0 284 + L: RPY 0 0 . 0 287
L: L:
L: <greeting> L: <greeting>
L: <profile L: <profile
L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' /> L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
L: <profile uri='http://xml.resource.org/profiles/SEP' /> L: <profile uri='http://xml.resource.org/profiles/IMXP' />
L: <profile uri='http://xml.resource.org/profiles/TLS' /> L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RSP . 0 0 14 + I: RPY 0 0 . 0 16
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.3 contains the registration for this profile. Section 6.3 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://xml.resource.org/profiles/TLS
in the BXXP "profile" element during channel creation. in the BXXP "profile" element during channel creation.
During channel creation, the corresponding "profile" element in the During channel creation, the corresponding "profile" element in the
BXXP "start" element may contain a "ready" element. If channel BXXP "start" element may contain a "ready" element. If channel
creation is successful, then before sending the corresponding "RSP" creation is successful, then before sending the corresponding reply,
message, the BXXP peer processes the "ready" element and includes the BXXP peer processes the "ready" element and includes the
the resulting response in the "RSP" message, e.g., resulting response in the reply, e.g.,
C: REQ . 1 14 120 0 C: MSG 0 1 . 16 122
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'> C: <profile uri='http://xml.resource.org/profiles/TLS'>
C: <ready /> C: <ready />
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RSP . 1 84 83 + S: RPY 0 1 . 86 85
S: S:
S: <profile uri='http://xml.resource.org/profiles/TLS'> S: <profile uri='http://xml.resource.org/profiles/TLS'>
S: <proceed /> S: <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: REQ . 1 14 135 0 C: MSG 0 1 . 16 137
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'> C: <profile uri='http://xml.resource.org/profiles/TLS'>
C: <ready version="oops" /> C: <ready version="oops" />
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RSP . 1 84 156 + S: RPY 0 1 . 86 158
S: S:
S: <profile uri='http://xml.resource.org/profiles/TLS'> S: <profile uri='http://xml.resource.org/profiles/TLS'>
S: <error code='501'>version attribute S: <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 "RSP" message is returned (as channel In this case, a positive reply is sent (as channel creation
creation succeeded), but the encapsulated response contains an succeeded), but the encapsulated response contains an indication as
indication as to why the operation failed. to why the operation failed.
3.1.2 Request and Response Messages 3.1.2 Message Syntax
Section 6.4 defines the messages that are used in the TLS transport Section 6.4 defines the messages that are used in the TLS transport
security profile: security profile.
o "REQ" messages carry only the "ready" element as data;
o positive "RSP" messages carry only the "proceed" element as data;
and,
o negative "RSP" messages carry only the "error" element as data.
3.1.3 Message Semantics 3.1.3 Message Semantics
3.1.3.1 The Ready Message 3.1.3.1 The Ready Message
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 BXXP peer sends the "ready" element, it no longer sends any When a BXXP peer sends the "ready" element, it must not send any
traffic on any channel until a corresponding "RSP" message is further traffic on any channel until a corresponding reply is
received; similarly, before processing a "ready" element, the received; similarly, before processing a "ready" element, the
receiving BXXP peer waits until any pending "RSP" messages have been receiving BXXP peer waits until any pending replies have been
generated and sent. generated and sent.
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
in response to the "ready" element. When a BXXP peer receives the as a reply to the "ready" element. When a BXXP peer receives the
"ready" element, it begins the underlying negotiation process for "ready" element, it begins the underlying negotiation process for
transport security. transport security.
4. User Authentication 4. User Authentication
When a BXXP session is established, anonymous access, without trace When a BXXP session is established, anonymous access, without trace
information, is provided. Accordingly, user authentication in BXXP information, is provided. Accordingly, user authentication in BXXP
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:
skipping to change at page 35, line 27 skipping to change at page 35, line 27
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 BXXP session; further, no additional attempts at channels on the BXXP 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 BXXP peer. As such, authorization is an internal matter for each BXXP 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 are 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.5 contains the registration for this profile. Section 6.5 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
BXXP session, then a SASL security layer may not be negotiated; BXXP 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 may not be started or otherwise used. security profile must not begin its underlying negotiation process.
Section 4 of the SASL specification[5] requires the following Section 4 of the SASL specification[5] requires the following
information be supplied by a protocol definition: information be supplied by a protocol definition:
service name: "bxxp" will be registered with the IANA as a GSSAPI service name: "bxxp"
service name when this draft is published as an RFC.
initiation sequence: Creating a channel using a BXXP profile initiation sequence: Creating a channel using a BXXP 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 the client is carried within a "blob" element during channel by the client is carried within a "blob" element during channel
creation. creation.
exchange sequence: "Challenges" and "responses" are carried in the exchange sequence: "Challenges" and "responses" are carried in
"blob" element during data exchange. The "status" attribute of exchanges of the "blob" element. The "status" attribute of the
the "blob" element is used both by a server indicating a "blob" element is used both by a server indicating a successful
successful completion of the exchange, and a client aborting the completion of the exchange, and a client aborting the exchange,
exchange, The server indicates failure of the exchange by sending The server indicates failure of the exchange by sending an
an "error" element. "error" element.
security layer negotiation: Prior to beginning the negotiation of a security layer negotiation: When a security layer starts
security layer, any pending "RSP" messages are generated and negotiation, all channels (including channel zero) are closed on
sent; further, once negotiation begins, no traffic is sent on any the BXXP session. Accordingly, upon completion of the negotiation
other channels until the negotiation completes. process, regardless of its outcome, a new greeting is issued by
both BXXP 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. When a security layer takes effect, successful completion reply.
all channels (including channel 0), are closed on the BXXP
session, and a new greeting is issued by both BXXP peers.
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 BXXP session. channels for the duration of the BXXP 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://xml.resource.org/profiles/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 BXXP peer may provide multiple Note that during channel creation, a BXXP peer may provide multiple
profiles to the remote peer, e.g., profiles to the remote peer, e.g.,
C: REQ . 1 14 171 0 C: MSG 0 1 . 16 173
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile C: <profile
C: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' /> C: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start> C: </start>
C: END C: END
S: RSP . 1 284 61 + S: RPY 0 1 . 287 63
S: S:
S: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> S: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
S: END S: END
During channel creation, the corresponding "profile" element in the During channel creation, the corresponding "profile" element in the
BXXP "start" element may provide data in a "blob" element. Note that BXXP "start" element may contain a "blob" element. Note that it is
it is possible for the channel to be created, but for the possible for the channel to be created, but for the encapsulated
encapsulated operation to fail, e.g., operation to fail, e.g.,
C: REQ . 1 14 145 0 C: MSG 0 1 . 16 147
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'>
C: <blob>AGJsb2NrbWFzdGVy</blob> C: <blob>AGJsb2NrbWFzdGVy</blob>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RSP . 1 284 140 + S: RPY 0 1 . 287 142
S: S:
S: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> S: <profile uri='http://xml.resource.org/profiles/sasl/OTP'>
S: <error code='534'>authentication mechanism is S: <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 "RSP" message is returned (as channel In this case, a positive reply is sent (as channel creation
creation succeeded), but the encapsulated response contains an succeeded), but the encapsulated response contains an indication as
indication as to why the operation failed. to why the operation failed.
Otherwise, the server returns a challenge (or signifies success), Otherwise, the server sends a challenge (or signifies success), e.g.,
e.g.,
C: REQ . 1 14 145 0 C: MSG 0 1 . 16 147
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'>
C: <blob>AGJsb2NrbWFzdGVy</blob> C: <blob>AGJsb2NrbWFzdGVy</blob>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RSP . 1 284 144 + S: RPY 0 1 . 287 146
S: S:
S: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> S: <profile uri='http://xml.resource.org/profiles/sasl/OTP'>
S: <blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=</blob> S: <blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=</blob>
S: </profile> S: </profile>
S: END S: END
If a challenge is received, then the client responds and awaits a If a challenge is received, then the client responds and awaits
reply, e.g., another reply, e.g.,
C: REQ . 2 0 67 1 C: MSG 1 0 . 0 69
C: C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob> C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END C: END
S: RSP . 2 0 13 + S: RPY 1 0 . 0 15
S: S:
S: <blob status='complete' /> S: <blob status='complete' />
S: END S: END
Of course, the client could abort the authentication process by Of course, the client could abort the authentication process by
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: REQ . 2 0 67 1 C: MSG 1 0 . 0 69
C: C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob> C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END C: END
S: RSP . 2 0 22 - S: ERR 1 1 . 0 24
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: REQ . 1 14 107 0 C: MSG 0 1 . 16 109
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile C: <profile
C: uri='http://xml.resource.org/profiles/sasl/CRAM-MD5' /> C: uri='http://xml.resource.org/profiles/sasl/CRAM-MD5' />
C: </start> C: </start>
C: END C: END
S: RSP . 1 284 148 + S: RPY 0 1 . 287 150
S: S:
S: <profile uri='http://xml.resource.org/profiles/sasl/CRAM-MD5'> S: <profile uri='http://xml.resource.org/profiles/sasl/CRAM-MD5'>
S: <blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ S: <blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
</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.
4.1.2 Request and Response Messages 4.1.2 Message Syntax
Section 6.6 defines the messages that are used for each profile in Section 6.6 defines the messages that are used for each profile in
the SASL family: the SASL family.
o "REQ" messages carry only the "blob" element as data;
o positive "RSP" messages carry only the "blob" element as data;
and,
o negative "RSP" messages carry only the "error" element as data.
Because many SASL mechanisms exchange binary data, the content of Note that because many SASL mechanisms exchange binary data, the
the "blob" element is always a base64-encoded string. content of the "blob" element is always a base64-encoded string.
4.1.3 Message Semantics 4.1.3 Message Semantics
The "blob" element has an optional "status" attribute, and arbitrary The "blob" element has an optional "status" attribute, and arbitrary
octets as its content: octets as its content:
o the "status" attribute, if present, takes one of three values: o the "status" attribute, if present, takes one of three values:
abort: used by a client to indicate that it is aborting the abort: used by a client to indicate that it is aborting the
authentication process; authentication process;
skipping to change at page 41, line 18 skipping to change at page 41, line 18
Profile Identification: specify a URI[9] that authoritatively Profile Identification: specify a URI[9] that authoritatively
identifies this profile. identifies this profile.
Elements Exchanged during Channel Creation: specify the elements Elements Exchanged during Channel Creation: specify the elements
that may be exchanged during channel creation (If the profile that may be exchanged during channel creation (If the profile
doesn't exchange XML elements, then initialization information doesn't exchange XML elements, then initialization information
may not be exchanged during channel creation). Regardless, the may not be exchanged during channel creation). Regardless, the
size of any initialization element may not exceed 4K octets. size of any initialization element may not exceed 4K octets.
Messages in "REQ" frames: specify the datatypes that may be present Messages starting one-to-one exchanges: specify the datatypes that
in a request. may be present when an exchange starts.
Messages in positive "RSP" frames: specify the datatypes that may be Messages in positive replies: specify the datatypes that may be
present in a positive response. present in a positive reply.
Messages in negative "RSP" frames: specify the datatypes that may be Messages in negative replies: specify the datatypes that may be
present in negative response. present in a negative reply.
Messages in one-to-many exchanges: specify the datatypes that may be
present in a one-to-many exchange.
Message Syntax: specify the syntax of the datatypes exchanged by the Message Syntax: specify the syntax of the datatypes exchanged by the
profile. profile.
Message Semantics: specify the semantics of the datatypes exchanged Message Semantics: specify the semantics of the datatypes exchanged
by the profile. by the profile.
Note that "datatype" refers to any MIME media type, whilst "element" Note that "datatype" refers to any MIME media type, whilst "element"
refers to any well-formed XML document. refers to any well-formed XML document.
6. Initial Profile Registrations 6. Initial Profile Registrations
6.1 BXXP Channel Management 6.1 BXXP Channel Management
Profile Identification: not applicable Profile Identification: not applicable
Elements Exchanged during Channel Creation: not applicable Elements Exchanged during Channel Creation: not applicable
Messages in "REQ" frames: "start" or "close" Messages starting one-to-one exchanges: "start" or "close"
Messages in positive "RSP" frames: "greeting", "profile", or "ok" Messages in positive replies: "greeting", "profile", or "ok"
Messages in negative "RSP" frames: "error" Messages in negative replies: "error"
Messages in one-to-many exchanges: none
Message Syntax: c.f., Section 6.2 Message Syntax: c.f., Section 6.2
Message Semantics: c.f., Section 2.3.1 Message Semantics: c.f., Section 2.3.1
6.2 BXXP Channel Management DTD 6.2 BXXP Channel Management DTD
<!-- <!--
DTD for BXXP Channel Management, as of 2000-08-06 DTD for BXXP Channel Management, as of 2000-09-04
Copyright 1999, 2000 Invisible Worlds, Inc.
This document is a DTD and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Refer to this DTD as: Refer to this DTD as:
<!ENTITY % BXXP PUBLIC "-//Blocks//DTD BXXP//EN" <!ENTITY % BXXP PUBLIC "-//Blocks//DTD BXXP//EN"
"http://xml.resource.org/profiles/BXXP/bxxp.dtd"> "http://xml.resource.org/profiles/BXXP/bxxp.dtd">
%BXXP; %BXXP;
--> -->
<!-- <!--
DTD data types: DTD data types:
skipping to change at page 44, line 7 skipping to change at page 44, line 4
a 3-digit reply code a 3-digit reply code
XYZ [1-5][1-9][1-9] 500 XYZ [1-5][1-9][1-9] 500
--> -->
<!ENTITY % CHAN "CDATA"> <!ENTITY % CHAN "CDATA">
<!ENTITY % URI "CDATA"> <!ENTITY % URI "CDATA">
<!ENTITY % FTRS "NMTOKENS"> <!ENTITY % FTRS "NMTOKENS">
<!ENTITY % LOCS "NMTOKEN"> <!ENTITY % LOCS "NMTOKEN">
<!ENTITY % LANG "NMTOKEN"> <!ENTITY % LANG "NMTOKEN">
<!ENTITY % XYZ "CDATA"> <!ENTITY % XYZ "CDATA">
<!-- <!--
BXXP messages BXXP messages
role REQ RSP role MSG RSP ERR
======= === === ======= === === ===
I and L +: greeting I and L greeting error
-: error
I or L start +: profile I or L start profile error
-: error
I or L close +: ok I or L close ok error
-: error
--> -->
<!ELEMENT greeting (profile)*> <!ELEMENT greeting (profile)*>
<!ATTLIST greeting <!ATTLIST greeting
features %FTRS; #IMPLIED features %FTRS; #IMPLIED
localize %LOCS; "i-default"> localize %LOCS; "i-default">
<!ELEMENT start (profile)+> <!ELEMENT start (profile)+>
<!ATTLIST start <!ATTLIST start
number %CHAN; #REQUIRED number %CHAN; #REQUIRED
serverName CDATA #IMPLIED> serverName CDATA #IMPLIED>
<!-- profile element is empty if contained in a greeting --> <!-- profile element is empty if contained in a greeting -->
<!ELEMENT profile ANY> <!ELEMENT profile ANY>
<!ATTLIST profile <!ATTLIST profile
uri %URI; #REQUIRED> uri %URI; #REQUIRED>
<!ELEMENT close (#PCDATA)*> <!ELEMENT close (#PCDATA)*>
<!ATTLIST close <!ATTLIST close
number %CHAN; #REQUIRED number %CHAN; "0"
code %XYZ; #REQUIRED code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED> xml:lang %LANG; #IMPLIED>
<!ELEMENT ok EMPTY> <!ELEMENT ok EMPTY>
<!ELEMENT error (#PCDATA)*> <!ELEMENT error (#PCDATA)*>
<!ATTLIST error <!ATTLIST error
code %XYZ; #REQUIRED code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED> xml:lang %LANG; #IMPLIED>
6.3 Registration: TLS Transport Security Profile 6.3 Registration: TLS Transport Security Profile
Profile Identification: http://xml.resource.org/profiles/TLS Profile Identification: http://xml.resource.org/profiles/TLS
Elements Exchanged during Channel Creation: "ready" Elements Exchanged during Channel Creation: "ready"
Messages in "REQ" frames: "ready" Messages starting one-to-one exchanges: "ready"
Messages in positive "RSP" frames: "proceed" Messages in positive replies: "proceed"
Messages in negative "RSP" frames: "error" Messages in negative replies: "error"
Messages in one-to-many exchanges: none
Message Syntax: c.f., Section 6.4 Message Syntax: c.f., Section 6.4
Message Semantics: c.f., Section 3.1.3 Message Semantics: c.f., Section 3.1.3
6.4 TLS Transport Security Profile DTD 6.4 TLS Transport Security Profile DTD
<!-- <!--
DTD for the TLS Transport Security Profile, as of 2000-03-03 DTD for the TLS Transport Security Profile, as of 2000-09-04
Copyright 1999, 2000 Invisible Worlds, Inc.
This document is a DTD and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Refer to this DTD as: Refer to this DTD as:
<!ENTITY % TLS PUBLIC "-//Blocks//DTD TLS//EN" <!ENTITY % TLS PUBLIC "-//Blocks//DTD TLS//EN"
"http://xml.resource.org/profiles/TLS/tls.dtd"> "http://xml.resource.org/profiles/TLS/tls.dtd">
%TLS; %TLS;
--> -->
<!-- <!--
TLS messages TLS messages
role REQ RSP role MSG RSP ERR
====== === === ====== === === ===
I or L ready +: proceed I or L ready proceed error
-: error
--> -->
<!ELEMENT ready EMPTY> <!ELEMENT ready EMPTY>
<!ATTLIST ready <!ATTLIST ready
version CDATA "1"> version CDATA "1">
<!ELEMENT proceed EMPTY> <!ELEMENT proceed EMPTY>
6.5 Registration: SASL Family of Profiles 6.5 Registration: SASL Family of Profiles
Profile Identification: Profile Identification:
http://xml.resource.org/profiles/sasl/MECHANISM, where http://xml.resource.org/profiles/sasl/MECHANISM, where
"MECHANISM" is a token registered with the IANA[14] "MECHANISM" is a token registered with the IANA[14]
Elements Exchanged during Channel Creation: "blob" Elements Exchanged during Channel Creation: "blob"
Messages in "REQ" frames: "blob" Messages starting one-to-one exchanges: "blob"
Messages in positive "RSP" frames: "blob" Messages in positive replies: "blob"
Messages in negative "RSP" frames: "error" Messages in negative replies: "error"
Messages in one-to-many exchanges: none
Message Syntax: c.f., Section 6.6 Message Syntax: c.f., Section 6.6
Message Semantics: c.f., Section 4.1.3 Message Semantics: c.f., Section 4.1.3
6.6 SASL Family of Profiles DTD 6.6 SASL Family of Profiles DTD
<!-- <!--
DTD for the SASL Family of Profiles, as of 2000-04-04 DTD for the SASL Family of Profiles, as of 2000-09-04
Copyright 1999, 2000 Invisible Worlds, Inc.
This document is a DTD and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Refer to this DTD as: Refer to this DTD as:
<!ENTITY % SASL PUBLIC "-//Blocks//DTD SASL//EN" <!ENTITY % SASL PUBLIC "-//Blocks//DTD SASL//EN"
"http://xml.resource.org/profiles/sasl/sasl.dtd"> "http://xml.resource.org/profiles/sasl/sasl.dtd">
%SASL; %SASL;
--> -->
<!-- <!--
SASL messages SASL messages
role REQ RSP role MSG RSP ERR
====== === === ====== === === ===
I or L blob +: blob I or L blob blob error
-: 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">
7. Reply Codes 7. Reply Codes
skipping to change at page 51, line 18 skipping to change at page 50, line 18
attack; however, judicious use of initial tuning profiles provides attack; however, judicious use of initial tuning profiles provides
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
[5]'s Section 9 for a discussion of security considerations. [5]'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 BXXP greeting or generate an error response to the from the BXXP 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
BXXP peer may be configurable to refuse to proceed without BXXP peer may be configurable to refuse to proceed without
an acceptable level of privacy. an 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 BXXP peer should be weakest cipher suite available. A BXXP 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 interactions 3. A man-in-the-middle may modify any protocol exchanges prior
prior to a successful negotiation. Upon completing the to a successful negotiation. Upon completing the
negotiation, a BXXP peer must discard previously cached negotiation, a BXXP peer must discard previously cached
information about the BXXP session. information about the BXXP session.
As different TLS ciphersuites provide varying levels of As different TLS ciphersuites provide varying levels of
security, administrators should carefully choose which security, administrators should carefully choose which
ciphersuites are provisioned. ciphersuites are provisioned.
9. IANA Considerations 9. IANA Considerations
The IANA registers "bxxp" as a GSSAPI[12] service name. The IANA registers "bxxp" as a GSSAPI[12] service name, as specified
in Section 4.1.
The IANA maintains a list of:
o BXXP reply codes, c.f., Section 7; and,
o BXXP profiles that are defined in the RFC series. The IANA maintains a list of BXXP profiles that are defined in any
standards-track documents.
The IANA makes the registrations specified in Section 6.3 and The IANA makes the registrations specified in Section 6.3 and
Section 6.5. It is recommended that the IANA register these profiles Section 6.5. It is recommended that the IANA register these profiles
using the IANA as a URI-prefix. using the IANA as a URI-prefix, and populate those URIs with the
respective profile registrations.
References References
[1] Rose, M.T., "On the Design of Application Protocols", [1] Rose, M.T., "On the Design of Application Protocols",
draft-mrose-beep-design-00 (work in progress), July 2000. draft-mrose-beep-design-00 (work in progress), July 2000.
[2] World Wide Web Consortium, "Extensible Markup Language (XML) [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1.0", W3C XML, February 1998,
<URL:http://www.w3.org/TR/1998/REC-xml-19980210>.
[3] 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", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[3] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998,
<URL:http://www.w3.org/TR/1998/REC-xml-19980210>.
[4] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A. [4] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A.
O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246, O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999. January 1999.
[5] Myers, J.G., "Simple Authentication and Security Layer [5] Myers, J.G., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997. (SASL)", RFC 2222, October 1997.
[6] Rose, M.T., "Mapping the BXXP Framework onto TCP", [6] Rose, M.T., "Mapping the BXXP Framework onto TCP",
draft-ietf-beep-tcpmapping-00 (work in progress), August 2000. draft-ietf-beep-tcpmapping-01 (work in progress), September
2000.
[7] Postel, J., "Transmission Control Protocol", RFC 793, STD 7, [7] Postel, J., "Transmission Control Protocol", RFC 793, STD 7,
Sep 1981. Sep 1981.
[8] Alvestrand, H., "Tags for the Identification of Languages", [8] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995. RFC 1766, March 1995.
[9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform [9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998. 1998.
skipping to change at page 55, line 5 skipping to change at page 54, line 5
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. Changes from draft-mrose-bxxp-framework-01 Appendix A. Changes from draft-ietf-beep-framework-00
o The names of messages are renamed:
* "REQ" messages are now "MSG" messages; and,
* "RSP" messages are now "RPY" (positive), "ANS"/"NULL"
(one-to-many), and "ERR" (negative).
o One-to-many exchanges are supported using the "ANS" message.
o Commonly-used paraemters are re-ordered in the header:
* channel numbers appear in each frame (and are 31-bits wide);
and,
* serial numbers are now message numbers, and are per-channel.
o MIME "entity-headers" are now part of the payload (and there is
no longer any header-related processing associated with them).
o An IANA registration for BXXP error codes is no longer required
(the error codes are used only within this specification).
o The close message (Section 2.3.1.3) is also used to release the
BXXP session.
Appendix B. Changes from draft-mrose-bxxp-framework-01
o Channel numbers are now 31-bits wide (instead of 8-bits). o Channel numbers are now 31-bits wide (instead of 8-bits).
o Peers should support at least 257 concurrently opened channels. o Peers should support at least 257 concurrent channels.
o The consistency rules in Section 2.2.1.1 now mandate that any o The consistency rules in Section 2.2.1.1 now mandate that any
MIME entity-headers occur only in the first frame of a message. MIME entity-headers occur only in the first frame of a message.
o Discussion of the role of the entity-headers is moved to Section o Discussion of the role of the entity-headers is moved to Section
2.2.1.1. 2.2.1.1.
o Section 2.2.2 requires that a BXXP peer close a channel when a o Section 2.2.2 requires that a BXXP peer close a channel when a
poorly-formed response is received (unless it's channel 0, in poorly-formed reply is received (unless it's channel zero, in
which case the BXXP session is terminated). which case the BXXP session is terminated).
o Section 2.2.2 explains that in an XML-based profile, if something o Section 2.2.2 explains that in an XML-based profile, if something
other than UTF-8 is sent, then a "Content-Type:" entity-header other than UTF-8 is sent, then a "Content-Type:" entity-header
must be present to specify the character set. must be present to specify the character set.
o The close (Section 2.3.1.3) and ok (Section 2.3.1.4) messages o The close (Section 2.3.1.3) and ok (Section 2.3.1.4) messages
were added. were added.
o Both Section 2.3.1.3 and Section 2.3.1.5 clarify that diagnostic o Both Section 2.3.1.3 and Section 2.3.1.5 clarify that diagnostic
text is not to be interpreted by programs. text is not to be interpreted by programs.
o Section 5 limits the the size of an initialization element to 4K o Section 5 limits the the size of an initialization element to 4K
octets. octets.
Appendix B. Changes from draft-mrose-bxxp-framework-00 Appendix C. Changes from draft-mrose-bxxp-framework-00
o The IPR notice is changed to be in full conformance with all o The IPR notice is changed to be in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
o At the beginning of Section 2.2 (and in the ABNF in Section o At the beginning of Section 2.2 (and in the ABNF in Section
2.2.1) the relationship between messages and frames is clarified. 2.2.1) the relationship between messages and frames is clarified.
o A typo involving the final CR LF in the ABNF in Section 2.2.1 is o A typo involving the final CR LF in the ABNF in Section 2.2.1 is
corrected. corrected.
skipping to change at page 57, line 5 skipping to change at page 57, line 5
"transport-specific" assertion (the sixth rule for identifying "transport-specific" assertion (the sixth rule for identifying
poorly-formed frames). poorly-formed frames).
o At the beginning of Section 2.3, an explanation of the o At the beginning of Section 2.3, an explanation of the
relstionship between profiles and channels (and the greeting and relstionship between profiles and channels (and the greeting and
start messages) is added. start messages) is added.
o In Section 2.3.1, the order of the sections for the greeting and o In Section 2.3.1, the order of the sections for the greeting and
start messages is reversed for readability. start messages is reversed for readability.
Appendix C. Acknowledgements Appendix D. Acknowledgements
The author gratefully acknowledges the contributions of: David The author gratefully acknowledges the contributions of: David
Clark, Dave Crocker, Steve Deering, Marco Gazzetta, Danny Goodman, Clark, Dave Crocker, Steve Deering, Marco Gazzetta, Danny Goodman,
Steve Harris, Robert Herriot, Ken Hirsch, Ben Laurie, Carl Malamud, Steve Harris, Robert Herriot, Ken Hirsch, Greg Hudson, Ben Laurie,
Michael Mealling, Keith McCloghrie, Paul Mockapetris, RL 'Bob' Carl Malamud, Michael Mealling, Keith McCloghrie, Paul Mockapetris,
Morgan, Frank Morton, Darren New, Chris Newman, Joe Touch, Paul RL 'Bob' Morgan, Frank Morton, Darren New, Chris Newman, Joe Touch,
Vixie, Gabe Wachob, and, Daniel Woods. In particular, Dave Crocker Paul Vixie, Gabe Wachob, Daniel Woods, and, James Woodyatt. In
provided helpful suggestions on the nature of segmentation in the particular, Dave Crocker provided helpful suggestions on the nature
framing protocol. of segmentation in the framing protocol.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). 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
 End of changes. 225 change blocks. 
508 lines changed or deleted 560 lines changed or added

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