draft-ietf-beep-framework-10.txt   draft-ietf-beep-framework-11.txt 
Network Working Group M.T. Rose Network Working Group M.T. Rose
Internet-Draft Invisible Worlds, Inc. Internet-Draft Invisible Worlds, Inc.
Expires: June 26, 2001 December 26, 2000 Expires: July 5, 2001 January 4, 2001
The Blocks Extensible Exchange Protocol Framework The Blocks Extensible Exchange Protocol Core
draft-ietf-beep-framework-10 draft-ietf-beep-framework-11
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document 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 June 26, 2001. This Internet-Draft will expire on July 5, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This memo describes a generic application protocol framework for This memo describes a generic application protocol kernel for
connection-oriented, asynchronous interactions. The framework connection-oriented, asynchronous interactions called BEEP. BEEP
permits simultaneous and independent exchanges within the context of permits simultaneous and independent exchanges within the context of
a single application user-identity, supporting both textual and a single application user-identity, supporting both textual and
binary messages. binary messages.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. The BEEP Framework . . . . . . . . . . . . . . . . . . . . 5 2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . . . . . 6 2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . . . . . 6
2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7 2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7
2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9
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.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 16 2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 16
2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16 2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16
2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 17 2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 17
2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 20 2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 20
2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 22 2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 22 2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 23
2.4 Session Establishment and Release . . . . . . . . . . . . 24 2.4 Session Establishment and Release . . . . . . . . . . . . 25
2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 26 2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 26 2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 27
2.5.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . 26 2.5.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . 27
2.6 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.1 Within a Single Channel . . . . . . . . . . . . . . . . . 27 2.6.1 Within a Single Channel . . . . . . . . . . . . . . . . . 28
2.6.2 Between Different Channels . . . . . . . . . . . . . . . . 27 2.6.2 Between Different Channels . . . . . . . . . . . . . . . . 28
2.6.3 Pre-emptive Replies . . . . . . . . . . . . . . . . . . . 28 2.6.3 Pre-emptive Replies . . . . . . . . . . . . . . . . . . . 29
2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 28 2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 29
2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 29 2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 30
3. Transport Security . . . . . . . . . . . . . . . . . . . . 30 3. Transport Security . . . . . . . . . . . . . . . . . . . . 31
3.1 The TLS Transport Security Profile . . . . . . . . . . . . 33 3.1 The TLS Transport Security Profile . . . . . . . . . . . . 34
3.1.1 Profile Identification and Initialization . . . . . . . . 33 3.1.1 Profile Identification and Initialization . . . . . . . . 34
3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 34 3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 35 3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 36
3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 35 3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 36
3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 35 3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 36
4. User Authentication . . . . . . . . . . . . . . . . . . . 36 4. User Authentication . . . . . . . . . . . . . . . . . . . 37
4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 37 4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 38
4.1.1 Profile Identification and Initialization . . . . . . . . 38 4.1.1 Profile Identification and Initialization . . . . . . . . 39
4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 41 4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 42
4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 42 4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 43
5. Registration Templates . . . . . . . . . . . . . . . . . . 43 5. Registration Templates . . . . . . . . . . . . . . . . . . 44
5.1 Profile Registration Template . . . . . . . . . . . . . . 43 5.1 Profile Registration Template . . . . . . . . . . . . . . 44
5.2 Feature Registration Template . . . . . . . . . . . . . . 43 5.2 Feature Registration Template . . . . . . . . . . . . . . 44
6. Initial Registrations . . . . . . . . . . . . . . . . . . 44 6. Initial Registrations . . . . . . . . . . . . . . . . . . 45
6.1 Registration: BEEP Channel Management . . . . . . . . . . 44 6.1 Registration: BEEP Channel Management . . . . . . . . . . 45
6.2 Registration: TLS Transport Security Profile . . . . . . . 44 6.2 Registration: TLS Transport Security Profile . . . . . . . 45
6.3 Registration: SASL Family of Profiles . . . . . . . . . . 45 6.3 Registration: SASL Family of Profiles . . . . . . . . . . 46
6.4 Registration: application/beep+xml . . . . . . . . . . . . 46 6.4 Registration: application/beep+xml . . . . . . . . . . . . 47
7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 47 7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 48
7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 49 7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 50
7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 50 7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 51
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 51 8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 52
9. Security Considerations . . . . . . . . . . . . . . . . . 52 9. Security Considerations . . . . . . . . . . . . . . . . . 53
References . . . . . . . . . . . . . . . . . . . . . . . . 53 References . . . . . . . . . . . . . . . . . . . . . . . . 54
Author's Address . . . . . . . . . . . . . . . . . . . . . 54 Author's Address . . . . . . . . . . . . . . . . . . . . . 55
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 55 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 56 B. IANA Considerations . . . . . . . . . . . . . . . . . . . 57
Full Copyright Statement . . . . . . . . . . . . . . . . . 57 Full Copyright Statement . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
This memo describes a generic application protocol framework for This memo describes a generic application protocol kernel for
connection-oriented, asynchronous interactions. connection-oriented, asynchronous interactions called BEEP.
At the core of the BEEP framework is a framing mechanism that At BEEP's core is a framing mechanism that permits simultaneous and
permits simultaneous and independent exchanges of messages between independent exchanges of messages between peers. Messages are
peers. Messages are arbitrary MIME[1] content, but are usually arbitrary MIME[1] content, but are usually textual (structured using
textual (structured using XML[2]). XML[2]).
All exchanges occur in the context of a channel -- a binding to a All exchanges occur in the context of a channel -- a binding to a
well-defined aspect of the application, such as transport security, well-defined aspect of the application, such as transport security,
user authentication, or data exchange. user authentication, or data exchange.
Each channel has an associated "profile" that defines the syntax and Each channel has an associated "profile" that defines the syntax and
semantics of the messages exchanged. Implicit in the operation of semantics of the messages exchanged. Implicit in the operation of
BEEP is the notion of channel management. In addition to defining BEEP is the notion of channel management. In addition to defining
BEEP's channel management profile, this document defines: BEEP's channel management profile, this document defines:
o the TLS[3] transport security profile; and, o the TLS[3] transport security profile; and,
o the SASL[4] family of profiles. o the SASL[4] family of profiles.
Other profiles, such as those used for data exchange, are defined by Other profiles, such as those used for data exchange, are defined by
an application protocol designer. an application protocol designer.
2. The BEEP Framework 2. The BEEP Core
A BEEP session is mapped onto an underlying transport service. A A BEEP session is mapped onto an underlying transport service. A
separate series of documents describe how a particular transport separate series of documents describe how a particular transport
service realizes a BEEP session. For example, [5] describes how a service realizes a BEEP session. For example, [5] describes how a
BEEP session is mapped onto a single TCP[6] connection. BEEP session is mapped onto a single TCP[6] connection.
When a session is established, each BEEP peer advertises the profile When a session is established, each BEEP peer advertises the profile
it supports. Later on, during the creation of a channel, the client it supports. Later on, during the creation of a channel, the client
supplies one or more proposed profiles for that channel. If the supplies one or more proposed profiles for that channel. If the
server creates the channel, it selects one of the profiles and sends server creates the channel, it selects one of the profiles and sends
skipping to change at page 6, line 5 skipping to change at page 5, line 32
initialization once the BEEP session is established (e.g., initialization once the BEEP session is established (e.g.,
negotiating the use of transport security); although several negotiating the use of transport security); although several
exchanges may be required to perform the initialization, these exchanges may be required to perform the initialization, these
channels become inactive early in the BEEP session and remain so channels become inactive early in the BEEP 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.
Note that because of their special nature, only one tuning channel
may be established at any given time; in contrast, BEEP allows
multiple data exchange channels to be simultaneously in use.
2.1 Roles 2.1 Roles
Although BEEP is peer-to-peer, it is convenient to label each peer Although BEEP is peer-to-peer, it is convenient to label each peer
in 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 BEEP session is established, the peer that awaits new o When a BEEP session is established, the peer that awaits new
connections is acting in the listening role, and the other peer, connections is acting in the listening role, and the other peer,
which establishes a connection to the listener, is acting in the which establishes a connection to the listener, is acting in the
initiating role. In the examples which follow, these are referred initiating role. In the examples which follow, these are referred
to as "L:" and "I:", respectively. to as "L:" and "I:", respectively.
skipping to change at page 20, line 40 skipping to change at page 20, line 40
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
BEEP peer's first choice is used. BEEP peer's first choice is used.
If the value of the "number" attribute is zero, then the BEEP peer If the value of the "number" attribute is zero, then the BEEP peer
wants to release the BEEP session (c.f., Section 2.4) -- otherwise wants to release the BEEP session (c.f., Section 2.4) -- otherwise
the value of the "number" attribute refers to an existing channel. the value of the "number" attribute refers to an existing channel,
and the remainder of this section applies.
When a BEEP peer receives a "close" element on channel zero, it A BEEP peer may send a "close" message for a channel whenever all
decides whether it is willing to close the channel. If so, an "ok" "MSG" messages it has sent on that channel have been acknowledged.
element is sent in a positive reply; otherwise, an "error" element (Acknowledgement consists of the first frame of a reply being
is sent in a negative reply. received by the BEEP peer that sent the MSG "message".)
For example, a successful channel close might look like this: After sending the "close" message, that BEEP peer must not send any
more "MSG" messages on that channel being closed until the reply to
the "close" message has been received (either by an "error" message
rejecting the request to close the channel, or by an "ok" message
subsequently followed by the channel being successfully started).
NOTE WELL: until a positive reply to the request to close the
channel is received, the BEEP peer must be prepared to process any
"MSG" messages that it receives on that channel.
When a BEEP peer receives a "close" message for a channel, it may,
at any time, reject the request to close the channel by sending an
"error" message in a negative reply.
Otherwise, before accepting the request to close the channel, and
sending an "ok" message in a positive reply, it must:
o finish sending any queued "MSG" messages on that channel of its
own;
o await complete replies to any outstanding "MSG" messages it has
sent on that channel; and,
o finish sending complete replies to any outstanding "MSG" messages
it has received on that channel, and ensure that the final frames
of those replies have been successfully delivered, i.e.,
* for transport mappings that guarantee inter-channel ordering
of messages, the replies must be sent prior to sending the
"ok" message in a positive reply; otherwise,
* the replies must be sent and subsequently acknowledged by the
underlying transport service prior to sending the "ok" message
in a positive reply.
Briefly, a successful channel close might look like this:
C: MSG 0 2 . 247 71 C: MSG 0 2 . 247 71
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <close number='1' code='200' /> C: <close number='1' code='200' />
C: END C: END
S: RPY 0 2 . 447 46 S: RPY 0 2 . 447 46
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <ok /> S: <ok />
skipping to change at page 53, line 22 skipping to change at page 54, line 22
1.0", W3C XML, February 1998, 1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>. <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 Core onto TCP",
draft-ietf-beep-tcpmapping-05 (work in progress), December draft-ietf-beep-tcpmapping-06 (work in progress), January 2001.
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] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [8] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
skipping to change at page 57, line 7 skipping to change at page 58, line 7
profiles and channel management features, the mailing list profiles and channel management features, the mailing list
bxxpwg@invisible.net may be used to solicit commentary. bxxpwg@invisible.net may be used to solicit commentary.
The IANA makes the registrations specified in Section 6.2 and The IANA makes the registrations specified in Section 6.2 and
Section 6.3. It is recommended that the IANA register these profiles Section 6.3. It is recommended that the IANA register these profiles
using the IANA as a URI-prefix, and populate those URIs with the using the IANA as a URI-prefix, and populate those URIs with the
respective profile registrations. respective profile registrations.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 16 change blocks. 
68 lines changed or deleted 107 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/