draft-ietf-beep-framework-05.txt   draft-ietf-beep-framework-06.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 14, 2001 October 14, 2000 Expires: April 25, 2001 October 25, 2000
The Blocks Extensible Exchange Protocol Framework The Blocks Extensible Exchange Protocol Framework
draft-ietf-beep-framework-05 draft-ietf-beep-framework-06
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 14, 2001. This Internet-Draft will expire on April 25, 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 18 skipping to change at page 2, line 18
2. The BEEP Framework . . . . . . . . . . . . . . . . . . . . 5 2. The BEEP Framework . . . . . . . . . . . . . . . . . . . . 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.2.2.2 XML-based Profiles . . . . . . . . . . . . . . . . . . . . 15 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15
2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 16 2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 17 2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16
2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 17 2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 17
2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 18 2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 20
2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 21 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 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 27
2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 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
7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 46 7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 46
7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 48 7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 48
7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 49 7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 49
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 50 8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 50
9. Security Considerations . . . . . . . . . . . . . . . . . 51 9. Security Considerations . . . . . . . . . . . . . . . . . 51
References . . . . . . . . . . . . . . . . . . . . . . . . 52 References . . . . . . . . . . . . . . . . . . . . . . . . 52
Author's Address . . . . . . . . . . . . . . . . . . . . . 53 Author's Address . . . . . . . . . . . . . . . . . . . . . 53
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 54 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 54
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 55 B. IANA Considerations . . . . . . . . . . . . . . . . . . . 55
skipping to change at page 7, line 29 skipping to change at page 7, line 29
Each frame consists of a header, the payload, and a trailer. The Each frame consists of a header, the payload, and a trailer. The
header and trailer are each represented using printable ASCII header and trailer are each represented using printable ASCII
characters and are terminated with a CRLF pair. Between the header characters and are terminated with a CRLF pair. Between the header
and the trailer is the payload, consisting of zero or more octets. and the trailer is the payload, consisting of zero or more octets.
For example, here is a message contained in a single frame that For example, here is a message contained in a single frame that
contains a payload of 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 . 52 132
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start> C: </start>
C: END C: END
In this example, note that the entire message is represented in a In this example, note that the entire message is represented in a
single frame. single frame.
2.2.1 Frame Syntax 2.2.1 Frame Syntax
skipping to change at page 12, line 20 skipping to change at page 12, line 20
associated sequence number. Numbering of payload octets within a associated sequence number. Numbering of payload octets within a
frame is such that the first payload octet is the lowest numbered, frame is such that the first payload octet is the lowest numbered,
and the following payload octets are numbered consecutively. (When a and the following payload octets are numbered consecutively. (When a
channel is created, the sequence number associated with the first channel is created, the sequence number associated with the first
payload octet of the first frame is 0.) payload octet of the first frame is 0.)
The actual sequence number space is finite, though very large, The actual sequence number space is finite, though very large,
ranging from 0..4294967295 (2**32 - 1). Since the space is finite, ranging from 0..4294967295 (2**32 - 1). Since the space is finite,
all arithmetic dealing with sequence numbers is performed modulo all arithmetic dealing with sequence numbers is performed modulo
2**32. This unsigned arithmetic preserves the relationship of 2**32. This unsigned arithmetic preserves the relationship of
sequence numbers as they cycle from 2**32 - 1 to 0 again. sequence numbers as they cycle from 2**32 - 1 to 0 again. Consult
Sections 2 through 5 of [8] for a discussion of the arithmetic
properties of sequence numbers.
When receiving a frame, the sum of its sequence number and payload When receiving a frame, the sum of its sequence number and payload
size, modulo 4294967296 (2**32), gives the expected sequence number size, modulo 4294967296 (2**32), gives the expected sequence number
associated with the first payload octet of the next frame received. associated with the first payload octet of the next frame received.
Accordingly, when receiving a frame if the sequence number isn't the Accordingly, when receiving a frame if the sequence number isn't the
expected value for this channel, then the BEEP peers have lost expected value for this channel, then the BEEP peers have lost
synchronization, then the session is terminated without generating a synchronization, then the session is terminated without generating a
response, and it is recommended that a diagnostic entry be logged. response, and it is recommended that a diagnostic entry be logged.
2.2.1.3 Frame Trailer 2.2.1.3 Frame Trailer
skipping to change at page 15, line 5 skipping to change at page 15, line 5
channel management profile sends a negative reply containing an channel management profile sends a negative reply containing an
error message (c.f., Section 2.3.1.5). error message (c.f., Section 2.3.1.5).
If a poorly-formed reply is received on channel zero, the session is If a poorly-formed reply is received on channel zero, the session is
terminated without generating a response, and it is recommended that terminated without generating a response, and it is recommended that
a diagnostic entry be logged. a diagnostic entry be logged.
If a poorly-formed reply is received on another channel, then the If a poorly-formed reply is received on another channel, then the
channel must be closed using the procedure in Section 2.3.1.3. channel must be closed using the procedure in Section 2.3.1.3.
2.2.2.2 XML-based Profiles
If a profile uses XML[2] to structure its messages, then only XML's
baseline facilities (as described in the XML 1.0 specification[2])
are allowed. Additional XML facilities (e.g., namespaces) are made
available only by being explicitly permitted in a given profile's
specification.
In particular this limitation allows use of only the five predefined
general entities references ("&amp;", "&lt;", "&gt;", "&apos;", and
"&quot;") and numeric entity references in the messages exchanged.
Further, because the profile registration template defines the
messages exchanged over a channel, the XML documents exchanged in
each message needn't have either a "XML" declaration (e.g., <?xml
version="1.0" ?>) or a "DOCTYPE" declaration (e.g., <!DOCTYPE ...>).
All other XML 1.0 instructions (e.g., CDATA blocks, processing
instructions, and so on) are allowed.
Finally, because the "XML" declaration isn't present, the default
character set for XML-based profiles is UTF-8. If another character
set is desired, the "Content-Type" entity-header must indicate this.
2.3 Channel Management 2.3 Channel Management
When a BEEP session starts, only channel number zero is defined, When a BEEP session starts, only channel number zero is defined,
which is used for channel management. Section 6.1 contains the which is used for channel management. Section 6.1 contains the
profile registration for BEEP channel management. profile registration for BEEP channel management.
Channel management allows each BEEP peer to advertise the profiles Channel management allows each BEEP peer to advertise the profiles
that it supports (c.f., Section 2.3.1.1), bind an instance of one of that it supports (c.f., Section 2.3.1.1), bind an instance of one of
those profiles to a channel (c.f., Section 2.3.1.2), and then later those profiles to a channel (c.f., Section 2.3.1.2), and then later
close any channels or release the BEEP session (c.f., Section close any channels or release the BEEP session (c.f., Section
skipping to change at page 17, line 15 skipping to change at page 16, line 15
2.3.1 Message Semantics 2.3.1 Message Semantics
2.3.1.1 The Greeting Message 2.3.1.1 The Greeting Message
When a BEEP session is established, each BEEP peer signifies its When a BEEP session is established, each BEEP peer signifies its
availability by immediately sending a positive reply with a message availability by immediately sending a positive reply with a message
number of zero that contains a "greeting" element, e.g., number of zero that contains a "greeting" element, e.g.,
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 110 L: RPY 0 0 . 0 122
L: Content-Type: text/xml L: Content-Type: application/beep+xml
L: L:
L: <greeting> L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' /> L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 52
I: Content-Type: text/xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
Note that this example implies that the BEEP peer in the initiating Note that this example implies that the BEEP peer in the initiating
role waits until the BEEP peer in the listening role sends its role waits until the BEEP peer in the listening role sends its
greeting -- this is an artifact of the presentation; in fact, both greeting -- this is an artifact of the presentation; in fact, both
BEEP peers send their replies independently. BEEP peers send their replies independently.
The "greeting" element has two optional attributes ("features" and The "greeting" element has two optional attributes ("features" and
"localize") and zero or more "profile" elements, one for each "localize") and zero or more "profile" elements, one for each
profile supported by the BEEP peer acting in a server role: profile supported by the BEEP peer acting in a server role:
o the "features" attribute, if present, contains one or more o the "features" attribute, if present, contains one or more
feature tokens, each indicating an optional feature of the feature tokens, each indicating an optional feature of the
channel management profile supported by the BEEP peer; channel management profile supported by the BEEP peer;
o the "localize" attribute, if present, contains one or more o the "localize" attribute, if present, contains one or more
language tokens (defined in [8]), each identifying a desirable language tokens (defined in [9]), each identifying a desirable
language tag to be used by the remote BEEP peer when generating language tag to be used by the remote BEEP peer when generating
textual diagnostics for the "close" and "error" elements (the textual diagnostics for the "close" and "error" elements (the
tokens are ordered from most to least desirable); and, tokens are ordered from most to least desirable); and,
o each "profile" element contained within the "greeting" element o each "profile" element contained within the "greeting" element
identifies a profile, and unlike the "profile" elements that identifies a profile, and unlike the "profile" elements that
occur 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.
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 . 52 132
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start> C: </start>
C: END C: END
The "start" element has a "number" attribute, an optional The "start" element has a "number" attribute, an optional
"serverName" attribute, and one or more "profile" elements: "serverName" attribute, and one or more "profile" elements:
o the "number" attribute indicates the channel number (in the range o the "number" attribute indicates the channel number (in the range
skipping to change at page 19, line 18 skipping to change at page 18, line 18
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.
When creating the channel, the value of the "serverName" attribute When creating the channel, the value of the "serverName" attribute
from the first successful "start" element is consulted to provide from the first successful "start" element is consulted to provide
configuration information, e.g., the desired server-side certificate configuration information, e.g., the desired server-side certificate
when starting the TLS transport security profile (Section 3.1). when starting the TLS transport security profile (Section 3.1).
For example, a successful channel creation might look like this: For example, a successful channel creation might look like this:
C: MSG 0 1 . 40 197 C: MSG 0 1 . 52 209
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://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
S: RPY 0 1 . 252 87 S: RPY 0 1 . 264 99
S: Content-Type: text/xml S: Content-Type: application/beep+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
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 . 52 132
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <start number='2'> C: <start number='2'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start> C: </start>
C: END C: END
S: ERR 0 1 . 252 115 S: ERR 0 1 . 264 127
S: Content-Type: text/xml S: Content-Type: application/beep+xml
S: S:
S: <error code='501'>number attribute S: <error code='501'>number attribute
S: in &lt;start&gt; element must be odd-valued</error> S: in &lt;start&gt; element must be odd-valued</error>
S: END S: END
Finally, here's an example in which an initialization element is Finally, here's an example in which an initialization element is
exchanged during channel creation: exchanged during channel creation:
C: MSG 0 1 . 40 158 C: MSG 0 1 . 52 170
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'> C: <profile uri='http://xml.resource.org/profiles/TLS'>
C: <![CDATA[<ready />]]> C: <![CDATA[<ready />]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RPY 0 1 . 110 121 S: RPY 0 1 . 122 133
S: Content-Type: text/xml S: Content-Type: application/beep+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
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 . 247 71
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <close number='1' code='200' /> C: <close number='1' code='200' />
C: END C: END
The "close" element has a "number" attribute, a "code" attribute, an The "close" element has a "number" attribute, a "code" attribute, an
optional "xml:lang" attribute, and an optional textual diagnostic as optional "xml:lang" attribute, and an optional textual diagnostic as
its content: its content:
o the "number" attribute indicates the channel number; o the "number" attribute indicates the channel number;
skipping to change at page 22, line 7 skipping to change at page 21, line 7
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.
When a BEEP peer receives a "close" element on channel zero, it When a BEEP 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 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 . 247 71
C: Content-Type: text/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 . 423 34 S: RPY 0 2 . 447 46
S: Content-Type: text/xml S: Content-Type: application/beep+xml
S: S:
S: <ok /> S: <ok />
S: END S: END
Similarly, an unsuccessful channel close might look like this: Similarly, an unsuccessful channel close might look like this:
C: MSG 0 2 . 223 59 C: MSG 0 2 . 247 71
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <close number='1' code='200' /> C: <close number='1' code='200' />
C: END C: END
S: ERR 0 2 . 423 67 S: ERR 0 2 . 447 79
S: Content-Type: text/xml S: Content-Type: application/beep+xml
S: S:
S: <error code='550'>still working</error> S: <error code='550'>still working</error>
S: END S: END
2.3.1.4 The OK Message 2.3.1.4 The OK Message
When a BEEP peer agrees to close a channel (or release the BEEP When a BEEP peer agrees to close a channel (or release the BEEP
session), it sends an "ok" element in a positive reply. session), it sends an "ok" element in a positive reply.
The "ok" element has no attributes and no content. The "ok" element has no attributes and no content.
2.3.1.5 The Error Message 2.3.1.5 The Error Message
When a BEEP peer declines the creation of a channel, it sends an When a BEEP peer declines the creation of a channel, it sends an
"error" element in a negative reply, e.g., "error" element in a negative reply, e.g.,
I: MSG 0 1 . 40 115 I: MSG 0 1 . 52 127
I: Content-Type: text/xml I: Content-Type: application/beep+xml
I: I:
I: <start number='2'> I: <start number='2'>
I: <profile uri='http://xml.resource.org/profiles/FOO' /> I: <profile uri='http://xml.resource.org/profiles/FOO' />
I: </start> I: </start>
I: END I: END
L: ERR 0 1 . 252 93 L: ERR 0 1 . 264 105
L: Content-Type: text/xml L: Content-Type: application/beep+xml
L: L:
L: <error code='550'>all requested profiles are L: <error code='550'>all requested profiles are
L: unsupported</error> L: unsupported</error>
L: END L: END
The "error" element has a "code" attribute, an optional "xml:lang" The "error" element has a "code" attribute, an optional "xml:lang"
attribute, and an optional textual diagnostic as its content: attribute, and an optional textual diagnostic as its content:
o the "code" attribute is a three-digit reply code meaningful to o the "code" attribute is a three-digit reply code meaningful to
programs (c.f., Section 8); programs (c.f., Section 8);
skipping to change at page 25, line 14 skipping to change at page 24, line 14
2.4 Session Establishment and Release 2.4 Session Establishment and Release
When a BEEP session is established, each BEEP peer signifies its When a BEEP session is established, each BEEP peer signifies its
availability by immediately sending a positive reply with a message availability by immediately sending a positive reply with a message
number of zero on channel zero that contains a "greeting" element, number of zero on channel zero that contains a "greeting" element,
e.g., e.g.,
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 110 L: RPY 0 0 . 0 122
L: Content-Type: text/xml L: Content-Type: application/beep+xml
L: L:
L: <greeting> L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' /> L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 52
I: Content-Type: text/xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
Alternatively, if the BEEP peer acting in the listening role is Alternatively, if the BEEP peer acting in the listening role is
unavailable, it sends a negative reply, e.g., unavailable, it sends a negative reply, e.g.,
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 60
L: Content-Type: text/xml L: Content-Type: application/beep+xml
L: L:
L: <error code='421' /> L: <error code='421' />
L: END L: END
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 52
I: Content-Type: text/xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I: <close connection> I: <close connection>
L: <close connection> L: <close connection>
L: <wait for next connection> L: <wait for next connection>
and the "greeting" element sent by the BEEP peer acting in the and the "greeting" element sent by the BEEP peer acting in the
initiating role is ignored. It is recommended that a diagnostic initiating role is ignored. It is recommended that a diagnostic
entry be logged by both BEEP peers. entry be logged by both BEEP peers.
skipping to change at page 26, line 10 skipping to change at page 25, line 10
Note that both of these examples imply that the BEEP peer in the Note that both of these examples imply that the BEEP peer in the
initiating role waits until the BEEP peer in the listening role initiating role waits until the BEEP peer in the listening role
sends its greeting -- this is an artifact of the presentation; in sends its greeting -- this is an artifact of the presentation; in
fact, both BEEP peers send their replies independently. fact, both BEEP peers send their replies independently.
When a BEEP peer wants to release the BEEP session, it sends a When a BEEP peer wants to release the BEEP session, it sends a
"close" element with a zero-valued "number" attribute on channel "close" element with a zero-valued "number" attribute on channel
zero. The other BEEP peer indicates its willingness by sending an zero. The other BEEP peer indicates its willingness by sending an
"ok" element in a positive reply, e.g., "ok" element in a positive reply, e.g.,
C: MSG 0 1 . 40 48 C: MSG 0 1 . 52 60
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <close code='200' /> C: <close code='200' />
C: END C: END
S: RPY 0 1 . 252 34 S: RPY 0 1 . 264 46
S: Content-Type: text/xml S: Content-Type: application/beep+xml
S: S:
S: <ok /> S: <ok />
S: END S: END
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 . 52 60
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <close code='200' /> C: <close code='200' />
C: END C: END
S: ERR 0 1 . 252 67 S: ERR 0 1 . 264 79
S: Content-Type: text/xml S: Content-Type: application/beep+xml
S: S:
S: <error code='550'>still working</error> S: <error code='550'>still working</error>
S: END S: END
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
skipping to change at page 29, line 22 skipping to change at page 28, line 22
unexpected "MSG" messages. unexpected "MSG" messages.
As a consequence of the peer-to-peer nature of BEEP, message numbers As a consequence of the peer-to-peer nature of BEEP, message numbers
are unidirectionally-significant. That is, the message numbers in are unidirectionally-significant. That is, the message numbers in
"MSG" messages sent by a BEEP peer acting in the initiating role are "MSG" messages sent by a BEEP peer acting in the initiating role are
unrelated to the message numbers in "MSG" messages sent by a BEEP unrelated to the message numbers in "MSG" messages sent by a BEEP
peer acting in the listening role. peer acting in the listening role.
For example, these two messages For example, these two messages
I: MSG 0 1 . 40 120 I: MSG 0 1 . 52 132
I: Content-Type: text/xml I: Content-Type: application/beep+xml
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
I: </start> I: </start>
I: END I: END
L: MSG 0 1 . 252 116 L: MSG 0 1 . 264 128
L: Content-Type: text/xml L: Content-Type: application/beep+xml
L: L:
L: <start number='2'> L: <start number='2'>
L: <profile uri='http://xml.resource.org/profiles/IMXP' /> L: <profile uri='http://xml.resource.org/profiles/IMXP' />
L: </start> L: </start>
L: END L: END
refer to different messages sent on channel zero. refer to different messages sent on channel zero.
3. Transport Security 3. Transport Security
skipping to change at page 30, line 33 skipping to change at page 29, line 33
of the negotiation process, regardless of its outcome, a new of the negotiation process, regardless of its outcome, a new
greeting is issued by both BEEP peers. (If the negotiation process greeting is issued by both BEEP peers. (If the negotiation process
fails, then either BEEP peer may instead terminate the session, and fails, then either BEEP peer may instead terminate the session, and
it is recommended that a diagnostic entry be logged.) it is recommended that a diagnostic entry be logged.)
A BEEP peer may choose to issue different greetings based on whether A BEEP peer may choose to issue different greetings based on whether
privacy is in use, e.g., privacy is in use, e.g.,
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 110 L: RPY 0 0 . 0 122
L: Content-Type: text/xml L: Content-Type: application/beep+xml
L: L:
L: <greeting> L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' /> L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting> L: </greeting>
L: END L: END
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 52
I: Content-Type: text/xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I: MSG 0 1 . 40 158 I: MSG 0 1 . 52 170
I: Content-Type: text/xml I: Content-Type: application/beep+xml
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/TLS'> I: <profile uri='http://xml.resource.org/profiles/TLS'>
I: <![CDATA[<ready />]]> I: <![CDATA[<ready />]]>
I: </profile> I: </profile>
I: </start> I: </start>
I: END I: END
L: RPY 0 1 . 110 121 L: RPY 0 1 . 122 133
L: Content-Type: text/xml L: Content-Type: application/beep+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
... successful transport security negotiation ... ... successful transport security negotiation ...
L: RPY 0 0 . 0 252 L: RPY 0 0 . 0 264
L: Content-Type: text/xml L: Content-Type: application/beep+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
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 52
I: Content-Type: text/xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
Of course, not all BEEP peers need be as single-minded: Of course, not all BEEP peers need be as single-minded:
L: <wait for incoming connection> L: <wait for incoming connection>
I: <open connection> I: <open connection>
L: RPY 0 0 . 0 311 L: RPY 0 0 . 0 323
L: Content-Type: text/xml L: Content-Type: application/beep+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
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 52
I: Content-Type: text/xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
I: MSG 0 1 . 40 158 I: MSG 0 1 . 52 170
I: Content-Type: text/xml I: Content-Type: application/beep+xml
I: I:
I: <start number='1'> I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/TLS'> I: <profile uri='http://xml.resource.org/profiles/TLS'>
I: <![CDATA[<ready />]]> I: <![CDATA[<ready />]]>
I: </profile> I: </profile>
I: </start> I: </start>
I: END I: END
L: RPY 0 1 . 311 121 L: RPY 0 1 . 323 133
L: Content-Type: text/xml L: Content-Type: application/beep+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
... failed transport security negotiation ... ... failed transport security negotiation ...
L: RPY 0 0 . 0 311 L: RPY 0 0 . 0 323
L: Content-Type: text/xml L: Content-Type: application/beep+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
I: RPY 0 0 . 0 40 I: RPY 0 0 . 0 52
I: Content-Type: text/xml I: Content-Type: application/beep+xml
I: I:
I: <greeting /> I: <greeting />
I: END I: END
3.1 The TLS Transport Security Profile 3.1 The TLS Transport Security Profile
Section 6.2 contains the registration for this profile. Section 6.2 contains the registration for this profile.
3.1.1 Profile Identification and Initialization 3.1.1 Profile Identification and Initialization
skipping to change at page 33, line 23 skipping to change at page 32, line 23
http://xml.resource.org/profiles/TLS http://xml.resource.org/profiles/TLS
in the BEEP "profile" element during channel creation. in the BEEP "profile" element during channel creation.
During channel creation, the corresponding "profile" element in the During channel creation, the corresponding "profile" element in the
BEEP "start" element may contain a "ready" element. If channel BEEP "start" element may contain a "ready" element. If channel
creation is successful, then before sending the corresponding reply, creation is successful, then before sending the corresponding reply,
the BEEP peer processes the "ready" element and includes the the BEEP peer processes the "ready" element and includes the
resulting response in the reply, e.g., resulting response in the reply, e.g.,
C: MSG 0 1 . 40 158 C: MSG 0 1 . 52 170
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'> C: <profile uri='http://xml.resource.org/profiles/TLS'>
C: <![CDATA[<ready />]]> C: <![CDATA[<ready />]]>
C: </profile> C: </profile>
C: </start> C: </start>
C: END C: END
S: RPY 0 1 . 110 121 S: RPY 0 1 . 122 133
S: Content-Type: text/xml S: Content-Type: application/beep+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
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 . 52 185
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'> C: <profile uri='http://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
S: RPY 0 1 . 110 193 S: RPY 0 1 . 122 205
S: Content-Type: text/xml S: Content-Type: application/beep+xml
S: S:
S: <profile uri='http://xml.resource.org/profiles/TLS'> S: <profile uri='http://xml.resource.org/profiles/TLS'>
S: <![CDATA[<error code='501'>version attribute S: <![CDATA[<error code='501'>version attribute
S: poorly formed in &lt;ready&gt; element</error>]]> S: poorly formed in &lt;ready&gt; element</error>]]>
S: </profile> S: </profile>
S: END S: END
In this case, a positive reply is sent (as channel creation In this case, a positive reply is sent (as channel creation
succeeded), but the encapsulated response contains an indication as succeeded), but the encapsulated response contains an indication as
to why the operation failed. to why the operation failed.
skipping to change at page 36, line 13 skipping to change at page 35, line 13
transport security. transport security.
4. User Authentication 4. User Authentication
When a BEEP session is established, anonymous access, without trace When a BEEP session is established, anonymous access, without trace
information, is provided. Accordingly, user authentication in BEEP information, is provided. Accordingly, user authentication in BEEP
is achieved using an initial tuning profile. is achieved using an initial tuning profile.
This document defines a family of profiles based on SASL mechanisms: This document defines a family of profiles based on SASL mechanisms:
o each mechanism in the IANA SASL registry[13] has an associated o each mechanism in the IANA SASL registry[15] has an associated
profile. profile.
Other profiles may be defined and deployed on a bilateral basis. Other profiles may be defined and deployed on a bilateral basis.
Whenever a successful authentication occurs, on any channel, the Whenever a successful authentication occurs, on any channel, the
authenticated identity is updated for all existing and future authenticated identity is updated for all existing and future
channels on the BEEP session; further, no additional attempts at channels on the BEEP session; further, no additional attempts at
authentication are allowed. authentication are allowed.
Note that regardless of transport security and user authentication, Note that regardless of transport security and user authentication,
skipping to change at page 38, line 17 skipping to change at page 37, line 17
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 BEEP peer may provide multiple Note that during channel creation, a BEEP peer may provide multiple
profiles to the remote peer, e.g., profiles to the remote peer, e.g.,
C: MSG 0 1 . 40 197 C: MSG 0 1 . 52 209
C: Content-Type: text/xml C: Content-Type: application/beep+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
S: RPY 0 1 . 252 87 S: RPY 0 1 . 264 99
S: Content-Type: text/xml S: Content-Type: application/beep+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
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 . 52 195
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> C: <profile uri='http://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
S: RPY 0 1 . 252 178 S: RPY 0 1 . 264 190
S: Content-Type: text/xml S: Content-Type: application/beep+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[<error code='534'>authentication mechanism is S: <![CDATA[<error code='534'>authentication mechanism is
S: too weak</error>]]> S: too weak</error>]]>
S: </profile> S: </profile>
S: END S: END
In this case, a positive reply is sent (as channel creation In this case, a positive reply is sent (as channel creation
succeeded), but the encapsulated response contains an indication as succeeded), but the encapsulated response contains an indication as
to why the operation failed. to why the operation failed.
Otherwise, the server sends a challenge (or signifies success), e.g., Otherwise, the server sends a challenge (or signifies success), e.g.,
C: MSG 0 1 . 40 183 C: MSG 0 1 . 52 195
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'> C: <profile uri='http://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
S: RPY 0 1 . 252 171 S: RPY 0 1 . 264 183
S: Content-Type: text/xml S: Content-Type: application/beep+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
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 97
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob> C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END C: END
S: RPY 1 0 . 0 54 S: RPY 1 0 . 0 66
S: Content-Type: text/xml S: Content-Type: application/beep+xml
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: MSG 1 0 . 0 85 C: MSG 1 0 . 0 97
C: Content-Type: text/xml C: Content-Type: application/beep+xml
C: C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob> C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END C: END
S: ERR 1 1 . 0 48 S: ERR 1 1 . 0 60
S: Content-Type: text/xml S: Content-Type: application/beep+xml
S: S:
S: <error code='535' /> S: <error code='535' />
S: END S: END
Finally, depending on the SASL mechanism, an initialization element Finally, depending on the SASL mechanism, an initialization element
may be exchanged unidirectionally during channel creation, e.g., may be exchanged unidirectionally during channel creation, e.g.,
C: MSG 0 1 . 40 133 C: MSG 0 1 . 52 145
C: Content-Type: text/xml C: Content-Type: application/beep+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
S: RPY 0 1 . 252 185 S: RPY 0 1 . 264 197
S: Content-Type: text/xml S: Content-Type: application/beep+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: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1 S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
jaS5uZXQ+</blob>]]> jaS5uZXQ+</blob>]]>
S: </profile> S: </profile>
S: END S: END
Note that this example implies that the "blob" element in the Note that this example implies that the "blob" element in the
server's reply appears on two lines -- this is an artifact of the server's reply appears on two lines -- this is an artifact of the
presentation; in fact, only one line is used. presentation; in fact, only one line is used.
skipping to change at page 42, line 27 skipping to change at page 41, line 27
continue: used by either a client or server, otherwise. continue: used by either a client or server, otherwise.
Finally, note that SASL's EXTERNAL mechanism works with an "external Finally, note that SASL's EXTERNAL mechanism works with an "external
authentication" service, which is provided by one of: authentication" service, which is provided by one of:
o a transport security profile, capable of providing authentication o a transport security profile, capable of providing authentication
information (e.g., Section 3.1), being active on the connection; information (e.g., Section 3.1), being active on the connection;
o a network service, capable of providing strong authentication o a network service, capable of providing strong authentication
(e.g., IPSec[11]), underlying the connection; or, (e.g., IPSec[12]), underlying the connection; or,
o a locally-defined security service. o a locally-defined security service.
For authentication to succeed, two conditions must hold: For authentication to succeed, two conditions must hold:
o an external authentication service must be active; and, o an external authentication service must be active; and,
o if present, the authentication identity must be consistent with o if present, the authentication identity must be consistent with
the credentials provided by the external authentication service the credentials provided by the external authentication service
(if the authentication identity is empty, then an authorization (if the authentication identity is empty, then an authorization
identity is automatically derived from the credentials provided identity is automatically derived from the credentials provided
by the external authentication service). by the external authentication service).
5. Registration Templates 5. Registration Templates
5.1 Profile Registration Template 5.1 Profile Registration Template
When a profile is registered, the following information is supplied: When a profile is registered, the following information is supplied:
Profile Identification: specify a URI[9] that authoritatively Profile Identification: specify a URI[10] that authoritatively
identifies this profile. identifies this profile.
Message Exchanged during Channel Creation: specify the datatypes Message Exchanged during Channel Creation: specify the datatypes
that may be exchanged during channel creation. that may be exchanged during channel creation.
Messages starting one-to-one exchanges: specify the datatypes that Messages starting one-to-one exchanges: specify the datatypes that
may be present when an exchange starts. may be present when an exchange starts.
Messages in positive replies: specify the datatypes that may be Messages in positive replies: specify the datatypes that may be
present in a positive reply. present in a positive reply.
skipping to change at page 45, line 9 skipping to change at page 44, line 9
Message Semantics: c.f., Section 3.1.3 Message Semantics: c.f., Section 3.1.3
Contact Information: c.f., the "Author's Address" section of this Contact Information: c.f., the "Author's Address" section of this
memo memo
6.3 Registration: SASL Family of Profiles 6.3 Registration: SASL Family of Profiles
Profile Identification: Profile Identification:
http://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[16]
Messages exchanged during Channel Creation: "blob" Messages exchanged during Channel Creation: "blob"
Messages starting one-to-one exchanges: "blob" Messages starting one-to-one exchanges: "blob"
Messages in positive replies: "blob" Messages in positive replies: "blob"
Messages in negative replies: "error" Messages in negative replies: "error"
Messages in one-to-many exchanges: none Messages in one-to-many exchanges: none
Message Syntax: c.f., Section 7.3 Message Syntax: c.f., Section 7.3
Message Semantics: c.f., Section 4.1.3 Message Semantics: c.f., Section 4.1.3
Contact Information: c.f., the "Author's Address" section of this Contact Information: c.f., the "Author's Address" section of this
memo memo
6.4 Registration: application/beep+xml
MIME media type name: application
MIME subtype name: beep+xml
Required parameters: none
Optional parameters: charset (defaults to "UTF-8"[13])
Encoding considerations: This media type may contain binary content;
accordingly, when used over a transport that does not permit
binary transfer, an appropriate encoding must be applied
Security considerations: none, per se; however, any BEEP profile
which uses this media type must describe its relevant security
considerations
Interoperability considerations: n/a
Published specification: This media type is a proper subset of the
the XML 1.0 specification[2]. Two restrictions are made.
First, no entity references other than the five predefined
general entities references ("&amp;", "&lt;", "&gt;", "&apos;",
and "&quot;") and numeric entity references may be present.
Second, neither the "XML" declaration (e.g., <?xml version="1.0"
?>) nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) may be
present. (Accordingly, if another character set other than UTF-8
is desired, then the "charset" parameter must be present.)
All other XML 1.0 instructions (e.g., CDATA blocks, processing
instructions, and so on) are allowed.
Applications which use this media type: any BEEP profile wishing to
make use of this XML 1.0 subset
Additional Information: none
Contact for further information: c.f., the "Author's Address"
section of this memo
Intended usage: limited use
Author/Change controller: the IESG
7. DTDs 7. DTDs
7.1 BEEP Channel Management DTD 7.1 BEEP Channel Management DTD
<!-- <!--
DTD for BEEP Channel Management, as of 2000-09-17 DTD for BEEP Channel Management, as of 2000-09-17
Refer to this DTD as: Refer to this DTD as:
<!ENTITY % BEEP PUBLIC "-//Blocks//DTD BEEP//EN" <!ENTITY % BEEP PUBLIC "-//Blocks//DTD BEEP//EN"
skipping to change at page 47, line 5 skipping to change at page 47, line 5
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">
<!-- <!--
BEEP messages BEEP messages, exchanged as application/beep+xml
role MSG RSP ERR role MSG RSP ERR
======= === === === ======= === === ===
I and L greeting error I and L greeting error
I or L start profile error I or L start profile error
I or L close ok error I or L close ok error
--> -->
skipping to change at page 48, line 18 skipping to change at page 48, line 18
DTD for the TLS Transport Security Profile, as of 2000-09-04 DTD for the TLS Transport Security Profile, as of 2000-09-04
Refer to this DTD as: Refer to this DTD as:
<!ENTITY % TLS PUBLIC "-//Blocks//DTD TLS//EN" <!ENTITY % TLS PUBLIC "-//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, exchanged as application/beep+xml
role MSG RSP ERR role MSG RSP ERR
====== === === === ====== === === ===
I or L ready proceed error I or L ready proceed error
--> -->
<!ELEMENT ready EMPTY> <!ELEMENT ready EMPTY>
<!ATTLIST ready <!ATTLIST ready
version CDATA "1"> version CDATA "1">
skipping to change at page 49, line 18 skipping to change at page 49, line 18
DTD for the SASL Family of Profiles, as of 2000-09-04 DTD for the SASL Family of Profiles, as of 2000-09-04
Refer to this DTD as: Refer to this DTD as:
<!ENTITY % SASL PUBLIC "-//Blocks//DTD SASL//EN" <!ENTITY % SASL PUBLIC "-//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, exchanged as application/beep+xml
role MSG RSP ERR role MSG RSP ERR
====== === === === ====== === === ===
I or L blob blob error I or L blob blob error
--> -->
<!ELEMENT blob (#PCDATA)> <!ELEMENT blob (#PCDATA)>
<!ATTLIST blob <!ATTLIST blob
xml:space (default|preserve) xml:space (default|preserve)
"preserve" "preserve"
skipping to change at page 52, line 13 skipping to change at page 52, line 13
associated with the BEEP session. associated with the BEEP session.
References References
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[2] World Wide Web Consortium, "Extensible Markup Language (XML) [2] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, 1.0", W3C XML, February 1998,
<URL: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 Framework onto TCP",
draft-ietf-beep-tcpmapping-04 (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] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[9] 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 [10] 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.
[10] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, [11] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
October 1998. October 1998.
[11] Kent, S. and R. Atkinson, "Security Architecture for the [12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[12] Linn, J., "Generic Security Service Application Program [13] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
Interface, Version 2", RFC 2078, January 1997. RFC 2279, January 1998.
[13] <URL:http://www.isi.edu/in-notes/iana/assignments/sasl-mechanis
ms>
[14] <URL:http://www.iana.org/> [14] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997.
[15] <http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms>
[16] <http://www.iana.org/>
Author's Address Author's Address
Marshall T. Rose Marshall T. Rose
Invisible Worlds, Inc. Invisible Worlds, Inc.
1179 North McDowell Boulevard 1179 North McDowell Boulevard
Petaluma, CA 94954-6559 Petaluma, CA 94954-6559
US US
Phone: +1 707 789 3700 Phone: +1 707 789 3700
EMail: mrose@invisible.net EMail: mrose@invisible.net
URI: http://invisible.net/ URI: http://invisible.net/
Appendix A. Acknowledgements Appendix A. Acknowledgements
The author gratefully acknowledges the contributions of: David The author gratefully acknowledges the contributions of: David
Clark, Dave Crocker, Steve Deering, Wesley Michael Eddy, Marco Clark, Dave Crocker, Steve Deering, Wesley Michael Eddy, Huston
Gazzetta, Danny Goodman, Steve Harris, Robert Herriot, Ken Hirsch, Franklin, Marco Gazzetta, Danny Goodman, Steve Harris, Robert
Greg Hudson, Ben Laurie, Carl Malamud, Michael Mealling, Keith Herriot, Ken Hirsch, Greg Hudson, Ben Laurie, Carl Malamud, Michael
McCloghrie, Paul Mockapetris, RL 'Bob' Morgan, Frank Morton, Darren Mealling, Keith McCloghrie, Paul Mockapetris, RL 'Bob' Morgan, Frank
New, Chris Newman, Joe Touch, Paul Vixie, Gabe Wachob, Daniel Woods, Morton, Darren New, Chris Newman, Joe Touch, Paul Vixie, Gabe
and, James Woodyatt. In particular, Dave Crocker provided helpful Wachob, Daniel Woods, and, James Woodyatt. In particular, Dave
suggestions on the nature of segmentation in the framing mechanism. Crocker provided helpful suggestions on the nature of segmentation
in the framing mechanism.
Appendix B. IANA Considerations Appendix B. IANA Considerations
The IANA registers "beep" as a GSSAPI[12] service name, as specified The IANA registers "beep" as a GSSAPI[14] service name, as specified
in Section 4.1. in Section 4.1.
The IANA maintains a list of: The IANA maintains a list of:
o BEEP profiles, c.f., Section 5.1; and, o BEEP profiles, c.f., Section 5.1; and,
o features for the channel management profile, c.f., Section 5.2. o features for the channel management profile, c.f., Section 5.2.
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
 End of changes. 80 change blocks. 
201 lines changed or deleted 231 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/