draft-ietf-beep-framework-03.txt   draft-ietf-beep-framework-04.txt 
Network Working Group M.T. Rose Network Working Group M.T. Rose
Internet-Draft Invisible Worlds, Inc. Internet-Draft Invisible Worlds, Inc.
Expires: April 9, 2001 October 9, 2000 Expires: April 10, 2001 October 10, 2000
The Blocks Extensible Exchange Protocol Framework The Blocks Extensible Exchange Protocol Framework
draft-ietf-beep-framework-03 draft-ietf-beep-framework-04
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 April 9, 2001. This Internet-Draft will expire on April 10, 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 interactions. The framework connection-oriented, asynchronous interactions. The framework
permits simultaneous and independent exchanges within the context of permits simultaneous and independent exchanges within the context of
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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.2.2.1 Poorly-formed Messages . . . . . . . . . . . . . . . . . . 14 2.2.2.1 Poorly-formed Messages . . . . . . . . . . . . . . . . . . 14
2.2.2.2 XML-based Profiles . . . . . . . . . . . . . . . . . . . . 15 2.2.2.2 XML-based Profiles . . . . . . . . . . . . . . . . . . . . 15
2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 16 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 17 2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 17
2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 17 2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 17
2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 19 2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 18
2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 22 2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 21
2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 24 2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 24 2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 23
2.4 Session Establishment and Release . . . . . . . . . . . . 26 2.4 Session Establishment and Release . . . . . . . . . . . . 25
2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 28 2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 28 2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 27
2.5.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . 28 2.5.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . 27
2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 29 2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.1 Within a Single Channel . . . . . . . . . . . . . . . . . 29 2.6.1 Within a Single Channel . . . . . . . . . . . . . . . . . 28
2.6.2 Between Different Channels . . . . . . . . . . . . . . . . 29 2.6.2 Between Different Channels . . . . . . . . . . . . . . . . 28
2.6.3 Pre-emptive Replies . . . . . . . . . . . . . . . . . . . 29 2.6.3 Pre-emptive Replies . . . . . . . . . . . . . . . . . . . 28
2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 29 2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 28
2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 30 2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 29
3. Transport Security . . . . . . . . . . . . . . . . . . . . 31 3. Transport Security . . . . . . . . . . . . . . . . . . . . 30
3.1 The TLS Transport Security Profile . . . . . . . . . . . . 34 3.1 The TLS Transport Security Profile . . . . . . . . . . . . 33
3.1.1 Profile Identification and Initialization . . . . . . . . 34 3.1.1 Profile Identification and Initialization . . . . . . . . 33
3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 35 3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 34
3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 36 3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 35
3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 36 3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 35
3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 36 3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 35
4. User Authentication . . . . . . . . . . . . . . . . . . . 37 4. User Authentication . . . . . . . . . . . . . . . . . . . 36
4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 38 4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 37
4.1.1 Profile Identification and Initialization . . . . . . . . 39 4.1.1 Profile Identification and Initialization . . . . . . . . 38
4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 42 4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 41
4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 43 4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 42
5. Registration Templates . . . . . . . . . . . . . . . . . . 44 5. Registration Templates . . . . . . . . . . . . . . . . . . 43
5.1 Profile Registration Template . . . . . . . . . . . . . . 44 5.1 Profile Registration Template . . . . . . . . . . . . . . 43
5.2 Feature Registration Template . . . . . . . . . . . . . . 44 5.2 Feature Registration Template . . . . . . . . . . . . . . 43
6. Initial Registrations . . . . . . . . . . . . . . . . . . 45 6. Initial Registrations . . . . . . . . . . . . . . . . . . 44
6.1 Registration: BEEP Channel Management . . . . . . . . . . 45 6.1 Registration: BEEP Channel Management . . . . . . . . . . 44
6.2 Registration: TLS Transport Security Profile . . . . . . . 45 6.2 Registration: TLS Transport Security Profile . . . . . . . 44
6.3 Registration: SASL Family of Profiles . . . . . . . . . . 46 6.3 Registration: SASL Family of Profiles . . . . . . . . . . 45
7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 47 7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 46
7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 49 7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 48
7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 50 7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 49
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 51 8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 50
9. Security Considerations . . . . . . . . . . . . . . . . . 52 9. Security Considerations . . . . . . . . . . . . . . . . . 51
References . . . . . . . . . . . . . . . . . . . . . . . . 53 References . . . . . . . . . . . . . . . . . . . . . . . . 52
Author's Address . . . . . . . . . . . . . . . . . . . . . 54 Author's Address . . . . . . . . . . . . . . . . . . . . . 53
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 55 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 54
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 56 B. IANA Considerations . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statement . . . . . . . . . . . . . . . . . 57 Full Copyright Statement . . . . . . . . . . . . . . . . . 56
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 interactions. connection-oriented, asynchronous interactions.
At the core of the BEEP framework is a framing mechanism that At the core of the BEEP framework is a framing mechanism that
permits simultaneous and independent exchanges of messages between permits simultaneous and independent exchanges of messages between
peers. Messages are arbitrary MIME[1] content, but are usually peers. Messages are arbitrary MIME[1] content, but are usually
textual (structured using XML[2]). textual (structured using XML[2]).
skipping to change at page 7, line 36 skipping to change at page 7, line 36
contains a payload of 119 octets spread over 5 lines (each line is contains a payload of 119 octets spread over 5 lines (each line is
terminated with a CRLF pair): terminated with a CRLF pair):
C: MSG 0 1 . 40 120 C: MSG 0 1 . 40 120
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start> C: </start>
C: END C: END
C:
In this example, note that the entire message is represented in a In this example, note that the entire message is represented in a
single frame. single frame.
2.2.1 Frame Syntax 2.2.1 Frame Syntax
The ABNF[7] for a frame is: The ABNF[7] for a frame is:
frame = data / mapping frame = data / mapping
skipping to change at page 9, line 42 skipping to change at page 9, line 42
The payload size ("size") must be a non-negative integer (in the The payload size ("size") must be a non-negative integer (in the
range 0..2147483647) and specifies the exact number of octets in the range 0..2147483647) and specifies the exact number of octets in the
payload. (This does not include either the header or trailer.) payload. (This does not include either the header or trailer.)
Note that a frame may have an empty payload, e.g., Note that a frame may have an empty payload, e.g.,
S: RPY 0 1 * 287 20 S: RPY 0 1 * 287 20
S: ... S: ...
S: ... S: ...
S: END S: END
S:
S: RPY 0 1 . 307 0 S: RPY 0 1 . 307 0
S: END S: END
S:
The answer number ("ansno") must be a non-negative integer (in the The answer number ("ansno") must be a non-negative integer (in the
range 0..4294967295) and must have a different value than all other range 0..4294967295) and must have a different value than all other
answers in progress for the message being replied to. answers in progress for the message being replied to.
There are two kinds of frames: data and mapping. each transport There are two kinds of frames: data and mapping. each transport
mapping (c.f., Section 2.5) may define its own frames. For example, mapping (c.f., Section 2.5) may define its own frames. For example,
[5] defines the SEQ frame. The remainder of this section discusses [5] defines the SEQ frame. The remainder of this section discusses
data frames. data frames.
skipping to change at page 10, line 23 skipping to change at page 10, line 23
first, no restriction is made with respect to the interleaving of first, no restriction is made with respect to the interleaving of
frames for other channels; and, second, in a one-to-many exchange, frames for other channels; and, second, in a one-to-many exchange,
multiple answers may be simultaneously in progress. Accordingly, multiple answers may be simultaneously in progress. Accordingly,
frames for "ANS" messages may be interleaved on the same channel -- frames for "ANS" messages may be interleaved on the same channel --
the answer number is used for collation, e.g., the answer number is used for collation, e.g.,
S: ANS 1 0 * 0 20 0 S: ANS 1 0 * 0 20 0
S: ... S: ...
S: ... S: ...
S: END S: END
S:
S: ANS 1 0 * 20 20 1 S: ANS 1 0 * 20 20 1
S: ... S: ...
S: ... S: ...
S: END S: END
S:
S: ANS 1 0 . 40 10 0 S: ANS 1 0 . 40 10 0
S: ... S: ...
S: END S: END
S:
which shows two "ANS" messages interleaved on channel 1 as part of a which shows two "ANS" messages interleaved on channel 1 as part of a
reply to message number 0. Note that the sequence number is advanced reply to message number 0. Note that the sequence number is advanced
for each frame sent on the channel, and is independent of the for each frame sent on the channel, and is independent of the
messages sent in those frames. messages sent in those frames.
There are several rules for identifying poorly-formed frames: There are several rules for identifying poorly-formed frames:
o if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or o if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or
"NUL"; "NUL";
skipping to change at page 17, line 22 skipping to change at page 17, line 22
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 110 L: RPY 0 0 . 0 110
L: Content-Type: text/xml L: Content-Type: text/xml
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
L:
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 40
I: Content-Type: text/xml I: Content-Type: text/xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I:
Note that this example implies that the BEEP peer in the initiating Note that this example implies that the BEEP peer in the initiating
role waits until the BEEP peer in the listening role sends its role waits until the BEEP peer in the listening role sends its
greeting -- this is an artifact of the presentation; in fact, both greeting -- this is an artifact of the presentation; in fact, both
BEEP peers send their replies independently. BEEP peers send their replies independently.
The "greeting" element has two optional attributes ("features" and The "greeting" element has two optional attributes ("features" and
"localize") and zero or more "profile" elements, one for each "localize") and zero or more "profile" elements, one for each
profile supported by the BEEP peer acting in a server role: profile supported by the BEEP peer acting in a server role:
skipping to change at page 18, line 24 skipping to change at page 17, line 52
language tokens (defined in [8]), each identifying a desirable language tokens (defined in [8]), each identifying a desirable
language tag to be used by the remote BEEP peer when generating language tag to be used by the remote BEEP peer when generating
textual diagnostics for the "close" and "error" elements (the textual diagnostics for the "close" and "error" elements (the
tokens are ordered from most to least desirable); and, tokens are ordered from most to least desirable); and,
o each "profile" element contained within the "greeting" element o each "profile" element contained within the "greeting" element
identifies a profile, and unlike the "profile" elements that identifies a profile, and unlike the "profile" elements that
occur 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 message. element may not contain an optional initialization message.
At present, there are no optional features defined for the channel
management profile.
Section 5.2 defines a registration template for optional features. Section 5.2 defines a registration template for optional features.
2.3.1.2 The Start Message 2.3.1.2 The Start Message
When a BEEP peer wants to create a channel, it sends a "start" When a BEEP peer wants to create a channel, it sends a "start"
element on channel zero, e.g., element on channel zero, e.g.,
C: MSG 0 1 . 40 120 C: MSG 0 1 . 40 120
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start> C: </start>
C: END C: END
C:
The "start" element has a "number" attribute, an optional The "start" element has a "number" attribute, an optional
"serverName" attribute, and one or more "profile" elements: "serverName" attribute, and one or more "profile" elements:
o the "number" attribute indicates the channel number (in the range o the "number" attribute indicates the channel number (in the range
1..2147483647) used to identify the channel in future messages; 1..2147483647) used to identify the channel in future messages;
o the "serverName" attribute, an arbitrary string, indicates the o the "serverName" attribute, an arbitrary string, indicates the
desired server name for this BEEP session; and, desired server name for this BEEP session; and,
skipping to change at page 20, line 27 skipping to change at page 19, line 27
C: MSG 0 1 . 40 197 C: MSG 0 1 . 40 197
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: <profile C: <profile
C: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' /> C: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
C: </start> C: </start>
C: END C: END
C:
S: RPY 0 1 . 252 87 S: RPY 0 1 . 252 87
S: Content-Type: text/xml S: Content-Type: text/xml
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
S:
Similarly, an unsuccessful channel creation might look like this: Similarly, an unsuccessful channel creation might look like this:
C: MSG 0 1 . 40 120 C: MSG 0 1 . 40 120
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <start number='2'> C: <start number='2'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start> C: </start>
C: END C: END
C:
S: ERR 0 1 . 252 115 S: ERR 0 1 . 252 115
S: Content-Type: text/xml S: Content-Type: text/xml
S: S:
S: <error code='501'>number attribute S: <error code='501'>number attribute
S: in &lt;start&gt; element must be odd-valued</error> S: in &lt;start&gt; element must be odd-valued</error>
S: END S: END
S:
Finally, here's an example in which an initialization element is Finally, here's an example in which an initialization element is
exchanged during channel creation: exchanged during channel creation:
C: MSG 0 1 . 40 158 C: MSG 0 1 . 40 158
C: Content-Type: text/xml C: Content-Type: text/xml
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: <![CDATA[<ready />]]> C: <![CDATA[<ready />]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
C:
S: RPY 0 1 . 110 121 S: RPY 0 1 . 110 121
S: Content-Type: text/xml S: Content-Type: text/xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/TLS'> S: <profile uri='http://xml.resource.org/profiles/TLS'>
S: <![CDATA[<proceed />]]> S: <![CDATA[<proceed />]]>
S: </profile> S: </profile>
S: END S: END
S:
2.3.1.3 The Close Message 2.3.1.3 The Close Message
When a BEEP peer wants to close a channel, it sends a "close" When a BEEP peer wants to close a channel, it sends a "close"
element on channel zero, e.g., element on channel zero, e.g.,
C: MSG 0 2 . 223 59 C: MSG 0 2 . 223 59
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <close number='1' code='200' /> C: <close number='1' code='200' />
C: END C: END
C:
The "close" element has a "number" attribute, a "code" attribute, an The "close" element has a "number" attribute, a "code" attribute, an
optional "xml:lang" attribute, and an optional textual diagnostic as optional "xml:lang" attribute, and an optional textual diagnostic as
its content: its content:
o the "number" attribute indicates the channel number; o the "number" attribute indicates the channel number;
o the "code" attribute is a three-digit reply code meaningful to o the "code" attribute is a three-digit reply code meaningful to
programs (c.f., Section 8); programs (c.f., Section 8);
skipping to change at page 23, line 12 skipping to change at page 22, line 12
element is sent in a positive reply; otherwise, an "error" element element is sent in a positive reply; otherwise, an "error" element
is sent in a negative reply. 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:
C: MSG 0 2 . 223 59 C: MSG 0 2 . 223 59
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <close number='1' code='200' /> C: <close number='1' code='200' />
C: END C: END
C:
S: RPY 0 2 . 423 34 S: RPY 0 2 . 423 34
S: Content-Type: text/xml S: Content-Type: text/xml
S: S:
S: <ok /> S: <ok />
S: END S: END
S:
Similarly, an unsuccessful channel close might look like this: Similarly, an unsuccessful channel close might look like this:
C: MSG 0 2 . 223 59 C: MSG 0 2 . 223 59
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <close number='1' code='200' /> C: <close number='1' code='200' />
C: END C: END
C:
S: ERR 0 2 . 423 67 S: ERR 0 2 . 423 67
S: Content-Type: text/xml S: Content-Type: text/xml
S: S:
S: <error code='550'>still working</error> S: <error code='550'>still working</error>
S: END S: END
S:
2.3.1.4 The OK Message 2.3.1.4 The OK Message
When a BEEP peer agrees to close a channel (or release the BEEP When a BEEP peer agrees to close a channel (or release the BEEP
session), it sends an "ok" element in a positive reply. session), it sends an "ok" element in a positive reply.
The "ok" element has no attributes and no content. The "ok" element has no attributes and no content.
2.3.1.5 The Error Message 2.3.1.5 The Error Message
When a BEEP peer declines the creation of a channel, it sends an When a BEEP peer declines the creation of a channel, it sends an
"error" element in a negative reply, e.g., "error" element in a negative reply, e.g.,
I: MSG 0 1 . 40 115 I: MSG 0 1 . 40 115
I: Content-Type: text/xml I: Content-Type: text/xml
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
I:
L: ERR 0 1 . 252 93 L: ERR 0 1 . 252 93
L: Content-Type: text/xml L: Content-Type: text/xml
L: L:
L: <error code='550'>all requested profiles are L: <error code='550'>all requested profiles are
L: unsupported</error> L: unsupported</error>
L: END L: END
L:
The "error" element has a "code" attribute, an optional "xml:lang" The "error" element has a "code" attribute, an optional "xml:lang"
attribute, and an optional textual diagnostic as its content: attribute, and an optional textual diagnostic as its content:
o the "code" attribute is a three-digit reply code meaningful to o the "code" attribute is a three-digit reply code meaningful to
programs (c.f., Section 8); programs (c.f., Section 8);
o the "xml:lang" attribute identifies the language that the o the "xml:lang" attribute identifies the language that the
element's content is written in (the value is suggested, but not element's content is written in (the value is suggested, but not
mandated, by the "localize" attribute of the "greeting" element mandated, by the "localize" attribute of the "greeting" element
skipping to change at page 26, line 21 skipping to change at page 25, line 21
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 110 L: RPY 0 0 . 0 110
L: Content-Type: text/xml L: Content-Type: text/xml
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
L:
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 40
I: Content-Type: text/xml I: Content-Type: text/xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I:
Alternatively, if the BEEP peer acting in the listening role is Alternatively, if the BEEP peer acting in the listening role is
unavailable, it sends a negative reply, e.g., unavailable, it sends a negative reply, e.g.,
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: ERR 0 0 . 0 48 L: ERR 0 0 . 0 48
L: Content-Type: text/xml L: Content-Type: text/xml
L: L:
L: <error code='421' /> L: <error code='421' />
L: END L: END
L:
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 40
I: Content-Type: text/xml I: Content-Type: text/xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I:
I: <close connection> I: <close connection>
L: <close connection> L: <close connection>
L: <wait for next connection> L: <wait for next connection>
and the "greeting" element sent by the BEEP peer acting in the and the "greeting" element sent by the BEEP peer acting in the
initiating role is ignored. It is recommended that a diagnostic initiating role is ignored. It is recommended that a diagnostic
entry be logged by both BEEP peers. entry be logged by both BEEP peers.
Note that both of these examples imply that the BEEP peer in the Note that both of these examples imply that the BEEP peer in the
initiating role waits until the BEEP peer in the listening role initiating role waits until the BEEP peer in the listening role
skipping to change at page 27, line 20 skipping to change at page 26, line 15
When a BEEP peer wants to release the BEEP session, it sends a When a BEEP peer wants to release the BEEP session, it sends a
"close" element with a zero-valued "number" attribute on channel "close" element with a zero-valued "number" attribute on channel
zero. The other BEEP peer indicates its willingness by sending an zero. The other BEEP peer indicates its willingness by sending an
"ok" element in a positive reply, e.g., "ok" element in a positive reply, e.g.,
C: MSG 0 1 . 40 48 C: MSG 0 1 . 40 48
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <close code='200' /> C: <close code='200' />
C: END C: END
C:
S: RPY 0 1 . 252 34 S: RPY 0 1 . 252 34
S: Content-Type: text/xml S: Content-Type: text/xml
S: S:
S: <ok /> S: <ok />
S: END S: END
S:
I: <close connection> I: <close connection>
L: <close connection> L: <close connection>
L: <wait for next connection> L: <wait for next connection>
Alternatively, if the other BEEP doesn't want to release the BEEP Alternatively, if the other BEEP doesn't want to release the BEEP
session, the exchange might look like this: session, the exchange might look like this:
C: MSG 0 1 . 40 48 C: MSG 0 1 . 40 48
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <close code='200' /> C: <close code='200' />
C: END C: END
C:
S: ERR 0 1 . 252 67 S: ERR 0 1 . 252 67
S: Content-Type: text/xml S: Content-Type: text/xml
S: S:
S: <error code='550'>still working</error> S: <error code='550'>still working</error>
S: END S: END
S:
If session release is declined, the BEEP session should not be If session release is declined, the BEEP session should not be
terminated, if possible. terminated, if possible.
2.5 Transport Mappings 2.5 Transport Mappings
All transport interactions occur in the context of a session -- a All transport interactions occur in the context of a session -- a
mapping onto a particular transport service. Accordingly, this memo mapping onto a particular transport service. Accordingly, this memo
defines the requirements that must be satisified by any document defines the requirements that must be satisified by any document
describing how a particular transport service realizes a BEEP describing how a particular transport service realizes a BEEP
skipping to change at page 30, line 29 skipping to change at page 29, line 29
For example, these two messages For example, these two messages
I: MSG 0 1 . 40 120 I: MSG 0 1 . 40 120
I: Content-Type: text/xml I: Content-Type: text/xml
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
I: </start> I: </start>
I: END I: END
I:
L: MSG 0 1 . 252 116 L: MSG 0 1 . 252 116
L: Content-Type: text/xml L: Content-Type: text/xml
L: L:
L: <start number='2'> L: <start number='2'>
L: <profile uri='http://xml.resource.org/profiles/IMXP' /> L: <profile uri='http://xml.resource.org/profiles/IMXP' />
L: </start> L: </start>
L: END L: END
L:
refer to different messages sent on channel zero. refer to different messages sent on channel zero.
3. Transport Security 3. Transport Security
When a BEEP session is established, plaintext transfer, without When a BEEP session is established, plaintext transfer, without
privacy, is provided. Accordingly, transport security in BEEP is privacy, is provided. Accordingly, transport security in BEEP is
achieved using an initial tuning profile. achieved using an initial tuning profile.
This document defines one profile: This document defines one profile:
skipping to change at page 31, line 40 skipping to change at page 30, line 40
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 110 L: RPY 0 0 . 0 110
L: Content-Type: text/xml L: Content-Type: text/xml
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
L:
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 40
I: Content-Type: text/xml I: Content-Type: text/xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I:
I: MSG 0 1 . 40 158 I: MSG 0 1 . 40 158
I: Content-Type: text/xml I: Content-Type: text/xml
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: <![CDATA[<ready />]]> I: <![CDATA[<ready />]]>
I: </profile> I: </profile>
I: </start> I: </start>
I: END I: END
I:
L: RPY 0 1 . 110 121 L: RPY 0 1 . 110 121
L: Content-Type: text/xml L: Content-Type: text/xml
L: L:
L: <profile uri='http://xml.resource.org/profiles/TLS'> L: <profile uri='http://xml.resource.org/profiles/TLS'>
L: <![CDATA[<proceed />]]> L: <![CDATA[<proceed />]]>
L: </profile> L: </profile>
L: END L: END
L:
... successful transport security negotiation ... ... successful transport security negotiation ...
L: RPY 0 0 . 0 252 L: RPY 0 0 . 0 252
L: Content-Type: text/xml L: Content-Type: text/xml
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/IMXP' /> L: <profile uri='http://xml.resource.org/profiles/IMXP' />
L: </greeting> L: </greeting>
L: END L: END
L:
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 40
I: Content-Type: text/xml I: Content-Type: text/xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I:
Of course, not all BEEP peers need be as single-minded: Of course, not all BEEP peers need be as single-minded:
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 311 L: RPY 0 0 . 0 311
L: Content-Type: text/xml L: Content-Type: text/xml
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/IMXP' /> 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
L:
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 40
I: Content-Type: text/xml I: Content-Type: text/xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I:
I: MSG 0 1 . 40 158 I: MSG 0 1 . 40 158
I: Content-Type: text/xml I: Content-Type: text/xml
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: <![CDATA[<ready />]]> I: <![CDATA[<ready />]]>
I: </profile> I: </profile>
I: </start> I: </start>
I: END I: END
I:
L: RPY 0 1 . 311 121 L: RPY 0 1 . 311 121
L: Content-Type: text/xml L: Content-Type: text/xml
L: L:
L: <profile uri='http://xml.resource.org/profiles/TLS'> L: <profile uri='http://xml.resource.org/profiles/TLS'>
L: <![CDATA[<proceed />]]> L: <![CDATA[<proceed />]]>
L: </profile> L: </profile>
L: END L: END
L:
... failed transport security negotiation ... ... failed transport security negotiation ...
L: RPY 0 0 . 0 311 L: RPY 0 0 . 0 311
L: Content-Type: text/xml L: Content-Type: text/xml
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/IMXP' /> 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
L:
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 40
I: Content-Type: text/xml I: Content-Type: text/xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I:
3.1 The TLS Transport Security Profile 3.1 The TLS Transport Security Profile
Section 6.2 contains the registration for this profile. Section 6.2 contains the registration for this profile.
3.1.1 Profile Identification and Initialization 3.1.1 Profile Identification and Initialization
The TLS transport security profile is identified as: The TLS transport security profile is identified as:
http://xml.resource.org/profiles/TLS http://xml.resource.org/profiles/TLS
skipping to change at page 34, line 32 skipping to change at page 33, line 32
C: MSG 0 1 . 40 158 C: MSG 0 1 . 40 158
C: Content-Type: text/xml C: Content-Type: text/xml
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: <![CDATA[<ready />]]> C: <![CDATA[<ready />]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
C:
S: RPY 0 1 . 110 121 S: RPY 0 1 . 110 121
S: Content-Type: text/xml S: Content-Type: text/xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/TLS'> S: <profile uri='http://xml.resource.org/profiles/TLS'>
S: <![CDATA[<proceed />]]> S: <![CDATA[<proceed />]]>
S: </profile> S: </profile>
S: END S: END
S:
Note that it is possible for the channel to be created, but for the Note that it is possible for the channel to be created, but for the
encapsulated operation to fail, e.g., encapsulated operation to fail, e.g.,
C: MSG 0 1 . 40 173 C: MSG 0 1 . 40 173
C: Content-Type: text/xml C: Content-Type: text/xml
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: <![CDATA[<ready version="oops" />]]> C: <![CDATA[<ready version="oops" />]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
C:
S: RPY 0 1 . 110 181 S: RPY 0 1 . 110 181
S: Content-Type: text/xml S: Content-Type: text/xml
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
S:
In this case, a positive reply is sent (as channel creation In this case, a positive reply is sent (as channel creation
succeeded), but the encapsulated response contains an indication as succeeded), but the encapsulated response contains an indication as
to why the operation failed. to why the operation failed.
3.1.2 Message Syntax 3.1.2 Message Syntax
Section 7.2 defines the messages that are used in the TLS transport Section 7.2 defines the messages that are used in the TLS transport
security profile. security profile.
skipping to change at page 39, line 26 skipping to change at page 38, line 26
C: MSG 0 1 . 40 197 C: MSG 0 1 . 40 197
C: Content-Type: text/xml C: Content-Type: text/xml
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
C:
S: RPY 0 1 . 252 87 S: RPY 0 1 . 252 87
S: Content-Type: text/xml S: Content-Type: text/xml
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
S:
During channel creation, the corresponding "profile" element in the During channel creation, the corresponding "profile" element in the
BEEP "start" element may contain a "blob" element. Note that it is BEEP "start" element may contain a "blob" element. Note that it is
possible for the channel to be created, but for the encapsulated possible for the channel to be created, but for the encapsulated
operation to fail, e.g., operation to fail, e.g.,
C: MSG 0 1 . 40 183 C: MSG 0 1 . 40 183
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]> C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
C:
S: RPY 0 1 . 252 166 S: RPY 0 1 . 252 166
S: Content-Type: text/xml S: Content-Type: text/xml
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
S:
In this case, a positive reply is sent (as channel creation In this case, a positive reply is sent (as channel creation
succeeded), but the encapsulated response contains an indication as succeeded), but the encapsulated response contains an indication as
to why the operation failed. to why the operation failed.
Otherwise, the server sends a challenge (or signifies success), e.g., Otherwise, the server sends a challenge (or signifies success), e.g.,
C: MSG 0 1 . 40 183 C: MSG 0 1 . 40 183
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]> C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
C:
S: RPY 0 1 . 252 171 S: RPY 0 1 . 252 171
S: Content-Type: text/xml S: Content-Type: text/xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> S: <profile uri='http://xml.resource.org/profiles/sasl/OTP'>
S: <![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ= S: <![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
</blob>]]> </blob>]]>
S: </profile> S: </profile>
S: END S: END
S:
Note that this example implies that the "blob" element in the Note that this example implies that the "blob" element in the
server's reply appears on two lines -- this is an artifact of the server's reply appears on two lines -- this is an artifact of the
presentation; in fact, only one line is used. presentation; in fact, only one line is used.
If a challenge is received, then the client responds and awaits If a challenge is received, then the client responds and awaits
another reply, e.g., another reply, e.g.,
C: MSG 1 0 . 0 85 C: MSG 1 0 . 0 85
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob> C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END C: END
C:
S: RPY 1 0 . 0 54 S: RPY 1 0 . 0 54
S: Content-Type: text/xml S: Content-Type: text/xml
S: S:
S: <blob status='complete' /> S: <blob status='complete' />
S: END S: END
S:
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: MSG 1 0 . 0 85 C: MSG 1 0 . 0 85
C: Content-Type: text/xml C: Content-Type: text/xml
C: C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob> C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END C: END
C:
S: ERR 1 1 . 0 48 S: ERR 1 1 . 0 48
S: Content-Type: text/xml S: Content-Type: text/xml
S: S:
S: <error code='535' /> S: <error code='535' />
S: END S: END
S:
Finally, depending on the SASL mechanism, an initialization element Finally, depending on the SASL mechanism, an initialization element
may be exchanged unidirectionally during channel creation, e.g., may be exchanged unidirectionally during channel creation, e.g.,
C: MSG 0 1 . 40 133 C: MSG 0 1 . 40 133
C: Content-Type: text/xml C: Content-Type: text/xml
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
C:
S: RPY 0 1 . 252 173 S: RPY 0 1 . 252 173
S: Content-Type: text/xml S: Content-Type: text/xml
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
S:
Note that this example implies that the "blob" element in the Note that this example implies that the "blob" element in the
server's reply appears on two lines -- this is an artifact of the server's reply appears on two lines -- this is an artifact of the
presentation; in fact, only one line is used. presentation; in fact, only one line is used.
4.1.2 Message Syntax 4.1.2 Message Syntax
Section 7.3 defines the messages that are used for each profile in Section 7.3 defines the messages that are used for each profile in
the SASL family. the SASL family.
skipping to change at page 53, line 23 skipping to change at page 52, line 23
<URL:http://www.w3.org/TR/1998/REC-xml-19980210>. <URL:http://www.w3.org/TR/1998/REC-xml-19980210>.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A. [3] 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.
[4] Myers, J.G., "Simple Authentication and Security Layer [4] Myers, J.G., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997. (SASL)", RFC 2222, October 1997.
[5] Rose, M.T., "Mapping the BEEP Framework onto TCP", [5] Rose, M.T., "Mapping the BEEP Framework onto TCP",
draft-ietf-beep-tcpmapping-03 (work in progress), October 2000. draft-ietf-beep-tcpmapping-04 (work in progress), October 2000.
[6] Postel, J., "Transmission Control Protocol", RFC 793, STD 7, [6] Postel, J., "Transmission Control Protocol", RFC 793, STD 7,
Sep 1981. Sep 1981.
[7] Crocker, D. H. and P. Overell, "Augmented BNF for Syntax [7] Crocker, D. H. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[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.
 End of changes. 67 change blocks. 
115 lines changed or deleted 49 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/