draft-ietf-beep-framework-09.txt   draft-ietf-beep-framework-10.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 16, 2001 December 16, 2000 Expires: June 26, 2001 December 26, 2000
The Blocks Extensible Exchange Protocol Framework The Blocks Extensible Exchange Protocol Framework
draft-ietf-beep-framework-09 draft-ietf-beep-framework-10
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 16, 2001. This Internet-Draft will expire on June 26, 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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . . 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 Message Exchange . . . . . . . . . . . . . . . . . . . . . 26 2.5.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . 26
2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 27 2.6 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . 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 Replies . . . . . . . . . . . . . . . . . . . 27 2.6.3 Pre-emptive Replies . . . . . . . . . . . . . . . . . . . 28
2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 28
2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 28 2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 29
3. Transport Security . . . . . . . . . . . . . . . . . . . . 29 3. Transport Security . . . . . . . . . . . . . . . . . . . . 30
3.1 The TLS Transport Security Profile . . . . . . . . . . . . 32 3.1 The TLS Transport Security Profile . . . . . . . . . . . . 33
3.1.1 Profile Identification and Initialization . . . . . . . . 32 3.1.1 Profile Identification and Initialization . . . . . . . . 33
3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 33 3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 34
3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 34 3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 35
3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 34 3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 35
3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 34 3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 35
4. User Authentication . . . . . . . . . . . . . . . . . . . 35 4. User Authentication . . . . . . . . . . . . . . . . . . . 36
4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 36 4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 37
4.1.1 Profile Identification and Initialization . . . . . . . . 37 4.1.1 Profile Identification and Initialization . . . . . . . . 38
4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 40 4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 41
4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 41 4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 42
5. Registration Templates . . . . . . . . . . . . . . . . . . 42 5. Registration Templates . . . . . . . . . . . . . . . . . . 43
5.1 Profile Registration Template . . . . . . . . . . . . . . 42 5.1 Profile Registration Template . . . . . . . . . . . . . . 43
5.2 Feature Registration Template . . . . . . . . . . . . . . 42 5.2 Feature Registration Template . . . . . . . . . . . . . . 43
6. Initial Registrations . . . . . . . . . . . . . . . . . . 43 6. Initial Registrations . . . . . . . . . . . . . . . . . . 44
6.1 Registration: BEEP Channel Management . . . . . . . . . . 43 6.1 Registration: BEEP Channel Management . . . . . . . . . . 44
6.2 Registration: TLS Transport Security Profile . . . . . . . 43 6.2 Registration: TLS Transport Security Profile . . . . . . . 44
6.3 Registration: SASL Family of Profiles . . . . . . . . . . 44 6.3 Registration: SASL Family of Profiles . . . . . . . . . . 45
6.4 Registration: application/beep+xml . . . . . . . . . . . . 45 6.4 Registration: application/beep+xml . . . . . . . . . . . . 46
7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 46 7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 47
7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 48 7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 49
7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 49 7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 50
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 50 8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 51
9. Security Considerations . . . . . . . . . . . . . . . . . 51 9. Security Considerations . . . . . . . . . . . . . . . . . 52
References . . . . . . . . . . . . . . . . . . . . . . . . 52 References . . . . . . . . . . . . . . . . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . 53 Author's Address . . . . . . . . . . . . . . . . . . . . . 54
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 54 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 55
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 55 B. IANA Considerations . . . . . . . . . . . . . . . . . . . 56
Full Copyright Statement . . . . . . . . . . . . . . . . . 56 Full Copyright Statement . . . . . . . . . . . . . . . . . 57
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 27, line 5 skipping to change at page 27, line 5
A BEEP session is message-oriented. A mapping document must define: A BEEP session is message-oriented. A mapping document must define:
o how messages are reliably sent and received; o how messages are reliably sent and received;
o how messages on the same channel are received in the same order o how messages on the same channel are received in the same order
as 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 Asynchrony
BEEP accomodates asynchronous interactions, both within a single
channel and between separate channels. This feature allows
pipelining (intra-channel) and parallelism (inter-channel).
2.6.1 Within a Single Channel 2.6.1 Within a Single Channel
A BEEP peer acting in the client role may send multiple "MSG" A BEEP peer acting in the client role may send multiple "MSG"
messages on the same channel without waiting to receive the messages on the same channel without waiting to receive the
corresponding replies. corresponding replies. This provides pipelining within a single
channel.
A BEEP peer acting in the server role must process all "MSG" A BEEP peer acting in the server role must process all "MSG"
messages for a given channel in the same order as they are received. messages for a given channel in the same order as they are received.
As a consequence, the BEEP peer must generate replies in the same As a consequence, the BEEP peer must generate replies in the same
order as the corresponding "MSG" messages are received on a given order as the corresponding "MSG" messages are received on a given
channel. channel.
Note that in one-to-many exchanges (c.f., Section 2.1.1), the reply
to the "MSG" message consists of zero or more "ANS" messages
followed by a "NUL" message. In this style of exchange, the "ANS"
messages comprising the reply may be interleaved. When the BEEP peer
acting in the server role signifies the end of the reply by
generating the "NUL" message, it may then process the next "MSG"
message received for that channel.
2.6.2 Between Different Channels 2.6.2 Between Different Channels
A BEEP peer acting in the client role may send multiple "MSG" A BEEP peer acting in the client role may send multiple "MSG"
messages on different channels without waiting to receive the messages on different channels without waiting to receive the
corresponding replies. corresponding replies. The channels operate independently, in
parallel.
A BEEP peer acting in the server role may process "MSG" messages A BEEP peer acting in the server role may process "MSG" messages
received on different channels in any order it chooses. As a received on different channels in any order it chooses. As a
consequence, although the replies for a given channel appear to be consequence, although the replies for a given channel appear to be
generated in the same order in which the corresponding "MSG" generated in the same order in which the corresponding "MSG"
messages are received, there is no ordering constraint for replies messages are received, there is no ordering constraint for replies
on different channels. on different channels.
2.6.3 Pre-emptive Replies 2.6.3 Pre-emptive Replies
 End of changes. 9 change blocks. 
41 lines changed or deleted 55 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/