[BXXPwg] html versions of new I-Ds...

Marshall Rose mrose+mtr.netnews@dbc.mtview.ca.us
Mon, 11 Sep 2000 23:46:07 -0700


This is a multi-part message in MIME format.

------=_NextPart_000_007A_01C01C4A.74CFB1A0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_007B_01C01C4A.74CFB1A0"


------=_NextPart_001_007B_01C01C4A.74CFB1A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit



------=_NextPart_001_007B_01C01C4A.74CFB1A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4207.2601" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_007B_01C01C4A.74CFB1A0--

------=_NextPart_000_007A_01C01C4A.74CFB1A0
Content-Type: text/html;
	name="draft-ietf-beep-tcpmapping.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-beep-tcpmapping.html"

<html><head><title>Mapping the BXXP Framework onto TCP</title>
<STYLE type=3D'text/css'>
    .title { color: #990000; font-size: 22px; line-height: 22px; =
font-weight: bold; text-align: right;
             font-family: helvetica, arial, sans-serif }
    .filename { color: #666666; font-size: 18px; line-height: 28px; =
font-weight: bold; text-align: right;
                  font-family: helvetica, arial, sans-serif }
    p.copyright { color: #000000; font-size: 10px;
                  font-family: verdana, charcoal, helvetica, arial, =
sans-serif }
    p { margin-left: 2em; margin-right: 2em; }
    ol { margin-left: 2em; margin-right: 2em; }
    ul.text { margin-left: 2em; margin-right: 2em; }
    pre { margin-left: 3em; color: #333333 }
    ul.toc { color: #000000; line-height: 16px;
             font-family: verdana, charcoal, helvetica, arial, =
sans-serif }
    H3 { color: #333333; font-size: 16px; line-height: 16px; =
font-family: helvetica, arial, sans-serif }
    H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, =
sans-serif }
    TD.header { color: #ffffff; font-size: 10px; font-family: arial, =
helvetica, san-serif; valign: top }
    TD.author-text { color: #000000; font-size: 10px;
                     font-family: verdana, charcoal, helvetica, arial, =
sans-serif }
    TD.author { color: #000000; font-weight: bold; margin-left: 4em; =
font-size: 10px; font-family: verdana, charcoal, helvetica, arial, =
sans-serif }
    A:link { color: #990000; font-size: 10px; text-transform: uppercase; =
font-weight: bold;
             font-family: MS Sans Serif, verdana, charcoal, helvetica, =
arial, sans-serif }
    A:visited { color: #333333; font-weight: bold; font-size: 10px; =
text-transform: uppercase;
                font-family: MS Sans Serif, verdana, charcoal, =
helvetica, arial, sans-serif }
    A:name { color: #333333; font-weight: bold; font-size: 10px; =
text-transform: uppercase;
             font-family: MS Sans Serif, verdana, charcoal, helvetica, =
arial, sans-serif }
    .link2 { color:#ffffff; font-weight: bold; text-decoration: none;
             font-family: monaco, charcoal, geneva, MS Sans Serif, =
helvetica, monotype, verdana, sans-serif;
             font-size: 9px }
    .RFC { color:#666666; font-weight: bold; text-decoration: none;
           font-family: monaco, charcoal, geneva, MS Sans Serif, =
helvetica, monotype, verdana, sans-serif;
           font-size: 9px }
    .hotText { color:#ffffff; font-weight: normal; text-decoration: =
none;
               font-family: charcoal, monaco, geneva, MS Sans Serif, =
helvetica, monotype, verdana, sans-serif;
               font-size: 9px }
</style>
</head>
<body bgcolor=3D"#ffffff"text=3D"#000000" alink=3D"#000000" =
vlink=3D"#666666" link=3D"#990000">
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<table width=3D"66%" border=3D"0" cellpadding=3D"0" =
cellspacing=3D"0"><tr><td><table width=3D"100%" border=3D"0" =
cellpadding=3D"2" cellspacing=3D"1">
<tr valign=3D"top"><td width=3D"33%" bgcolor=3D"#666666" =
class=3D"header">Network Working Group</td><td width=3D"33%" =
bgcolor=3D"#666666" class=3D"header">M.T. Rose</td></tr>
<tr valign=3D"top"><td width=3D"33%" bgcolor=3D"#666666" =
class=3D"header">Internet-Draft</td><td width=3D"33%" =
bgcolor=3D"#666666" class=3D"header">Invisible Worlds, Inc.</td></tr>
<tr valign=3D"top"><td width=3D"33%" bgcolor=3D"#666666" =
class=3D"header">Expires: March 6, 2001</td><td width=3D"33%" =
bgcolor=3D"#666666" class=3D"header">September 5, 2000</td></tr>
</table></td></tr></table>
<div align=3D"right"><font face=3D"monaco, MS Sans Serif" =
color=3D"#990000" size=3D"+3"><b><br><span class=3D"title">Mapping the =
BXXP Framework onto TCP</span></b></font></div>
<div align=3D"right"><font face=3D"monaco, MS Sans Serif" =
color=3D"#666666" size=3D"+2"><b><span =
class=3D"filename">draft-ietf-beep-tcpmapping-01</span></b></font></div>
<font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<h3>Status of this Memo</h3>
<p>
This document is an Internet-Draft and is in full conformance with all =
provisions of Section 10 of RFC2026.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any =
time.
It is inappropriate to use Internet-Drafts as reference material or to =
cite
them other than as "work in progress."</p>
<p>
The list of current Internet-Drafts can be accessed at
<a =
href=3D'http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/i=
etf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a =
href=3D'http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html<=
/a>.</p>
<p>
This Internet-Draft will expire on March 6, 2001.</p>

<h3>Copyright Notice</h3>
<p>
Copyright (C) The Internet Society (2000). All Rights Reserved.</p>

<h3>Abstract</h3>

<p>
This memo describes how a BXXP session is mapped onto
a single TCP connection.
</p>
<a name=3D"toc"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Table of Contents</h3>
<ul compact class=3D"toc">
<b><a href=3D"#anchor1">1.</a>&nbsp;
Introduction<br></b>
<b><a href=3D"#anchor2">2.</a>&nbsp;
Session Management<br></b>
<b><a href=3D"#anchor3">3.</a>&nbsp;
Message Exchange<br></b>
<b><a href=3D"#anchor4">3.1</a>&nbsp;
Flow Control<br></b>
<b><a href=3D"#anchor5">3.1.1</a>&nbsp;
Channel Creation<br></b>
<b><a href=3D"#anchor6">3.1.2</a>&nbsp;
Sending Messages<br></b>
<b><a href=3D"#flow.seq">3.1.3</a>&nbsp;
Processing SEQ Frames<br></b>
<b><a href=3D"#flow.use">3.1.4</a>&nbsp;
Use of Flow Control<br></b>
<b><a href=3D"#rfc.references">&#167;</a>&nbsp;
References<br></b>
<b><a href=3D"#rfc.authors">&#167;</a>&nbsp;
Author's Address<br></b>
<b><a href=3D"#anchor7">A.</a>&nbsp;
Changes from draft-ietf-beep-tcpmapping-00<br></b>
<b><a href=3D"#anchor8">B.</a>&nbsp;
Changes from draft-mrose-bxxp-tcpmapping-01<br></b>
<b><a href=3D"#anchor9">C.</a>&nbsp;
Changes from draft-mrose-bxxp-tcpmapping-00<br></b>
<b><a href=3D"#anchor10">D.</a>&nbsp;
Acknowledgements<br></b>
<b><a href=3D"#rfc.copyright">&#167;</a>&nbsp;
Full Copyright Statement<br></b>
</ul>
<br clear=3D"all">

<a name=3D"anchor1"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>1.&nbsp;Introduction</h3>

<p>
This memo describes how a <a href=3D"#BEEP-FRAMEWORK">BXXP</a>[1] =
session
is mapped onto a single <a href=3D"#RFC0793">TCP</a>[2] connection.
Refer to Section 2.5 of <a href=3D"#BEEP-FRAMEWORK">[1]</a> for an =
explanation of
the mapping requirements.
</p>

<a name=3D"anchor2"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>2.&nbsp;Session Management</h3>

<p>
The mapping of BXXP session management onto the TCP service is
straight-forward.
</p>

<p>
A BXXP session is established when a TCP connection is established
between two BXXP peers:

<ul class=3D"text">

<li>
the BXXP peer that issues a passive OPEN call is termed the
listener; and,
</li>

<li>
the BXXP peer that issues an active OPEN call is termed the
initiator.
</li>

</ul>

</p>

<p>
A BXXP session is released when either peer issues the CLOSE call,
and the TCP connection is subsequently closed.
</p>

<p>
A BXXP session is terminated when either peer issues the ABORT call,
and the TCP connection is subsequently aborted.
</p>

<a name=3D"anchor3"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>3.&nbsp;Message Exchange</h3>

<p>
The mapping of BXXP exchanges onto the TCP service is less
straight-forward.
</p>

<p>
Messages are reliably sent and received using the SEND and RECEIVE
calls.
(This also provides ordered delivery of messages on the same channel.)
</p>

<p>
Although TCP imposes flow control on a per-connection basis,
if multiple channels are simultaneously in use on a BXXP session,
BXXP must provide a mechanism to avoid starvation and deadlock.
To achieve this,
BXXP re-introduces a mechanism used by the TCP:
window-based flow control &#151;
each channel has a sliding window that indicates the number of payload
octets that a peer may transmit before receiving further permission.
</p>

<p>

</p>

<h4><a name=3D"anchor4">3.1</a>&nbsp;Flow Control</h4>

<p>
Recall from Section 2.2.1.2 of <a href=3D"#BEEP-FRAMEWORK">[1]</a> that
every payload octet sent in each direction on a channel has an
associated sequence number.
Numbering of payload octets within a frame is such that the first =
payload
octet is the lowest numbered,
and the following payload octets are numbered consecutively.
</p>

<p>
The actual sequence number space is finite,
though very large,
ranging from 0..4294967295 (2**32 - 1).
Since the space is finite,
all arithmetic dealing with sequence numbers is performed modulo 2**32.
This unsigned arithmetic preserves the relationship of sequence
numbers as they cycle from 2**32 - 1 to 0 again.
</p>

<h4><a name=3D"anchor5">3.1.1</a>&nbsp;Channel Creation</h4>

<p>
When a channel is created,
the sequence number associated with the first payload octet of the
first frame is 0,
and the initial window size for that channel is 4096 octets.
After channel creation,
a BXXP peer may update the window size by
<a href=3D"#flow.seq">sending a "SEQ" frame</a>.
</p>

<p>
If a BXXP peer is asked to create a channel and it is unable to
allocate at least 4096 octets for that channel,
it must decline creation of the channel,
as specified in Section 2.3.1.2 of <a href=3D"#BEEP-FRAMEWORK">[1]</a>.
Similarly,
during establishment of the BXXP session,
if the BXXP peer acting in the listening role is unable to allocate at
least 4096 octets for channel 0,
then it must return a negative reply,
as specified in Section 2.4 of <a href=3D"#BEEP-FRAMEWORK">[1]</a>.
instead of a greeting.
</p>

<p>

</p>

<h4><a name=3D"anchor6">3.1.2</a>&nbsp;Sending Messages</h4>

<p>
Before a message is sent,
the sending BXXP peer must ensure that the size of the payload is within
the window advertised by the receiving BXXP peer.
If not,
it has three choices:

<ul class=3D"text">

<li>
if the window would allow for at least one payload octet to be
sent,
the BXXP peer may segment the message and start by sending a smaller =
frame
(up to the size of the remaining window);
</li>

<li>
the BXXP peer may delay sending the message until the
window becomes larger; or,
</li>

<li>
the BXXP peer may signal to its application that it is unable to
send the message,
allowing the application to try again at a later time
(or perhaps signaling its application when a larger window is =
available.)
</li>

</ul>

The choice is implementation-dependent,
although it is recommended that the application using BXXP be
given a mechanism for influencing the decision.
</p>

<p>

</p>

<h4><a name=3D"flow.seq">3.1.3</a>&nbsp;Processing SEQ Frames</h4>

<p>
As an application accepts responsibility for incoming frames,
its BXXP peer should send "SEQ" frames to advertise a new window.
</p>

<p>
The ABNF for a "SEQ" frame is:
</p>
</font><pre>
    seq        =3D "SEQ" SP channel SP ackno SP window CR LF

    ackno      =3D seqno

    window     =3D size

    ; channel, seqno, and size are defined in Section 2.2.1 of [1].
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
The "SEQ" frame has three parameters:

<ul class=3D"text">

<li>
a channel number;
</li>

<li>
an acknowledgement number,
that indicates the value of the next sequence number that the sender
is expecting to receive on this channel; and,
</li>

<li>
a window size,
that indicates the number of payload octets beginning with the one
indicated by the acknowledgement number that the sender is expecting to
receive on this channel.
</li>

</ul>

A single space character (decimal code 32, " ") separates each
component.
The "SEQ" frame is terminated with a CRLF pair.
</p>

<p>
When a "SEQ" frame is received,
if any of the channel number, acknowledgement number, or window size
cannot be determined or is invalid,
then the BXXP session is terminated without generating a response,
and it is recommended that a diagnostic entry be logged.
</p>

<p>

</p>

<h4><a name=3D"flow.use">3.1.4</a>&nbsp;Use of Flow Control</h4>

<p>
The key to successful use of flow control within BXXP is to balance
performance and fairness:

<ul class=3D"text">

<li>
large messages should be segmented into multiple frames
(e.g., the ideal BXXP segment size should be no larger than TCP's
negotiated maximum segment size minus some small constant);
</li>

<li>
frames for different channels with traffic ready to send should be
sent in a round-robin fashion; and,
</li>

<li>
each time a message is received,
a "SEQ" frame should be sent whenever the window size is
at least one half of the available buffer space
(if the transport service presents multiple messages to a BXXP peer
simultaneously,
then a single consolidating "SEQ" frame may be sent).
</li>

</ul>

In order to avoid pathological interactions with the transport
service,
it is important that a BXXP peer advertise windows based on available
buffer space,
to allow data to be read from the transport service as soon as
available.
Further,
"SEQ" frames for a channel should have higher priority than messages
for that channel.
</p>

<p>
Implementations may wish to provide queue management facilities to the
application using BXXP,
e.g., channel priorities, (relative) buffer allocations, and so on.
In particular,
implementations should not allow a given channel to monopolize the
underlying transport window
(e.g., slow readers should get small windows).
</p>

<p>
In addition,
where possible,
implementations should support transport layer APIs that convey
congestion information.
</p>

<p>
Finally,
implementors should follow the guidelines given in the relevant portions
of <a href=3D"#RFC1122">RFC1122</a>[3] that deal with flow control=20
(and bear in mind that issues such as retransmission,
while they interact with flow control in TCP,
are not applicable to this memo).
For example,
Section 4.2.2.16 of <a href=3D"#RFC1122">RFC1122</a>[3] indicates
that a "receiver SHOULD NOT shrink the window, i.e., move the right
window edge to the left" and then discusses the impact of this rule on
unacknowledged data.
In the context of mapping BXXP onto a single TCP connection,
only the portions concerning flow control should be implemented.
</p>
<a name=3D"rfc.references"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>
References</h3>
<table width=3D"99%" border=3D"0">
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"BEEP-FRAMEWORK">[1]</a></b></td>
<td class=3D"author-text"><a href=3D"mailto:mrose@invisible.net">Rose, =
M.T.</a>, "<a =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-beep-framework-01.=
txt">The Blocks eXtensible eXchange Protocol Framework</a>", =
draft-ietf-beep-framework-01 (work in progress), September =
2000.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"RFC0793">[2]</a></b></td>
<td class=3D"author-text">Postel, J., "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc793.txt">Transmission Control =
Protocol</a>", RFC 793, STD 7, Sep 1981.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"RFC1122">[3]</a></b></td>
<td class=3D"author-text">Braden, R.T., "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc1122.txt">Requirements for =
Internet hosts - communication layers</a>", RFC 1122, STD 3, Oct =
1989.</td></tr>
</table>

<a name=3D"rfc.authors"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Author's Address</h3>
<table width=3D"99%" border=3D"0" cellpadding=3D"0" cellspacing=3D"0">
<tr><td class=3D"author-text">&nbsp;</td>
<td class=3D"author-text">Marshall T. Rose</td></tr>
<tr><td class=3D"author-text">&nbsp;</td>
<td class=3D"author-text">Invisible Worlds, Inc.</td></tr>
<tr><td class=3D"author-text">&nbsp;</td>
<td class=3D"author-text">1179 North McDowell Boulevard</td></tr>
<tr><td class=3D"author-text">&nbsp;</td>
<td class=3D"author-text">Petaluma, CA  94954-6559</td></tr>
<tr><td class=3D"author-text">&nbsp;</td>
<td class=3D"author-text">US</td></tr>
<tr><td class=3D"author" align=3D"right">Phone:&nbsp;</td>
<td class=3D"author-text">+1 707 789 3700</td></tr>
<tr><td class=3D"author" align=3D"right">EMail:&nbsp;</td>
<td class=3D"author-text"><a =
href=3D"mailto:mrose@invisible.net">mrose@invisible.net</a></td></tr>
<tr><td class=3D"author" align=3D"right">URI:&nbsp;</td>
<td class=3D"author-text"><a =
href=3D"http://invisible.net/">http://invisible.net/</a></td></tr>
</table>

<a name=3D"anchor7"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix A.&nbsp;Changes from draft-ietf-beep-tcpmapping-00</h3>

<p>

<ul class=3D"text">

<li>
References to "REQ" and "RSP" messages are generalized.
</li>

</ul>

</p>

<a name=3D"anchor8"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix B.&nbsp;Changes from draft-mrose-bxxp-tcpmapping-01</h3>

<p>

<ul class=3D"text">

<li>
A reference to RFC1122,
along with instructions on how to interpret that specification,
is added to <a href=3D"#flow.use">Use of Flow Control</a>.
</li>

</ul>

</p>

<a name=3D"anchor9"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix C.&nbsp;Changes from draft-mrose-bxxp-tcpmapping-00</h3>

<p>

<ul class=3D"text">

<li>
The IPR notice is changed to be in full compliance of Section 10 of
RFC 2026.
</li>

<li>
SEQ messages are now (correcty) called SEQ frames.
</li>

<li>
In <a href=3D"#flow.use">Use of Flow Control</a>,
the explanation of when to send a SEQ frame is clarified.
</li>

<li>
In <a href=3D"#flow.use">Use of Flow Control</a>,
the illustration of queue management facilities is expanded.
</li>

</ul>

</p>

<a name=3D"anchor10"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix D.&nbsp;Acknowledgements</h3>

<p>
The author gratefully acknowledges the contributions of:
Dave Crocker,
Steve Harris,
Eliot Lear,
Keith McCloghrie,
Craig Partridge,
Vernon Schryver,
and,
Joe Touch.
In particular,
Dave Crocker provided helpful suggestions on the nature of=20
flow control in the mapping.
</p>
<a name=3D"rfc.copyright"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Full Copyright Statement</h3>
<p class=3D'copyright'>
Copyright (C) The Internet Society (2000). All Rights Reserved.</p>
<p class=3D'copyright'>
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.</p>
<p class=3D'copyright'>
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.</p>
<p class=3D'copyright'>
This document and the information contained herein is provided on an
&quot;AS IS&quot; basis and THE INTERNET SOCIETY AND THE INTERNET =
ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>
<h3>Acknowledgement</h3>
<p class=3D'copyright'>
Funding for the RFC editor function is currently provided by the
Internet Society.</p>
</font></body></html>

------=_NextPart_000_007A_01C01C4A.74CFB1A0
Content-Type: text/html;
	name="draft-ietf-beep-framework.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-beep-framework.html"

<html><head><title>The Blocks eXtensible eXchange Protocol =
Framework</title>
<STYLE type=3D'text/css'>
    .title { color: #990000; font-size: 22px; line-height: 22px; =
font-weight: bold; text-align: right;
             font-family: helvetica, arial, sans-serif }
    .filename { color: #666666; font-size: 18px; line-height: 28px; =
font-weight: bold; text-align: right;
                  font-family: helvetica, arial, sans-serif }
    p.copyright { color: #000000; font-size: 10px;
                  font-family: verdana, charcoal, helvetica, arial, =
sans-serif }
    p { margin-left: 2em; margin-right: 2em; }
    ol { margin-left: 2em; margin-right: 2em; }
    ul.text { margin-left: 2em; margin-right: 2em; }
    pre { margin-left: 3em; color: #333333 }
    ul.toc { color: #000000; line-height: 16px;
             font-family: verdana, charcoal, helvetica, arial, =
sans-serif }
    H3 { color: #333333; font-size: 16px; line-height: 16px; =
font-family: helvetica, arial, sans-serif }
    H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, =
sans-serif }
    TD.header { color: #ffffff; font-size: 10px; font-family: arial, =
helvetica, san-serif; valign: top }
    TD.author-text { color: #000000; font-size: 10px;
                     font-family: verdana, charcoal, helvetica, arial, =
sans-serif }
    TD.author { color: #000000; font-weight: bold; margin-left: 4em; =
font-size: 10px; font-family: verdana, charcoal, helvetica, arial, =
sans-serif }
    A:link { color: #990000; font-size: 10px; text-transform: uppercase; =
font-weight: bold;
             font-family: MS Sans Serif, verdana, charcoal, helvetica, =
arial, sans-serif }
    A:visited { color: #333333; font-weight: bold; font-size: 10px; =
text-transform: uppercase;
                font-family: MS Sans Serif, verdana, charcoal, =
helvetica, arial, sans-serif }
    A:name { color: #333333; font-weight: bold; font-size: 10px; =
text-transform: uppercase;
             font-family: MS Sans Serif, verdana, charcoal, helvetica, =
arial, sans-serif }
    .link2 { color:#ffffff; font-weight: bold; text-decoration: none;
             font-family: monaco, charcoal, geneva, MS Sans Serif, =
helvetica, monotype, verdana, sans-serif;
             font-size: 9px }
    .RFC { color:#666666; font-weight: bold; text-decoration: none;
           font-family: monaco, charcoal, geneva, MS Sans Serif, =
helvetica, monotype, verdana, sans-serif;
           font-size: 9px }
    .hotText { color:#ffffff; font-weight: normal; text-decoration: =
none;
               font-family: charcoal, monaco, geneva, MS Sans Serif, =
helvetica, monotype, verdana, sans-serif;
               font-size: 9px }
</style>
</head>
<body bgcolor=3D"#ffffff"text=3D"#000000" alink=3D"#000000" =
vlink=3D"#666666" link=3D"#990000">
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<table width=3D"66%" border=3D"0" cellpadding=3D"0" =
cellspacing=3D"0"><tr><td><table width=3D"100%" border=3D"0" =
cellpadding=3D"2" cellspacing=3D"1">
<tr valign=3D"top"><td width=3D"33%" bgcolor=3D"#666666" =
class=3D"header">Network Working Group</td><td width=3D"33%" =
bgcolor=3D"#666666" class=3D"header">M.T. Rose</td></tr>
<tr valign=3D"top"><td width=3D"33%" bgcolor=3D"#666666" =
class=3D"header">Internet-Draft</td><td width=3D"33%" =
bgcolor=3D"#666666" class=3D"header">Invisible Worlds, Inc.</td></tr>
<tr valign=3D"top"><td width=3D"33%" bgcolor=3D"#666666" =
class=3D"header">Expires: March 12, 2001</td><td width=3D"33%" =
bgcolor=3D"#666666" class=3D"header">September 11, 2000</td></tr>
</table></td></tr></table>
<div align=3D"right"><font face=3D"monaco, MS Sans Serif" =
color=3D"#990000" size=3D"+3"><b><br><span class=3D"title">The Blocks =
eXtensible eXchange Protocol Framework</span></b></font></div>
<div align=3D"right"><font face=3D"monaco, MS Sans Serif" =
color=3D"#666666" size=3D"+2"><b><span =
class=3D"filename">draft-ietf-beep-framework-01</span></b></font></div>
<font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<h3>Status of this Memo</h3>
<p>
This document is an Internet-Draft and is in full conformance with all =
provisions of Section 10 of RFC2026.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any =
time.
It is inappropriate to use Internet-Drafts as reference material or to =
cite
them other than as "work in progress."</p>
<p>
The list of current Internet-Drafts can be accessed at
<a =
href=3D'http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/i=
etf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a =
href=3D'http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html<=
/a>.</p>
<p>
This Internet-Draft will expire on March 12, 2001.</p>

<h3>Copyright Notice</h3>
<p>
Copyright (C) The Internet Society (2000). All Rights Reserved.</p>

<h3>Abstract</h3>

<p>
This memo describes a generic application protocol
framework for connection-oriented,
asynchronous interactions.
The framework permits simultaneous and independent exchanges
within the context of a single application user-identity,
supporting both textual and binary messages.
</p>
<a name=3D"toc"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Table of Contents</h3>
<ul compact class=3D"toc">
<b><a href=3D"#anchor1">1.</a>&nbsp;
Introduction<br></b>
<b><a href=3D"#anchor2">2.</a>&nbsp;
The BXXP Framework<br></b>
<b><a href=3D"#anchor3">2.1</a>&nbsp;
Roles<br></b>
<b><a href=3D"#anchor4">2.1.1</a>&nbsp;
Exchange Styles<br></b>
<b><a href=3D"#messages">2.2</a>&nbsp;
Messages and Frames<br></b>
<b><a href=3D"#frame.syntax">2.2.1</a>&nbsp;
Frame Syntax<br></b>
<b><a href=3D"#frame.header">2.2.1.1</a>&nbsp;
Frame Header<br></b>
<b><a href=3D"#frame.payload">2.2.1.2</a>&nbsp;
Frame Payload<br></b>
<b><a href=3D"#anchor5">2.2.1.3</a>&nbsp;
Frame Trailer<br></b>
<b><a href=3D"#frame.semantics">2.2.2</a>&nbsp;
Frame Semantics<br></b>
<b><a href=3D"#anchor6">2.2.2.1</a>&nbsp;
Poorly-formed Messages<br></b>
<b><a href=3D"#anchor7">2.2.2.2</a>&nbsp;
XML-based Profiles<br></b>
<b><a href=3D"#channel.mgmt">2.3</a>&nbsp;
Channel Management<br></b>
<b><a href=3D"#bxxp.messages">2.3.1</a>&nbsp;
Message Semantics<br></b>
<b><a href=3D"#greeting.message">2.3.1.1</a>&nbsp;
The Greeting Message<br></b>
<b><a href=3D"#start.message">2.3.1.2</a>&nbsp;
The Start Message<br></b>
<b><a href=3D"#close.message">2.3.1.3</a>&nbsp;
The Close Message<br></b>
<b><a href=3D"#ok.message">2.3.1.4</a>&nbsp;
The OK Message<br></b>
<b><a href=3D"#error.message">2.3.1.5</a>&nbsp;
The Error Message<br></b>
<b><a href=3D"#session.estab">2.4</a>&nbsp;
Session Establishment and Release<br></b>
<b><a href=3D"#transport.mapping">2.5</a>&nbsp;
Transport Mappings<br></b>
<b><a href=3D"#anchor8">2.5.1</a>&nbsp;
Session Management<br></b>
<b><a href=3D"#anchor9">2.5.2</a>&nbsp;
Message Exchange<br></b>
<b><a href=3D"#anchor10">2.6</a>&nbsp;
Parallelism<br></b>
<b><a href=3D"#anchor11">2.6.1</a>&nbsp;
Within a Single Channel<br></b>
<b><a href=3D"#anchor12">2.6.2</a>&nbsp;
Between Different Channels<br></b>
<b><a href=3D"#anchor13">2.6.3</a>&nbsp;
Pre-emptive Replies<br></b>
<b><a href=3D"#anchor14">2.6.4</a>&nbsp;
Interference<br></b>
<b><a href=3D"#anchor15">2.7</a>&nbsp;
Peer-to-Peer Behavior<br></b>
<b><a href=3D"#anchor16">3.</a>&nbsp;
Transport Security<br></b>
<b><a href=3D"#tls.profile">3.1</a>&nbsp;
The TLS Transport Security Profile<br></b>
<b><a href=3D"#anchor17">3.1.1</a>&nbsp;
Profile Identification and Initialization<br></b>
<b><a href=3D"#anchor18">3.1.2</a>&nbsp;
Message Syntax<br></b>
<b><a href=3D"#tls.messages">3.1.3</a>&nbsp;
Message Semantics<br></b>
<b><a href=3D"#anchor19">3.1.3.1</a>&nbsp;
The Ready Message<br></b>
<b><a href=3D"#anchor20">3.1.3.2</a>&nbsp;
The Proceed Message<br></b>
<b><a href=3D"#anchor21">4.</a>&nbsp;
User Authentication<br></b>
<b><a href=3D"#sasl.profiles">4.1</a>&nbsp;
The SASL Family of Profiles<br></b>
<b><a href=3D"#anchor22">4.1.1</a>&nbsp;
Profile Identification and Initialization<br></b>
<b><a href=3D"#anchor23">4.1.2</a>&nbsp;
Message Syntax<br></b>
<b><a href=3D"#sasl.messages">4.1.3</a>&nbsp;
Message Semantics<br></b>
<b><a href=3D"#profile.registration">5.</a>&nbsp;
Profile Registration Template<br></b>
<b><a href=3D"#initial.definitions">6.</a>&nbsp;
Initial Profile Registrations<br></b>
<b><a href=3D"#channelZ.definition">6.1</a>&nbsp;
BXXP Channel Management<br></b>
<b><a href=3D"#bxxp.dtd">6.2</a>&nbsp;
BXXP Channel Management DTD<br></b>
<b><a href=3D"#tls.definition">6.3</a>&nbsp;
Registration: TLS Transport Security Profile<br></b>
<b><a href=3D"#tls.dtd">6.4</a>&nbsp;
TLS Transport Security Profile DTD<br></b>
<b><a href=3D"#sasl.definition">6.5</a>&nbsp;
Registration: SASL Family of Profiles<br></b>
<b><a href=3D"#sasl.dtd">6.6</a>&nbsp;
SASL Family of Profiles DTD<br></b>
<b><a href=3D"#reply-codes">7.</a>&nbsp;
Reply Codes<br></b>
<b><a href=3D"#anchor24">8.</a>&nbsp;
Security Considerations<br></b>
<b><a href=3D"#anchor25">9.</a>&nbsp;
IANA Considerations<br></b>
<b><a href=3D"#rfc.references">&#167;</a>&nbsp;
References<br></b>
<b><a href=3D"#rfc.authors">&#167;</a>&nbsp;
Author's Address<br></b>
<b><a href=3D"#anchor26">A.</a>&nbsp;
Changes from draft-ietf-beep-framework-00<br></b>
<b><a href=3D"#anchor27">B.</a>&nbsp;
Changes from draft-mrose-bxxp-framework-01<br></b>
<b><a href=3D"#anchor28">C.</a>&nbsp;
Changes from draft-mrose-bxxp-framework-00<br></b>
<b><a href=3D"#anchor29">D.</a>&nbsp;
Acknowledgements<br></b>
<b><a href=3D"#rfc.copyright">&#167;</a>&nbsp;
Full Copyright Statement<br></b>
</ul>
<br clear=3D"all">

<a name=3D"anchor1"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>1.&nbsp;Introduction</h3>

<p>
This memo describes a generic application protocol
framework for connection-oriented, asynchronous interactions.
Consult <a href=3D"#BEEP-DESIGN">[1]</a> for a description of the
framework's design principles.
</p>

<p>
At the core of the BXXP framework is a framing mechanism that
permits simultaneous and independent exchanges of messages between =
peers.
Messages are arbitrary <a href=3D"#RFC2045">MIME</a>[2] content,
but are usually textual
(structured using <a href=3D"#W3C.XML">XML</a>[3]).
</p>

<p>
Frames are exchanged in the context of a "channel".
Each channel has an associated "profile" that defines the syntax and
semantics of the messages exchanged.
Implicit in the operation of BXXP is the notion of channel management.
In addition to defining BXXP's channel management profile,
this document defines:

<ul class=3D"text">

<li>
the <a href=3D"#RFC2246">TLS</a>[4] transport security profile; and,
</li>

<li>
the <a href=3D"#RFC2222">SASL</a>[5] family of profiles.
</li>

</ul>

Other profiles,
such as those used for data exchange,
are defined by an application protocol designer.
A registration template is provided for this purpose.
</p>

<a name=3D"anchor2"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>2.&nbsp;The BXXP Framework</h3>

<p>
The BXXP framework is message-oriented.
All exchanges occur in the context of a channel &#151;
a binding to a well-defined aspect of the application,
such as transport security, user authentication, or data exchange.
</p>

<p>
A BXXP session is mapped onto an underlying transport service.
A separate series of documents describe how a particular transport
service realizes a BXXP session.
For example,
<a href=3D"#BEEP-TCPMAPPING">[6]</a> describes how a BXXP session is
mapped onto a single <a href=3D"#RFC0793">TCP</a>[7] connection.
</p>

<p>
During the creation of a channel,
the client supplies one or more proposed profiles for that channel.
If the server creates the channel,
it selects one of the profiles and sends it in a reply;
otherwise,
it may indicate that none of the profiles are acceptable,
and decline creation of the channel.
</p>

<p>
Channel usage falls into one of two categories:

<blockquote class=3D"text"><dl>

<dt>initial tuning:</dt>
<dd>

these are used by profiles that perform initialization once the
BXXP session is established
(e.g., negotiating the use of transport security);
although several exchanges may be required to perform
the initialization,
these channels become inactive early in the BXXP session and remain so
for the duration.
</dd>

<dt>continuous:</dt>
<dd>

these are used by profiles that support data exchange;
typically,
these channels are created after the initial tuning channels have gone
quiet.
</dd>

</dl></blockquote>

</p>

<p>

</p>

<h4><a name=3D"anchor3">2.1</a>&nbsp;Roles</h4>

<p>
Although BXXP is peer-to-peer,
it is convenient to label each peer in the context of the role it is
performing at a given time:

<ul class=3D"text">

<li>
When a BXXP session is established,
the peer that awaits new connections is acting in the
listening role,
and the other peer,
which establishes a connection to the listener,
is acting in the initiating role.
In the examples which follow,
these are referred to as "L:" and "I:",
respectively.
</li>

<li>
A BXXP peer starting an exchange is termed the client;
similarly,
the other BXXP peer is termed the server.
In the examples which follow,
these are referred to as "C:" and "S:",
respectively.
</li>

</ul>

Typically,
a BXXP peer acting in the server role is also acting in a listening =
role.
However,
because BXXP is peer-to-peer in nature,
no such requirement exists.
</p>

<h4><a name=3D"anchor4">2.1.1</a>&nbsp;Exchange Styles</h4>

<p>
BXXP allows three styles of exchange:

<blockquote class=3D"text"><dl>

<dt>MSG/RPY:</dt>
<dd>
the client sends a "MSG" message asking the
server to perform some task,
the server performs the task and replies with a "RPY" message
(termed a positive reply).
</dd>

<dt>MSG/ERR:</dt>
<dd>
the client sends a "MSG" message,
the server does not perform any task and replies with an "ERR" message
(termed a negative reply).
</dd>

<dt>MSG/ANS:</dt>
<dd>
the client sends a "MSG" message,
the server,
during the course of performing some task,
replies with zero or more "ANS" messages,
and,
upon completion of the task,
sends a "NUL" message,
which signifies the end of the reply.
</dd>

</dl></blockquote>

The first two styles are termed one-to-one exchanges,
whilst the third style is termed a one-to-many exchange.
</p>

<p>

</p>

<h4><a name=3D"messages">2.2</a>&nbsp;Messages and Frames</h4>

<p>
A message is structured according to the rules of MIME.
Accordingly,
the payload may begin with "entity-headers"
(c.f., <a href=3D"#RFC2045">MIME</a>[2]'s Section 3).
If none,
or only some,
of the "entity-headers" are present:

<ul class=3D"text">

<li>
the default "Content-Type" is "text/xml"; and,
</li>

<li>
the default "Content-Transfer-Encoding" is "binary".
</li>

</ul>

Hence,
in the absence of typing information,
a message is a well-formed <a href=3D"#W3C.XML">XML</a>[3] document.
</p>

<p>
Normally,
a message is sent in a single frame.
However,
it may be convenient or necesary to segment a message into multiple =
frames
(e.g., if only part of a message is ready to be sent).
</p>

<p>
Each frame consists of a header, the payload, and a trailer.
The header and trailer are each represented using printable ASCII
characters and are terminated with a CRLF pair.
Between the header and the trailer is the payload,
consisting of zero or more octets.
</p>

<p>
For example,
here is a message contained in a single frame that contains a payload
of 96 octets spread over 4 lines
(each line is terminated with a CRLF pair):
</p>
</font><pre>
    C: MSG 0 1 . 16 96
    C:
    C: &lt;start number=3D'1'>
    C:    &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    C: &lt;/start>
    C: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
Note that the message starts with a blank line,
signifying a lack of explicit MIME typing information.
Also note that in this example,
the message is represented as a single payload.
</p>

<p>

</p>

<h4><a name=3D"frame.syntax">2.2.1</a>&nbsp;Frame Syntax</h4>

<p>
The ABNF for a frame is:
</p>
</font><pre>
frame      =3D header payload trailer / mapping

header     =3D msg / rpy / err / ans / nul

msg        =3D "MSG" SP common          CR LF

rpy        =3D "RPY" SP common          CR LF

ans        =3D "ANS" SP common SP ansno CR LF

err        =3D "ERR" SP common          CR LF

nul        =3D "NUL" SP common          CR LF


common     =3D channel SP msgno SP more SP seqno SP size

channel    =3D 0..2147483647

msgno      =3D 0..2147483647

more       =3D "." / "*"

seqno      =3D 0..4294967295

size       =3D 0..2147483647

ansno      =3D 0..2147483647


payload    =3D *OCTET


trailer    =3D "END" CR LF


mapping    =3D ;; each transport mapping may define additional frames
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>

</p>

<h4><a name=3D"frame.header">2.2.1.1</a>&nbsp;Frame Header</h4>

<p>
The frame header consists of a three-character keyword
(one of: "MSG", "RPY", "ERR", "ANS", or "NUL"),
followed by zero or more parameters.
A single space character (decimal code 32, " ") separates each =
component.
The header is terminated with a CRLF pair.
</p>

<p>
The channel number ("channel") must be a non-negative integer
(in the range 0..2147483647).
</p>

<p>
The message number ("msgno") must be a non-negative integer
(in the range 0..2147483647)
and have a different value than all other "MSG" messages for which a
reply has not been completely received.
</p>

<p>
The continuation indicator
("more", one of: decimal code 42, "*",
or decimal code 46, ".")
specifies whether this is the final frame of the message:

<blockquote class=3D"text"><dl>

<dt>   intermediate ("*"):</dt>
<dd>

at least one other frame follows for the message; or,
</dd>

<dt>   complete ("."):</dt>
<dd>

this frame completes the message.
</dd>

</dl></blockquote>

</p>

<p>
The sequence number ("seqno") must be a non-negative integer
(in the range 0..4294967295) and specifies the sequence number of the
first octet in the payload,
for the associated channel.
</p>

<p>
The payload size ("size") must be a non-negative integer
(in the range 0..2147483647) and specifies the exact number of octets
in the payload.
(This does not include either the header or trailer.)
</p>

<p>
Note that a frame may have an empty payload,
e.g.,
</p>
</font><pre>
    S: RPY 0 1 * 287 27
    S:
    S:     ...
    S:     ...
    S:     ...
    S: END
    S: RPY 0 1 . 314 0
    S: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
The answer number ("ansno") must be a non-negative integer
(in the range 0..4294967295) and must have a different value than all
other answers in progress for the message being replied to.
</p>

<p>

</p>

<p>
When a message is segmented and sent as several frames,
those frames must be sent sequentally,
without any intervening frames from other messages on the same channel.
However,
there are two exceptions:
first,
no restriction is made with respect to the interleaving of frames for
other channels;
and,
second,
in a one-to-many exchange,
multiple answers may be simultaneously in progress.
</p>

<p>
Accordingly,
frames for "ANS" messages may be interleaved on the same channel &#151;
the answer number is used for collation,
e.g.,
</p>
</font><pre>
    S: ANS 1 0 * 0 10 0
    S:
    S:     ...
    S: END
    S: ANS 1 0 * 10 20 1
    S:
    S:     ...
    S:     ...
    S: END
    S: ANS 1 0 . 30 10 0
    S:     ...
    S: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
which shows two "ANS" messages interleaved on channel 1 as
part of a reply to message number 0.
Note that the sequence number is advanced for each frame sent on the
channel,
and is independent of the messages sent in those frames.
</p>

<p>
There are several rules for identifying poorly-formed frames:

<ul class=3D"text">

<li>
if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or "NUL";=20
</li>

<li>
if any of the parameters in the header cannot be determined or are
invalid (i.e., syntactically incorrect);
</li>

<li>
if the value of the channel number doesn't refer to an existing
channel;
</li>

<li>
if the header starts with "MSG",
and the message number refers to a "MSG" message that has been =
completely
received but for which a reply has not been completely sent;
</li>

<li>
if the header doesn't start with "MSG",
and refers to a message number for which a reply has not been
completely received;
</li>

<li>
if the header doesn't start with "MSG",
and refers to a message number that has never been sent
(except during session establishment,
c.f., <a href=3D"#greeting.message">The Greeting Message</a>);
</li>

<li>
if the header starts with "MSG", "ERR", or "ANS",
and refers to a message number for which at least one other frame has
been received,
and the three-character keyword starting this frame and the
immediately-previous received frame for this reply are not identical;
</li>

<li>
if the header starts with "NUL",
and refers to a message number for which at least one other frame has
been received,
and the keyword of of the immediately-previous received frame for this
reply isn't "ANS";
</li>

<li>
if the continuation indicator of the previous frame received on
the same channel was intermediate ("*"),
and its message number isn't identical to this frame's message number;
</li>

<li>
if the value of the sequence number doesn't correspond to the
expected value for the associated channel
(c.f., <a href=3D"#frame.payload">Frame Payload</a>);
</li>

<li>
if the header starts with "NUL",
and the continuation indicator is intermediate ("*") or the payload
size is non-zero;
</li>

<li>
if the header doesn't start with "NUL",
and the continuation indicator is complete ("."),
and the total size of the (re-assembled) message is less than two
octets;
or,
</li>

<li>
if the header doesn't start with "NUL",
and the continuation indicator is complete ("."),
and "entity-headers" are present but poorly-formed in the
(re-assembled) message.
</li>

</ul>

If a frame is poorly-formed,
then the session is terminated without generating a response,
and it is recommended that a diagnostic entry be logged.
</p>

<p>

</p>

<h4><a name=3D"frame.payload">2.2.1.2</a>&nbsp;Frame Payload</h4>

<p>
The frame payload consists of zero or more octets.
</p>

<p>
Every payload octet sent in each direction on a channel has an
associated sequence number.
Numbering of payload octets within a frame is such that the first =
payload
octet is the lowest numbered,
and the following payload octets are numbered consecutively.
(When a channel is created,
the sequence number associated with the first payload octet of the
first frame is 0.)
</p>

<p>
The actual sequence number space is finite,
though very large,
ranging from 0..4294967295 (2**32 - 1).
Since the space is finite,
all arithmetic dealing with sequence numbers is performed modulo 2**32.
This unsigned arithmetic preserves the relationship of sequence
numbers as they cycle from 2**32 - 1 to 0 again.
</p>

<p>
When receiving a frame,
the sum of its sequence number and payload size,
modulo 4294967296 (2**32),
gives the expected sequence number associated with the first payload =
octet of
the next frame received.
Accordingly,
when receiving a frame if the sequence number isn't the expected
value for this channel,
then the BXXP peers have lost synchronization,
then the session is terminated without generating a response,
and it is recommended that a diagnostic entry be logged.
</p>

<p>

</p>

<h4><a name=3D"anchor5">2.2.1.3</a>&nbsp;Frame Trailer</h4>

<p>
The frame trailer consists of "END" followed by a CRLF pair.
</p>

<p>
When receiving a frame,
if the characters immediately following the payload don't correspond
to a trailer,
then the session is terminated without generating a response,
and it is recommended that a diagnostic entry be logged.
</p>

<p>

</p>

<h4><a name=3D"frame.semantics">2.2.2</a>&nbsp;Frame Semantics</h4>

<p>
The semantics of each message is channel-specific.
Accordingly,
the profile associated with a channel must define:

<ul class=3D"text">

<li>
the initialization messages,
if any,
exchanged during channel creation;
</li>

<li>
the messages that may be exchanged in the payload of the channel; and,
</li>

<li>
the semantics of these messages.
</li>

</ul>

A <a href=3D"#profile.registration">profile registration template</a>
organizes this information.
</p>

<h4><a name=3D"anchor6">2.2.2.1</a>&nbsp;Poorly-formed Messages</h4>

<p>
When defining the behavior of the profile,
the template must specify how poorly-formed "MSG" messages are replied
to.
For example,
the channel management profile sends a negative reply containing an
error message (c.f., <a href=3D"#error.message">The Error Message</a>).
</p>

<p>
If a poorly-formed reply is received on channel zero,
the session is terminated without generating a response,
and it is recommended that a diagnostic entry be logged.
</p>

<p>
If a poorly-formed reply is received on another channel,
then the channel must be closed using the procedure in
<a href=3D"#close.message">The Close Message</a>.
</p>

<p>

</p>

<h4><a name=3D"anchor7">2.2.2.2</a>&nbsp;XML-based Profiles</h4>

<p>
If a profile uses XML to structure its messages,
then only XML's baseline facilities
(as described in <a href=3D"#W3C.XML">the XML 1.0 specification</a>[3])
are allowed.
Additional XML features (e.g., namespaces) are made available only by
being explicitly discussed in a given profile's specification.
</p>

<p>
In particular this limitation allows use of only the five
predefined general entities references
("&amp;amp;",
"&amp;lt;",
"&amp;gt;",
"&amp;apos;", and
"&amp;quot;")
and numeric entity references in the messages exchanged.
</p>

<p>
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., &lt;?xml version=3D"1.0" ?>)
or a "DOCTYPE" declaration (e.g., &lt;!DOCTYPE ...>).
All other XML 1.0 instructions
(e.g., CDATA blocks, processing instructions, and so on) are allowed.
</p>

<p>
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,
a "Content-Type" entity-header should be used to specify the character
set in question.
</p>

<p>

</p>

<h4><a name=3D"channel.mgmt">2.3</a>&nbsp;Channel Management</h4>

<p>
When a BXXP session starts,
only channel number zero is defined,
which is used for channel management.
<a href=3D"#channelZ.definition">BXXP Channel Management</a> contains =
the profile registration for
BXXP channel management.
</p>

<p>
Channel management allows each BXXP peer to advertise the profiles
that it supports
(c.f., <a href=3D"#greeting.message">The Greeting Message</a>),
bind an instance of one of those profiles to a channel
(c.f., <a href=3D"#start.message">The Start Message</a>),
and then later close any channels or release the BXXP session
(c.f., <a href=3D"#close.message">The Close Message</a>).
</p>

<p>
A BXXP peer should support at least 257 concurrent channels.
</p>

<p>

</p>

<h4><a name=3D"bxxp.messages">2.3.1</a>&nbsp;Message Semantics</h4>

<h4><a name=3D"greeting.message">2.3.1.1</a>&nbsp;The Greeting =
Message</h4>

<p>
When a BXXP session is established,
each BXXP peer signifies its availability by immediately sending a
positive reply with a message number of zero that contains a
"greeting" element, e.g.,
</p>
</font><pre>
    L: &lt;wait for incoming connection>
    I: &lt;open connection>
    L: RPY 0 0 . 0 86
    L:
    L: &lt;greeting>
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/TLS' />
    L: &lt;/greeting>
    L: END
    I: RPY 0 0 . 0 16
    I:
    I: &lt;greeting />
    I: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
Note that this example implies that the BXXP peer in the
initiating role waits until the BXXP peer in the listening role sends =
its
greeting &#151; this is an artifact of the presentation;
in fact,
both BXXP peers send their replies independently.
</p>

<p>
The "greeting" element has two optional attributes
("features" and "localize")
and zero or more "profile" elements,
one for each profile supported by the BXXP peer acting in a server role:

<ul class=3D"text">

<li>
the "features" attribute,
if present,
contains one or more feature tokens,
each indicating an optional feature of the channel management profile
supported by the BXXP peer;
</li>

<li>
the "localize" attribute,
if present,
contains one or more language tokens (defined in <a =
href=3D"#RFC1766">[8]</a>),
each identifying a desirable language tag to be used by the remote
BXXP peer when generating textual diagnostics for the "close" and
"error" elements
(the tokens are ordered from most to least desirable); and,
</li>

<li>
each "profile" element contained within the "greeting" element =
identifies
a profile,
and unlike the "profile" elements that occur within the "start" element,
the content of each "profile" element may not contain an optional
initialization element.
</li>

</ul>

</p>

<p>
At present,
there are no optional features defined for the channel management =
profile.
</p>

<p>

</p>

<h4><a name=3D"start.message">2.3.1.2</a>&nbsp;The Start Message</h4>

<p>
When a BXXP peer wants to create a channel,
it sends a "start" element on channel zero,
e.g.,
</p>
</font><pre>
    I: MSG 0 1 . 16 96
    I:
    I: &lt;start number=3D'1'>
    I:    &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    I: &lt;/start>
    I: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
The "start" element has a "number" attribute,
an optional "serverName" attribute,
and one or more "profile" elements:

<ul class=3D"text">

<li>
the "number" attribute indicates the channel number=20
(in the range 1..2147483647)
used to identify the channel in future messages;
</li>

<li>
the "serverName" attribute,
an arbitrary string,
indicates the desired server name for this BXXP session; and,
</li>

<li>
each "profile" element contained within the "start" element identifies
a profile, and, optionally, contains an XML element
exchanged during channel creation as its content.
</li>

</ul>

</p>

<p>
To avoid conflict in assigning channel numbers when requesting the
creation of a channel,
BXXP peers acting in the initiating role use only positive integers that =
are
odd-numbered;
similarly,
BXXP peers acting in the listening role use only positive integers that =
are
even-numbered.
</p>

<p>
The "serverName" attribute for the first successful "start" element
received by a BXXP peer is meaningful for the duration of the BXXP
session.
(If the attribute isn't present or it's value is empty,
then the sending BXXP peer is requesting a configuration-specific
default value.)
The BXXP peer decides whether to operate as the indicated "serverName";
if not,
an "error" element is sent in a negative reply.
</p>

<p>
When a BXXP peer receives a "start" element on channel zero,
it examines each of the proposed profiles,
and decides whether to use one of them to create the channel.
If so,
the appropriate "profile" element is sent in a positive reply;
otherwise,
an "error" element is sent in a negative reply.
</p>

<p>
When creating the channel,
the value of the "serverName" attribute from the first successful
"start" element is consulted to provide configuration information,
e.g., the desired server-side certificate when starting the
<a href=3D"#tls.profile">TLS transport security profile</a>.
</p>

<p>
For example,
a successful channel creation might look like this:
</p>
</font><pre>
    I: MSG 0 1 . 16 173
    I:=20
    I: &lt;start number=3D'1'>
    I:    &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    I:    &lt;profile
    I:       uri=3D'http://xml.resource.org/profiles/sasl/ANONYMOUS' />
    I: &lt;/start>
    I: END
    L: RPY 0 1 . 287 63
    L:
    L: &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' />
    L: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
Similarly,
an unsuccessful channel creation might look like this:
</p>
</font><pre>
    I: MSG 0 1 . 16 96
    I:=20
    I: &lt;start number=3D'2'>
    I:    &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>=20
    I: &lt;/start>
    I: END
    L: ERR 0 1 . 287 91
    L:
    L: &lt;error code=3D'501'>number attribute
    L: in &amp;lt;start&amp;gt; element must be odd-valued&lt;/error>
    L: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
Finally,
here's an example in which an initialization element is exchanged
during channel creation:
</p>
</font><pre>
    C: MSG 0 1 . 16 122
    C:
    C: &lt;start number=3D'1'>
    C:    &lt;profile uri=3D'http://xml.resource.org/profiles/TLS'>
    C:        &lt;ready />
    C:    &lt;/profile>
    C: &lt;/start>
    C: END
    S: RPY 0 1 . 86 85
    S:
    S: &lt;profile uri=3D'http://xml.resource.org/profiles/TLS'>
    S:     &lt;proceed />
    S: &lt;/profile>
    S: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>

</p>

<h4><a name=3D"close.message">2.3.1.3</a>&nbsp;The Close Message</h4>

<p>
When a BXXP peer wants to close a channel,
it sends a "close" element on channel zero,
e.g.,
</p>
</font><pre>
    I: MSG 0 2 . 163 35
    I:
    I: &lt;close number=3D'1' code=3D'200' />
    I: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
The "close" element has a "number" attribute,
a "code" attribute,
an optional "xml:lang" attribute,
and an optional textual diagnostic as its content:

<ul class=3D"text">

<li>
the "number" attribute indicates the channel number;
</li>

<li>
the "code" attribute is a three digit reply code meaningful to programs
(c.f., <a href=3D"#reply-codes">Reply Codes</a>);
</li>

<li>
the "xml:lang" attribute identifies the language that the element's
content is written in
(the value is suggested,
but not mandated,
by the "localize" attribute of the "greeting" element sent by the
remote BXXP peer); and,
</li>

<li>
the textual diagnostic (which may be multiline) is
meaningful to implementers,
perhaps administrators,
and possibly even users,
but never programs.
</li>

</ul>

Note that if the textual diagnostic is present,
then the "xml:lang" attribute is absent only if the language
indicated as the remote BXXP peer's first choice is used.
</p>

<p>
If the value of the "number" attribute is zero,
then the BXXP peer wants to release the BXXP session
(c.f., <a href=3D"#session.estab">Session Establishment and Release</a>) =
&#151; otherwise the value of
the "number" attribute refers to an existing channel.
</p>

<p>
When a BXXP peer receives a "close" element on channel zero,
it decides whether it is willing to close the channel.
If so,
an "ok" element is sent in a positive reply;
otherwise,
an "error" element is sent in a negative reply.
</p>

<p>

</p>

<p>
For example,
a successful channel close might look like this:
</p>
</font><pre>
    I: MSG 0 2 . 163 35
    I:
    I: &lt;close number=3D'1' code=3D'200' />
    I: END
    L: RPY 0 2 . 429 10
    L:
    L: &lt;ok />
    L: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
Similarly,
an unsuccessful channel close might look like this:
</p>
</font><pre>
    I: MSG 0 2 . 163 35
    I:
    I: &lt;close number=3D'1' code=3D'200' />
    I: END
    L: ERR 0 2 . 429 43
    L:
    L: &lt;error code=3D'550'>still working&lt;/error>
    L: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>

</p>

<h4><a name=3D"ok.message">2.3.1.4</a>&nbsp;The OK Message</h4>

<p>
When a BXXP peer agrees to close a channel
(or release the BXXP session),
it sends an "ok" element in a positive reply.
</p>

<p>
The "ok" element has no attributes and no content.
</p>

<h4><a name=3D"error.message">2.3.1.5</a>&nbsp;The Error Message</h4>

<p>
When a BXXP peer declines the creation of a channel,
it sends an "error" element in a negative reply,
e.g.,
</p>
</font><pre>
    I: MSG 0 1 . 16 91
    I:=20
    I: &lt;start number=3D'2'>
    I:    &lt;profile uri=3D'http://xml.resource.org/profiles/FOO' />
    I: &lt;/start>
    I: END
    L: ERR 0 1 . 287 69
    L:
    L: &lt;error code=3D'550'>all requested profiles are
    L: unsupported&lt;/error>
    L: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
The "error" element has a "code" attribute,
an optional "xml:lang" attribute,
and an optional textual diagnostic as its content:

<ul class=3D"text">

<li>
the "code" attribute is a three digit reply code meaningful to programs
(c.f., <a href=3D"#reply-codes">Reply Codes</a>);
</li>

<li>
the "xml:lang" attribute identifies the language that the element's
content is written in
(the value is suggested,
but not mandated,
by the "localize" attribute of the "greeting" element sent by the
remote BXXP peer); and,
</li>

<li>
the textual diagnostic (which may be multiline) is
meaningful to implementers,
perhaps administrators,
and possibly even users,
but never programs.
</li>

</ul>

Note that if the textual diagnostic is present,
then the "xml:lang" attribute is absent only if the language
indicated as the remote BXXP peer's first choice is used.
</p>

<p>

</p>

<p>
In addition,
a BXXP peer sends an "error" element whenever:

<ul class=3D"text">

<li>
it receives a "MSG" message containing a poorly-formed or
unexpected element;
</li>

<li>
it receives a "MSG" message asking to close a channel=20
(or release the BXXP session)
and it declines to do so; or
</li>

<li>
a BXXP session is established,
the BXXP peer is acting in the listening role,
and that BXXP peer is unavailable
(in this case,
the BXXP acting in the listening role does not send a "greeting" =
element).
</li>

</ul>


In the final case,
both BXXP peers terminate the session,
and it is recommended that a diagnostic entry be logged by both BXXP
peers.
</p>

<p>

</p>

<h4><a name=3D"session.estab">2.4</a>&nbsp;Session Establishment and =
Release</h4>

<p>
When a BXXP session is established,
each BXXP peer signifies its availability by immediately sending a
positive reply with a message number of zero on channel zero that =
contains a
"greeting" element, e.g.,
</p>
</font><pre>
    L: &lt;wait for incoming connection>
    I: &lt;open connection>
    L: RPY 0 0 . 0 86
    L:
    L: &lt;greeting>
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/TLS' />
    L: &lt;/greeting>
    L: END
    I: RPY 0 0 . 0 16
    I:
    I: &lt;greeting />
    I: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
Alternatively,
if the BXXP peer acting in the listening role is unavailable,
it sends a negative reply,
e.g.,
</p>
</font><pre>
    L: &lt;wait for incoming connection>
    I: &lt;open connection>
    L: ERR 0 0 . 0 24
    L:
    L: &lt;error code=3D'421' />
    L: END
    I: RPY 0 0 . 0 16
    I:
    I: &lt;greeting />
    I: END
    I: &lt;close connection>
    L: &lt;close connection>
    L: &lt;wait for next connection>
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
and the "greeting" element sent by the BXXP peer acting in
the initiating role is ignored.
It is recommended that a diagnostic entry be logged by both BXXP
peers.
</p>

<p>
Note that both of these examples imply that the BXXP peer in the
initiating role waits until the BXXP peer in the listening role sends =
its
greeting &#151; this is an artifact of the presentation;
in fact,
both BXXP peers send their replies independently.
</p>

<p>
When a BXXP peer wants to release the BXXP session,
it sends a "close" element with a zero-valued "number" attribute on
channel zero.
The other BXXP peer indicates its willingness by sending an "ok"
element in a positive reply,
e.g.,
</p>
</font><pre>
    C: MSG 0 1 . 16 24
    C:
    C: &lt;close code=3D'200' />
    C: END
    S: RPY 0 1 . 287 10
    S:
    S: &lt;ok />
    S: END
    I: &lt;close connection>
    L: &lt;close connection>
    L: &lt;wait for next connection>
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
Alternatively,
if the other BXXP doesn't want to release the BXXP session,
the exchange might look like this:
</p>
</font><pre>
    C: MSG 0 1 . 16 24
    C:
    C: &lt;close code=3D'200' />
    C: END
    S: ERR 0 1 . 287 43
    S:
    S: &lt;error code=3D'550'>still working&lt;/error>
    L: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
If session release is declined,
the BXXP session should not be terminated,
if possible.
</p>

<p>

</p>

<h4><a name=3D"transport.mapping">2.5</a>&nbsp;Transport Mappings</h4>

<p>
All transport interactions occur in the context of a session &#151;
a mapping onto a particular transport service.
Accordingly,
this memo defines the requirements that must be satisified by any
document describing how a particular transport service realizes a BXXP
session.
</p>

<h4><a name=3D"anchor8">2.5.1</a>&nbsp;Session Management</h4>

<p>
A BXXP session is connection-oriented.
A mapping document must define:

<ul class=3D"text">

<li>
how a BXXP session is established;
</li>

<li>
how a BXXP peer is identified as acting in the listening role;
</li>

<li>
how a BXXP peer is identified as acting in the initiating role;
</li>

<li>
how a BXXP session is released; and,
</li>

<li>
how a BXXP session is terminated.
</li>

</ul>

</p>

<h4><a name=3D"anchor9">2.5.2</a>&nbsp;Message Exchange</h4>

<p>
A BXXP session is message-oriented.
A mapping document must define:

<ul class=3D"text">

<li>
how messages are reliably sent and received;
</li>

<li>
how messages on the same channel are received in the same order as
they were sent; and,
</li>

<li>
how messages on different channels are sent without ordering constraint.
</li>

</ul>

</p>

<p>

</p>

<h4><a name=3D"anchor10">2.6</a>&nbsp;Parallelism</h4>

<h4><a name=3D"anchor11">2.6.1</a>&nbsp;Within a Single Channel</h4>

<p>
A BXXP peer acting in the client role may send multiple "MSG" messages
on the same channel without waiting to receive the corresponding
replies.
</p>

<p>
A BXXP peer acting in the server role must process all "MSG"
messages for a given channel in the same order as they are received.
As a consequence,
the BXXP peer must generate replies
in the same order as the corresponding "MSG" messages are received on
a given channel.
</p>

<h4><a name=3D"anchor12">2.6.2</a>&nbsp;Between Different Channels</h4>

<p>
A BXXP peer acting in the client role may send multiple "MSG" messages
on different channels without waiting to receive the corresponding
replies.
</p>

<p>
A BXXP peer acting in the server role may process "MSG" messages
received on different channels in any order it chooses.
As a consequence,
although the replies for a given channel appear to be generated in the
same order in which the corresponding "MSG" messages are received,
there is no ordering constraint for replies on different channels.
</p>

<h4><a name=3D"anchor13">2.6.3</a>&nbsp;Pre-emptive Replies</h4>

<p>
A BXXP peer acting in the server role may send a negative reply
before it receives the final "MSG" frame of a message.
If it does so,
that BXXP peer is obliged to ignore any subsequent "MSG" frames for
that message,
up to and including the final "MSG" frame.
</p>

<p>
If a BXXP peer acting in the client role receives a negative reply
before it sends the final "MSG" frame for a message,
then it is required to send a "MSG" frame with a continuation status
of complete (".") and having a zero-length payload.
</p>

<h4><a name=3D"anchor14">2.6.4</a>&nbsp;Interference</h4>

<p>
If the processing of a particular message has sequencing impacts on
other messages (either intra-channel or inter-channel),
then the corresponding profile should define this behavior, e.g.,
a profile whose messages alter the underlying transport mapping.
</p>

<p>

</p>

<h4><a name=3D"anchor15">2.7</a>&nbsp;Peer-to-Peer Behavior</h4>

<p>
BXXP is peer-to-peer &#151; as such both peers must be
prepared to receive all messages defined in this memo.
Accordingly,
an initiating BXXP peer capable of acting only in the client role must
behave gracefully if it receives a "MSG" message.
Accordingly,
all profiles must provide an appropriate error message for replying
to unexpected "MSG" messages.
</p>

<p>
As a consequence of the peer-to-peer nature of BXXP,
message numbers are unidirectionally-significant.
That is,
the message numbers in "MSG" messages sent by a BXXP peer acting in the
initiating role are unrelated to the message numbers in "MSG" messages
sent by a BXXP peer acting in the listening role.
</p>

<p>
For example, these two messages
</p>
</font><pre>
    I: MSG 0 1 . 16 96
    I:=20
    I: &lt;start number=3D'1'>
    I:    &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>=20
    I: &lt;/start>
    I: END
    L: MSG 0 1 . 287 92
    L:=20
    L: &lt;start number=3D'2'>
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/IMXP' />
    L: &lt;/start>
    L: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
refer to different messages sent on channel zero.
</p>

<a name=3D"anchor16"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>3.&nbsp;Transport Security</h3>

<p>
When a BXXP session is established,
plaintext transfer,
without privacy,
is provided.
Accordingly,
transport security in BXXP is achieved using an initial tuning profile.
</p>

<p>
This document defines one profile:

<ul class=3D"text">

<li>
the TLS transport security profile,
based on <a href=3D"#RFC2246">TLS version one</a>[4].
</li>

</ul>

Other profiles may be defined and deployed on a bilateral basis.
Note that because of their intimate relationship with the tranpsort =
service,
a given transport security profile tends to be relevant to a single
transort mapping (c.f., <a href=3D"#transport.mapping">Transport =
Mappings</a>).
</p>

<p>
When a channel associated with transport security begins the
underlying negotiation process,
all channels (including channel zero) are closed on the BXXP session.
Accordingly,
upon completion of the negotiation process,
regardless of its outcome,
a new greeting is issued by both BXXP peers.
</p>

<p>

</p>

<p>
A BXXP peer may choose to issue different greetings
based on whether privacy is in use, e.g.,
</p>
</font><pre>
    L: &lt;wait for incoming connection>
    I: &lt;open connection>
    L: RPY 0 0 . 0 86
    L:
    L: &lt;greeting>
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/TLS' />
    L: &lt;/greeting>
    L: END
    I: RPY 0 0 . 0 16
    I:
    I: &lt;greeting />
    I: END
    I: MSG 0 1 . 16 122
    I:=20
    I: &lt;start number=3D'1'>
    I:    &lt;profile uri=3D'http://xml.resource.org/profiles/TLS'>
    I:        &lt;ready />
    I:    &lt;/profile>
    I: &lt;/start>
    I: END
    L: RPY 0 1 . 86 85
    L:
    L: &lt;profile uri=3D'http://xml.resource.org/profiles/TLS'>
    L:     &lt;proceed />
    L: &lt;/profile>
    L: END

        ... successful transport security negotiation ...

    L: RPY 0 0 . 0 227
    L:
    L: &lt;greeting>
    L:    &lt;profile
    L:       uri=3D'http://xml.resource.org/profiles/sasl/ANONYMOUS' />
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/IMXP' />
    L: &lt;/greeting>
    L: END
    I: RPY 0 0 . 0 16
    I:
    I: &lt;greeting />
    I: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>

</p>

<p>
Of course,
not all BXXP peers need be as single-minded:
</p>
</font><pre>
    L: &lt;wait for incoming connection>
    I: &lt;open connection>
    L: RPY 0 0 . 0 287
    L:
    L: &lt;greeting>
    L:    &lt;profile
    L:       uri=3D'http://xml.resource.org/profiles/sasl/ANONYMOUS' />
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/IMXP' />
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/TLS' />
    L: &lt;/greeting>
    L: END
    I: RPY 0 0 . 0 16
    I:
    I: &lt;greeting />
    I: END
    I: MSG 0 1 . 16 122
    I:=20
    I: &lt;start number=3D'1'>
    I:    &lt;profile uri=3D'http://xml.resource.org/profiles/TLS'>
    I:        &lt;ready />
    I:    &lt;/profile>
    I: &lt;/start>
    I: END
    L: RPY 0 1 . 287 85
    L:
    L: &lt;profile uri=3D'http://xml.resource.org/profiles/TLS'>
    L:     &lt;proceed />
    L: &lt;/profile>
    L: END

        ... failed transport security negotiation ...

    L: RPY 0 0 . 0 287
    L:
    L: &lt;greeting>
    L:    &lt;profile
    L:       uri=3D'http://xml.resource.org/profiles/sasl/ANONYMOUS' />
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/IMXP' />
    L:    &lt;profile uri=3D'http://xml.resource.org/profiles/TLS' />
    L: &lt;/greeting>
    L: END
    I: RPY 0 0 . 0 16
    I:
    I: &lt;greeting />
    I: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<h4><a name=3D"tls.profile">3.1</a>&nbsp;The TLS Transport Security =
Profile</h4>

<p>
<a href=3D"#tls.definition">Registration: TLS Transport Security =
Profile</a> contains the registration for this
profile.
</p>

<h4><a name=3D"anchor17">3.1.1</a>&nbsp;Profile Identification and =
Initialization</h4>

<p>
The TLS transport security profile is identified as:
</p>
</font><pre>
    http://xml.resource.org/profiles/TLS
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
in the BXXP "profile" element during channel creation.
</p>

<p>
During channel creation,
the corresponding "profile" element in the BXXP "start" element may
contain a "ready" element.
If channel creation is successful,
then before sending the corresponding reply,
the BXXP peer processes the "ready" element and includes the resulting
response in the reply,
e.g.,
</p>
</font><pre>
    C: MSG 0 1 . 16 122
    C:
    C: &lt;start number=3D'1'>
    C:    &lt;profile uri=3D'http://xml.resource.org/profiles/TLS'>
    C:        &lt;ready />
    C:    &lt;/profile>
    C: &lt;/start>
    C: END
    S: RPY 0 1 . 86 85
    S:
    S: &lt;profile uri=3D'http://xml.resource.org/profiles/TLS'>
    S:     &lt;proceed />
    S: &lt;/profile>
    S: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
Note that it is possible for the channel to be created,
but for the encapsulated operation to fail, e.g.,
</p>
</font><pre>
    C: MSG 0 1 . 16 137
    C:
    C: &lt;start number=3D'1'>
    C:    &lt;profile uri=3D'http://xml.resource.org/profiles/TLS'>
    C:        &lt;ready version=3D"oops" />
    C:    &lt;/profile>
    C: &lt;/start>
    C: END
    S: RPY 0 1 . 86 158
    S:
    S: &lt;profile uri=3D'http://xml.resource.org/profiles/TLS'>
    S:     &lt;error code=3D'501'>version attribute
    S: poorly formed in &amp;lt;ready&amp;gt; element&lt;/error>
    S: &lt;/profile>
    S: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
In this case,
a positive reply is sent (as channel creation succeeded),
but the encapsulated response contains an indication as to why the
operation failed.
</p>

<h4><a name=3D"anchor18">3.1.2</a>&nbsp;Message Syntax</h4>

<p>
<a href=3D"#tls.dtd">TLS Transport Security Profile DTD</a> defines the =
messages that are used in the
TLS transport security profile.
</p>

<h4><a name=3D"tls.messages">3.1.3</a>&nbsp;Message Semantics</h4>

<h4><a name=3D"anchor19">3.1.3.1</a>&nbsp;The Ready Message</h4>

<p>
The "ready" element has an optional "version" attribute and no content:

<ul class=3D"text">

<li>
the "version" element defines the earliest version of TLS
acceptable for use.
</li>

</ul>

</p>

<p>
When a BXXP peer sends the "ready" element,
it must not send any further traffic on any channel until a =
corresponding
reply is received;
similarly,
before processing a "ready" element,
the receiving BXXP peer waits until any pending replies have been
generated and sent.
</p>

<h4><a name=3D"anchor20">3.1.3.2</a>&nbsp;The Proceed Message</h4>

<p>
The "proceed" element has no attributes and no content.
It is sent as a reply to the "ready" element.
When a BXXP peer receives the "ready" element,
it begins the underlying negotiation process for transport security.
</p>

<a name=3D"anchor21"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>4.&nbsp;User Authentication</h3>

<p>
When a BXXP session is established,
anonymous access,
without trace information,
is provided.
Accordingly,
user authentication in BXXP is achieved using an initial tuning profile.
</p>

<p>
This document defines a family of profiles based on SASL mechanisms:

<ul class=3D"text">

<li>
each mechanism in the
<a =
href=3D"http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms">IAN=
A SASL registry</a>
has an associated profile.
</li>

</ul>

Other profiles may be defined and deployed on a bilateral basis.
</p>

<p>
Whenever a successful authentication occurs,
on any channel,
the authenticated identity is updated for all existing and future
channels on the BXXP session;
further,
no additional attempts at authentication are allowed.
</p>

<p>
Note that regardless of transport security and user authentication,
authorization is an internal matter for each BXXP peer.
As such,
each peer may choose to restrict the operations it allows based on the
authentication credentials provided
(i.e., unauthorized operations might be rejected with error code 530).
</p>

<p>

</p>

<h4><a name=3D"sasl.profiles">4.1</a>&nbsp;The SASL Family of =
Profiles</h4>

<p>
<a href=3D"#sasl.definition">Registration: SASL Family of Profiles</a> =
contains the registration for this
profile.
</p>

<p>
Note that SASL may provide both user authentication and transport =
security.
Once transport security is successfully negotiated for a BXXP session,
then a SASL security layer must not be negotiated;
similarly,
once any SASL negotiation is successful,
a transport security profile must not begin its underlying negotiation
process.
</p>

<p>
Section 4 of the SASL <a href=3D"#RFC2222">specification</a>[5]
requires the following information be supplied by a protocol
definition:

<blockquote class=3D"text"><dl>

<dt>service name:</dt>
<dd>
"bxxp"
</dd>

<dt>initiation sequence:</dt>
<dd>
Creating a channel using a BXXP profile
corresponding to a SASL mechanism starts the exchange.
An optional parameter corresponding to the "initial response" sent by
the client is carried within a "blob" element during channel
creation.
</dd>

<dt>exchange sequence:</dt>
<dd>
"Challenges" and "responses" are
carried in exchanges of the "blob" element.
The "status" attribute of the "blob" element is used both by a server
indicating a successful completion of the exchange,=20
and a client aborting the exchange,
The server indicates failure of the exchange by sending an "error" =
element.
</dd>

<dt>security layer negotiation:</dt>
<dd>
When a security layer starts
negotiation,
all channels (including channel zero) are closed on the BXXP session.
Accordingly,
upon completion of the negotiation process,
regardless of its outcome,
a new greeting is issued by both BXXP peers.
<br>

If a security layer is successfully negotiated,
it takes effect immediately following the message that concludes the
server's successful completion reply.
</dd>

<dt>use of the authorization identity:</dt>
<dd>
This is made
available to all channels for the duration of the BXXP session.
</dd>

</dl></blockquote>

</p>

<p>

</p>

<h4><a name=3D"anchor22">4.1.1</a>&nbsp;Profile Identification and =
Initialization</h4>

<p>
Each SASL mechanism registered with the IANA is identified as:
</p>
</font><pre>
    http://xml.resource.org/profiles/sasl/MECHANISM
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
where "MECHANISM" is the token assigned to that mechanism
by the IANA.
</p>

<p>
Note that during channel creation,
a BXXP peer may provide multiple profiles to the remote peer, e.g.,
</p>
</font><pre>
    C: MSG 0 1 . 16 173
    C:
    C: &lt;start number=3D'1'>
    C:    &lt;profile
    C:       uri=3D'http://xml.resource.org/profiles/sasl/ANONYMOUS' />
    C:    &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    C: &lt;/start>
    C: END
    S: RPY 0 1 . 287 63
    S:
    S: &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' />
    S: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
During channel creation,
the corresponding "profile" element in the BXXP "start" element may
contain a "blob" element.
Note that it is possible for the channel to be created,
but for the encapsulated operation to fail, e.g.,
</p>
</font><pre>
    C: MSG 0 1 . 16 147
    C:
    C: &lt;start number=3D'1'>
    C:    &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP'>
    C:        &lt;blob>AGJsb2NrbWFzdGVy&lt;/blob>
    C:    &lt;/profile>
    C: &lt;/start>
    C: END
    S: RPY 0 1 . 287 142
    S:
    S: &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP'>
    S:     &lt;error code=3D'534'>authentication mechanism is
    S: too weak&lt;/error>
    S: &lt;/profile>
    S: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
In this case,
a positive reply is sent (as channel creation succeeded),
but the encapsulated response contains an indication as to why the
operation failed.
</p>

<p>
Otherwise,
the server sends a challenge (or signifies success), e.g.,
</p>
</font><pre>
    C: MSG 0 1 . 16 147
    C:
    C: &lt;start number=3D'1'>
    C:    &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP'>
    C:        &lt;blob>AGJsb2NrbWFzdGVy&lt;/blob>
    C:    &lt;/profile>
    C: &lt;/start>
    C: END
    S: RPY 0 1 . 287 146
    S:
    S: &lt;profile uri=3D'http://xml.resource.org/profiles/sasl/OTP'>
    S:     =
&lt;blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=3D&lt;/blob>
    S: &lt;/profile>
    S: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
If a challenge is received,
then the client responds and awaits another reply,
e.g.,
</p>
</font><pre>
    C: MSG 1 0 . 0 69
    C:
    C: &lt;blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n&lt;/blob>
    C: END
    S: RPY 1 0 . 0 15
    S:
    S: &lt;blob status=3D'complete' />
    S: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
Of course,
the client could abort the authentication process by sending
"&lt;blob status=3D'abort' />" instead.
</p>

<p>
Alternatively,
the server might reject the response with an error:
e.g.,
</p>
</font><pre>
    C: MSG 1 0 . 0 69
    C:
    C: &lt;blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n&lt;/blob>
    C: END
    S: ERR 1 1 . 0 24
    S:
    S: &lt;error code=3D'535' />
    S: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
Finally,
depending on the SASL mechanism,
an initialization element may be exchanged unidirectionally during
channel creation, e.g.,
</p>
</font><pre>
    C: MSG 0 1 . 16 109
    C:
    C: &lt;start number=3D'1'>
    C:    &lt;profile
    C:        uri=3D'http://xml.resource.org/profiles/sasl/CRAM-MD5' />
    C: &lt;/start>
    C: END
    S: RPY 0 1 . 287 150
    S:
    S: &lt;profile =
uri=3D'http://xml.resource.org/profiles/sasl/CRAM-MD5'>
    S: &lt;blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
                                                              &lt;/blob>
    S: &lt;/profile>
    S: END
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>
Note that this example implies that the "blob" element in
the server's reply appears on two lines &#151; this is an artifact of
the presentation;
in fact,
only one line is used.
</p>

<h4><a name=3D"anchor23">4.1.2</a>&nbsp;Message Syntax</h4>

<p>
<a href=3D"#sasl.dtd">SASL Family of Profiles DTD</a> defines the =
messages that are used for
each profile in the SASL family.
</p>

<p>
Note that because many SASL mechanisms exchange binary data,
the content of the "blob" element is always a base64-encoded string.
</p>

<p>

</p>

<h4><a name=3D"sasl.messages">4.1.3</a>&nbsp;Message Semantics</h4>

<p>
The "blob" element has an optional "status" attribute,
and arbitrary octets as its content:

<ul class=3D"text">

<li>
the "status" attribute, if present, takes one of three values:

<blockquote class=3D"text"><dl>

<dt>abort:</dt>
<dd>
used by a client to indicate that it is aborting
the authentication process;
</dd>

<dt>complete:</dt>
<dd>
used by a server to indicate that the exchange is
complete and successful; or,
</dd>

<dt>continue:</dt>
<dd>
used by either a client or server, otherwise.
</dd>

</dl></blockquote>

</li>

</ul>

</p>

<p>
Finally,
note that SASL's EXTERNAL mechanism works with an "external
authentication" service,
which is provided by one of:

<ul class=3D"text">

<li>
a transport security profile,
capable of providing authentication information
(e.g., <a href=3D"#tls.profile">The TLS Transport Security Profile</a>),
being active on the connection;
</li>

<li>
a network service,
capable of providing strong authentication
(e.g., <a href=3D"#RFC2401">IPSec</a>[11]),
underlying the connection;
or,
</li>

<li>
a locally-defined security service.
</li>

</ul>
For authentication to succeed,
two conditions must hold:

<ul class=3D"text">

<li>
an external authentication service must be active; and,
</li>

<li>
if present,
the authentication identity must be consistent with
the credentials provided by the external authentication service
(if the authentication identity is empty,
then an authorization identity is automatically derived from the
credentials provided by the external authentication service).
</li>

</ul>

</p>

<a name=3D"profile.registration"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>5.&nbsp;Profile Registration Template</h3>

<p>
When a profile is registered,
the following information is supplied:

<blockquote class=3D"text"><dl>

<dt>Profile Identification:</dt>
<dd>
specify a
<a href=3D"#RFC2396">URI</a>[9] that authoritatively identifies this
profile.
</dd>

<dt>Elements Exchanged during Channel Creation:</dt>
<dd>
specify
the elements that may be exchanged during channel creation
(If the profile doesn't exchange XML elements,
then initialization information may not be exchanged during channel
creation).
Regardless,
the size of any initialization element may not exceed 4K octets.
</dd>

<dt>Messages starting one-to-one exchanges:</dt>
<dd>
specify the datatypes that
may be present when an exchange starts.
</dd>

<dt>Messages in positive replies:</dt>
<dd>
specify the
datatypes that may be present in a positive reply.
</dd>

<dt>Messages in negative replies:</dt>
<dd>
specify the
datatypes that may be present in a negative reply.
</dd>

<dt>Messages in one-to-many exchanges:</dt>
<dd>
specify the
datatypes that may be present in a one-to-many exchange.
</dd>

<dt>Message Syntax:</dt>
<dd>
specify the syntax of the datatypes
exchanged by the profile.
</dd>

<dt>Message Semantics:</dt>
<dd>
specify the semantics of the
datatypes exchanged by the profile.
</dd>

</dl></blockquote>

Note that "datatype" refers to any MIME media type,
whilst "element" refers to any well-formed XML document.
</p>

<a name=3D"initial.definitions"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>6.&nbsp;Initial Profile Registrations</h3>

<h4><a name=3D"channelZ.definition">6.1</a>&nbsp;BXXP Channel =
Management</h4>

<p>

<blockquote class=3D"text"><dl>

<dt>Profile Identification:</dt>
<dd>
not applicable
</dd>

<dt>Elements Exchanged during Channel Creation:</dt>
<dd>
not applicable
</dd>

<dt>Messages starting one-to-one exchanges:</dt>
<dd>
"start" or "close"
</dd>

<dt>Messages in positive replies:</dt>
<dd>
"greeting",
"profile", or "ok"
</dd>

<dt>Messages in negative replies:</dt>
<dd>
"error"
</dd>

<dt>Messages in one-to-many exchanges:</dt>
<dd>
none
</dd>

<dt>Message Syntax:</dt>
<dd>
c.f., <a href=3D"#bxxp.dtd">BXXP Channel Management DTD</a>
</dd>

<dt>Message Semantics:</dt>
<dd>
c.f., <a href=3D"#bxxp.messages">Message Semantics</a>
</dd>

</dl></blockquote>

</p>

<p>

</p>

<h4><a name=3D"bxxp.dtd">6.2</a>&nbsp;BXXP Channel Management DTD</h4>
</font><pre>
&lt;!--
  DTD for BXXP Channel Management, as of 2000-09-04


  Refer to this DTD as:

    &lt;!ENTITY % BXXP PUBLIC "-//Blocks//DTD BXXP//EN"
               "http://xml.resource.org/profiles/BXXP/bxxp.dtd">
    %BXXP;
  -->


&lt;!--
  DTD data types:

        entity        syntax/reference     example
        =3D=3D=3D=3D=3D=3D        =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D     =
=3D=3D=3D=3D=3D=3D=3D
    a channel number
        CHAN          1..2147483647        1

    authoritative profile identification
        URI          c.f., [RFC-2396]      http://invisible.net/

    one or more feature tokens, seperated by space
        FTRS         NMTOKENS              "magic"

    zero or more language tags
        LOCS         NMTOKENS              "en-US"

    a language tag
        LANG         c.f., [RFC-1766]      "en", "en-US", etc.

    a 3-digit reply code
        XYZ           [1-5][1-9][1-9]      500
-->


&lt;!ENTITY % CHAN       "CDATA">
&lt;!ENTITY % URI        "CDATA">
&lt;!ENTITY % FTRS       "NMTOKENS">
&lt;!ENTITY % LOCS       "NMTOKEN">
&lt;!ENTITY % LANG       "NMTOKEN">
&lt;!ENTITY % XYZ        "CDATA">




&lt;!--
  BXXP messages

     role       MSG         RSP         ERR
    =3D=3D=3D=3D=3D=3D=3D     =3D=3D=3D         =3D=3D=3D         =
=3D=3D=3D
    I and L                 greeting    error

    I or L      start       profile     error=20

    I or L      close       ok          error
  -->


&lt;!ELEMENT greeting    (profile)*>
&lt;!ATTLIST greeting
          features    %FTRS;            #IMPLIED
          localize    %LOCS;            "i-default">

&lt;!ELEMENT start       (profile)+>
&lt;!ATTLIST start
          number      %CHAN;             #REQUIRED
          serverName  CDATA              #IMPLIED>

&lt;!-- profile element is empty if contained in a greeting -->
&lt;!ELEMENT profile     ANY>
&lt;!ATTLIST profile
          uri         %URI;              #REQUIRED>

&lt;!ELEMENT close       (#PCDATA)*>
&lt;!ATTLIST close
          number      %CHAN;             "0"
          code        %XYZ;              #REQUIRED
          xml:lang    %LANG;             #IMPLIED>

&lt;!ELEMENT ok          EMPTY>

&lt;!ELEMENT error       (#PCDATA)*>
&lt;!ATTLIST error
          code        %XYZ;              #REQUIRED
          xml:lang    %LANG;             #IMPLIED>

</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>

</p>

<h4><a name=3D"tls.definition">6.3</a>&nbsp;Registration: TLS Transport =
Security Profile</h4>

<p>

<blockquote class=3D"text"><dl>

<dt>Profile Identification:</dt>
<dd>
<a =
href=3D"http://xml.resource.org/profiles/TLS">http://xml.resource.org/pro=
files/TLS</a>
</dd>

<dt>Elements Exchanged during Channel Creation:</dt>
<dd>
"ready"
</dd>

<dt>Messages starting one-to-one exchanges:</dt>
<dd>
"ready"
</dd>

<dt>Messages in positive replies:</dt>
<dd>
"proceed"
</dd>

<dt>Messages in negative replies:</dt>
<dd>
"error"
</dd>

<dt>Messages in one-to-many exchanges:</dt>
<dd>
none
</dd>

<dt>Message Syntax:</dt>
<dd>
c.f., <a href=3D"#tls.dtd">TLS Transport Security Profile DTD</a>
</dd>

<dt>Message Semantics:</dt>
<dd>
c.f., <a href=3D"#tls.messages">Message Semantics</a>
</dd>

</dl></blockquote>

</p>

<p>

</p>

<h4><a name=3D"tls.dtd">6.4</a>&nbsp;TLS Transport Security Profile =
DTD</h4>
</font><pre>
&lt;!--
  DTD for the TLS Transport Security Profile, as of 2000-09-04


  Refer to this DTD as:

    &lt;!ENTITY % TLS PUBLIC "-//Blocks//DTD TLS//EN"
               "http://xml.resource.org/profiles/TLS/tls.dtd">
    %TLS;
  -->


&lt;!--
  TLS messages

     role       MSG         RSP         ERR
    =3D=3D=3D=3D=3D=3D      =3D=3D=3D         =3D=3D=3D         =
=3D=3D=3D
    I or L      ready       proceed     error        =20
  -->


&lt;!ELEMENT ready       EMPTY>
&lt;!ATTLIST ready
          version     CDATA              "1">

&lt;!ELEMENT proceed     EMPTY>

</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<p>

</p>

<h4><a name=3D"sasl.definition">6.5</a>&nbsp;Registration: SASL Family =
of Profiles</h4>

<p>

<blockquote class=3D"text"><dl>

<dt>Profile Identification:</dt>
<dd>
<a =
href=3D"http://xml.resource.org/profiles/sasl/MECHANISM">http://xml.resou=
rce.org/profiles/sasl/MECHANISM</a>,
where "MECHANISM" is a token registered with the
<a href=3D"http://www.iana.org/">IANA</a>
</dd>

<dt>Elements Exchanged during Channel Creation:</dt>
<dd>
"blob"
</dd>

<dt>Messages starting one-to-one exchanges:</dt>
<dd>
"blob"
</dd>

<dt>Messages in positive replies:</dt>
<dd>
"blob"
</dd>

<dt>Messages in negative replies:</dt>
<dd>
"error"
</dd>

<dt>Messages in one-to-many exchanges:</dt>
<dd>
none
</dd>

<dt>Message Syntax:</dt>
<dd>
c.f., <a href=3D"#sasl.dtd">SASL Family of Profiles DTD</a>
</dd>

<dt>Message Semantics:</dt>
<dd>
c.f., <a href=3D"#sasl.messages">Message Semantics</a>
</dd>

</dl></blockquote>

</p>

<p>

</p>

<h4><a name=3D"sasl.dtd">6.6</a>&nbsp;SASL Family of Profiles DTD</h4>
</font><pre>
&lt;!--
  DTD for the SASL Family of Profiles, as of 2000-09-04


  Refer to this DTD as:

    &lt;!ENTITY % SASL PUBLIC "-//Blocks//DTD SASL//EN"=20
               "http://xml.resource.org/profiles/sasl/sasl.dtd">
    %SASL;
  -->


&lt;!--
  SASL messages

     role       MSG         RSP         ERR
    =3D=3D=3D=3D=3D=3D      =3D=3D=3D         =3D=3D=3D         =
=3D=3D=3D
    I or L      blob        blob        error
  -->


&lt;!ELEMENT blob        (#PCDATA)*>
&lt;!ATTLIST blob
          xml:space   (default|preserve)
                                        "preserve"
          status      (abort|complete|continue)
                                         "continue">

</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<a name=3D"reply-codes"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>7.&nbsp;Reply Codes</h3>
</font><pre>
code    meaning
=3D=3D=3D=3D    =3D=3D=3D=3D=3D=3D=3D
421     service not available

450     requested action not taken
        (e.g., lock already in use)

451     requested action aborted
        (e.g., local error in processing)

454     temporary authentication failure

500     general syntax error
        (e.g., poorly-formed XML)

501     syntax error in parameters
        (e.g., non-valid XML)=20

504     parameter not implemented

530     authentication required

534     authentication mechanism insufficient
        (e.g., too weak, sequence exhausted, etc.)

535     authentication failure

537     action not authorized for user

538     authentication mechanism requires encryption

550     requested action not taken
        (e.g., no requested profiles are acceptable)

553     parameter invalid

554     transaction failed
        (e.g., policy violation)
</pre><font face=3D"verdana, helvetica, arial, sans-serif" size=3D"2">

<a name=3D"anchor24"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>8.&nbsp;Security Considerations</h3>

<p>
The BXXP framing mechanism,
per se,
provides no protection against attack;
however,
judicious use of initial tuning profiles provides varying degrees of
assurance:

<ol class=3D"text">

<li>
If one of the profiles from the SASL family is used,
refer to <a href=3D"#RFC2222">[5]</a>'s Section 9 for a discussion of
security considerations.
</li>

<li>
If the TLS transport security profile is used
(or if a SASL security layer is negotiated),
then:

<ol class=3D"text">

<li>
A man-in-the-middle may remove the security-related profiles
from the BXXP greeting or generate a negative reply to the
"ready" element of the TLS transport security profile.
A BXXP peer may be configurable to refuse to proceed without an
acceptable level of privacy.
</li>

<li>
A man-in-the-middle may cause a down-negotiation to the weakest
cipher suite available.
A BXXP peer should be configurable to refuse weak cipher suites.
</li>

<li>
A man-in-the-middle may modify any protocol exchanges prior to
a successful negotiation.
Upon completing the negotiation,
a BXXP peer must discard previously cached information about the BXXP
session.
</li>

</ol>

As different TLS ciphersuites provide varying levels of security,
administrators should carefully choose which ciphersuites are =
provisioned.
</li>

</ol>

</p>

<a name=3D"anchor25"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>9.&nbsp;IANA Considerations</h3>

<p>
The IANA registers "bxxp" as a <a href=3D"#RFC2078">GSSAPI</a>[12]
service name,
as specified in <a href=3D"#sasl.profiles">The SASL Family of =
Profiles</a>.
</p>

<p>
The IANA maintains a list of BXXP profiles that are defined in any
standards-track documents.
</p>

<p>
The IANA makes the registrations specified in
<a href=3D"#tls.definition">Registration: TLS Transport Security =
Profile</a> and <a href=3D"#sasl.definition">Registration: SASL Family =
of Profiles</a>.
It is recommended that the IANA register these profiles using the IANA
as a URI-prefix,
and populate those URIs with the respective profile registrations.
</p>
<a name=3D"rfc.references"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>
References</h3>
<table width=3D"99%" border=3D"0">
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"BEEP-DESIGN">[1]</a></b></td>
<td class=3D"author-text"><a href=3D"mailto:mrose@invisible.net">Rose, =
M.T.</a>, "<a =
href=3D"http://www.ietf.org/internet-drafts/draft-mrose-beep-design-00.tx=
t">On the Design of Application Protocols</a>", =
draft-mrose-beep-design-00 (work in progress), July 2000.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"RFC2045">[2]</a></b></td>
<td class=3D"author-text"><a href=3D"mailto:ned@innosoft.com">Freed, =
N.</a> and <a href=3D"mailto:nsb@nsb.fv.com">N. Borenstein</a>, "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc2045.txt">Multipurpose Internet =
Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>", =
RFC 2045, November 1996.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"W3C.XML">[3]</a></b></td>
<td class=3D"author-text"><a href=3D"http://www.w3c.org">World Wide Web =
Consortium</a>, "<a =
href=3D"http://www.w3.org/TR/1998/REC-xml-19980210">Extensible Markup =
Language (XML) 1.0</a>", W3C XML, February 1998.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"RFC2246">[4]</a></b></td>
<td class=3D"author-text"><a =
href=3D"mailto:tdierks@certicom.com">Dierks, T.</a>, <a =
href=3D"mailto:callen@certicom.com">Allen, C.</a>, <a =
href=3D"mailto:treese@openmarket.com">Treese, W.</a>, <a =
href=3D"mailto:">Karlton, P. L.</a>, <a =
href=3D"mailto:freier@netscape.com">Freier, A. O.</a> and <a =
href=3D"mailto:pck@netcom.com">P. C. Kocher</a>, "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc2246.txt">The TLS Protocol Version =
1.0</a>", RFC 2246, January 1999.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"RFC2222">[5]</a></b></td>
<td class=3D"author-text"><a href=3D"mailto:jgmyers@netscape.com">Myers, =
J.G.</a>, "<a href=3D"ftp://ftp.isi.edu/in-notes/rfc2222.txt">Simple =
Authentication and Security Layer (SASL)</a>", RFC 2222, October =
1997.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"BEEP-TCPMAPPING">[6]</a></b></td>
<td class=3D"author-text"><a href=3D"mailto:mrose@invisible.net">Rose, =
M.T.</a>, "<a =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-beep-tcpmapping-01=
.txt">Mapping the BXXP Framework onto TCP</a>", =
draft-ietf-beep-tcpmapping-01 (work in progress), September =
2000.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"RFC0793">[7]</a></b></td>
<td class=3D"author-text">Postel, J., "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc793.txt">Transmission Control =
Protocol</a>", RFC 793, STD 7, Sep 1981.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"RFC1766">[8]</a></b></td>
<td class=3D"author-text">Alvestrand, H., "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc1766.txt">Tags for the =
Identification of Languages</a>", RFC 1766, March 1995.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"RFC2396">[9]</a></b></td>
<td class=3D"author-text"><a href=3D"mailto:timbl@w3.org">Berners-Lee, =
T.</a>, <a href=3D"mailto:fielding@ics.uci.edu">Fielding, R.T.</a> and =
<a href=3D"mailto:masinter@parc.xerox.com">L. Masinter</a>, "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc2396.txt">Uniform Resource =
Identifiers (URI): Generic Syntax</a>", RFC 2396, August 1998.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"RFC2444">[10]</a></b></td>
<td class=3D"author-text"><a =
href=3D"mailto:chris.newman@innosoft.com">Newman, C.</a>, "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc2444.txt">The One-Time-Password =
SASL Mechanism</a>", RFC 2444, October 1998.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"RFC2401">[11]</a></b></td>
<td class=3D"author-text"><a href=3D"mailto:kent@bbn.com">Kent, S.</a> =
and <a href=3D"mailto:rja@corp.home.net">R. Atkinson</a>, "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc2401.txt">Security Architecture =
for the Internet Protocol</a>", RFC 2401, November 1998.</td></tr>
<tr><td class=3D"author-text" valign=3D"top"><b><a =
name=3D"RFC2078">[12]</a></b></td>
<td class=3D"author-text"><a href=3D"mailto:John.Linn@ov.com">Linn, =
J.</a>, "<a href=3D"ftp://ftp.isi.edu/in-notes/rfc2078.txt">Generic =
Security Service Application Program Interface, Version 2</a>", RFC =
2078, January 1997.</td></tr>
</table>

<a name=3D"rfc.authors"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Author's Address</h3>
<table width=3D"99%" border=3D"0" cellpadding=3D"0" cellspacing=3D"0">
<tr><td class=3D"author-text">&nbsp;</td>
<td class=3D"author-text">Marshall T. Rose</td></tr>
<tr><td class=3D"author-text">&nbsp;</td>
<td class=3D"author-text">Invisible Worlds, Inc.</td></tr>
<tr><td class=3D"author-text">&nbsp;</td>
<td class=3D"author-text">1179 North McDowell Boulevard</td></tr>
<tr><td class=3D"author-text">&nbsp;</td>
<td class=3D"author-text">Petaluma, CA  94954-6559</td></tr>
<tr><td class=3D"author-text">&nbsp;</td>
<td class=3D"author-text">US</td></tr>
<tr><td class=3D"author" align=3D"right">Phone:&nbsp;</td>
<td class=3D"author-text">+1 707 789 3700</td></tr>
<tr><td class=3D"author" align=3D"right">EMail:&nbsp;</td>
<td class=3D"author-text"><a =
href=3D"mailto:mrose@invisible.net">mrose@invisible.net</a></td></tr>
<tr><td class=3D"author" align=3D"right">URI:&nbsp;</td>
<td class=3D"author-text"><a =
href=3D"http://invisible.net/">http://invisible.net/</a></td></tr>
</table>

<a name=3D"anchor26"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix A.&nbsp;Changes from draft-ietf-beep-framework-00</h3>

<p>

<ul class=3D"text">

<li>
The names of messages are renamed:

<ul class=3D"text">

<li>
"REQ" messages are now "MSG" messages; and,
</li>

<li>
"RSP" messages are now "RPY" (positive), "ANS"/"NULL"
(one-to-many), and "ERR" (negative).
</li>

</ul>

</li>

<li>
One-to-many exchanges are supported using the "ANS" message.
</li>

<li>
Commonly-used paraemters are re-ordered in the header:

<ul class=3D"text">

<li>
channel numbers appear in each frame (and are 31-bits wide); and,
</li>

<li>
serial numbers are now message numbers, and are per-channel.
</li>

</ul>

</li>

<li>
MIME "entity-headers" are now part of the payload
(and there is no longer any header-related processing associated with
them).
</li>

<li>
An IANA registration for BXXP error codes is no longer required
(the error codes are used only within this specification).
</li>

<li>
The <a href=3D"#close.message">close message</a> is also used to
release the BXXP session.
</li>

</ul>

</p>

<a name=3D"anchor27"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix B.&nbsp;Changes from draft-mrose-bxxp-framework-01</h3>

<p>

<ul class=3D"text">

<li>
Channel numbers are now 31-bits wide (instead of 8-bits).
</li>

<li>
Peers should support at least 257 concurrent channels.
</li>

<li>
The consistency rules in <a href=3D"#frame.header">Frame Header</a> now =
mandate
that any MIME entity-headers occur only in the first frame of a
message.
</li>

<li>
Discussion of the role of the entity-headers is moved to=20
<a href=3D"#frame.header">Frame Header</a>.
</li>

<li>
<a href=3D"#frame.semantics">Frame Semantics</a> requires that a BXXP =
peer close a
channel when a poorly-formed reply is received
(unless it's channel zero, in which case the BXXP session is =
terminated).
</li>

<li>
<a href=3D"#frame.semantics">Frame Semantics</a> explains that in an =
XML-based profile,
if something other than UTF-8 is sent,
then a "Content-Type:" entity-header must be present to specify the
character set.
</li>

<li>
The <a href=3D"#close.message">close</a> and
<a href=3D"#ok.message">ok</a> messages were added.
</li>

<li>
Both <a href=3D"#close.message">The Close Message</a> and <a =
href=3D"#error.message">The Error Message</a>=20
clarify that diagnostic text is not to be interpreted by programs.
</li>

<li>
<a href=3D"#profile.registration">Profile Registration Template</a> =
limits the the size of an
initialization element to 4K octets.
</li>

</ul>

</p>

<a name=3D"anchor28"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix C.&nbsp;Changes from draft-mrose-bxxp-framework-00</h3>

<p>

<ul class=3D"text">

<li>
The IPR notice is changed to be in full conformance with all
provisions of Section 10 of RFC2026.
</li>

<li>
At the beginning of <a href=3D"#messages">Messages and Frames</a>
(and in the ABNF in <a href=3D"#frame.syntax">Frame Syntax</a>)
the relationship between messages and frames is clarified.
</li>

<li>
A typo involving the final CR LF in the ABNF in
<a href=3D"#frame.syntax">Frame Syntax</a> is corrected.
</li>

<li>
In <a href=3D"#frame.header">Frame Header</a>,
the "contiguous message" rule replaces the "transport-specific" =
assertion
(the sixth rule for identifying poorly-formed frames).
</li>

<li>
At the beginning of <a href=3D"#channel.mgmt">Channel Management</a>,
an explanation of the relstionship between profiles and channels
(and the greeting and start messages) is added.
</li>

<li>
In <a href=3D"#bxxp.messages">Message Semantics</a>,
the order of the sections for the greeting and start messages is
reversed for readability.
</li>

</ul>

</p>

<a name=3D"anchor29"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix D.&nbsp;Acknowledgements</h3>

<p>
The author gratefully acknowledges the contributions of:
David Clark,
Dave Crocker,
Steve Deering,
Marco Gazzetta,
Danny Goodman,
Steve Harris,
Robert Herriot,
Ken Hirsch,
Greg Hudson,
Ben Laurie,
Carl Malamud,
Michael Mealling,
Keith McCloghrie,
Paul Mockapetris,
RL 'Bob' Morgan,
Frank Morton,
Darren New,
Chris Newman,
Joe Touch,
Paul Vixie,
Gabe Wachob,
Daniel Woods,
and,
James Woodyatt.
In particular,
Dave Crocker provided helpful suggestions on the nature of=20
segmentation in the framing protocol.
</p>
<a name=3D"rfc.copyright"><br><hr size=3D"1" shade=3D"0"></a>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"2" width=3D"30" =
height=3D"15" align=3D"right"><tr><td bgcolor=3D"#990000" =
align=3D"center" width=3D"30" height=3D"15"><a href=3D"#toc" =
CLASS=3D"link2"><font face=3D"monaco, MS Sans Serif" color=3D"#ffffff" =
size=3D"1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Full Copyright Statement</h3>
<p class=3D'copyright'>
Copyright (C) The Internet Society (2000). All Rights Reserved.</p>
<p class=3D'copyright'>
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.</p>
<p class=3D'copyright'>
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.</p>
<p class=3D'copyright'>
This document and the information contained herein is provided on an
&quot;AS IS&quot; basis and THE INTERNET SOCIETY AND THE INTERNET =
ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>
<h3>Acknowledgement</h3>
<p class=3D'copyright'>
Funding for the RFC editor function is currently provided by the
Internet Society.</p>
</font></body></html>

------=_NextPart_000_007A_01C01C4A.74CFB1A0--