idnits 2.17.1
draft-mrose-bxxp-framework-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 1475 has weird spacing: '... code mea...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 13, 2000) is 8687 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: 'RFC-2396' on line 1325
-- Looks like a reference, but probably isn't: 'RFC-1766' on line 1331
-- Looks like a reference, but probably isn't: '1-5' on line 1334
-- Looks like a reference, but probably isn't: '1-9' on line 1334
== Unused Reference: '10' is defined on line 1590, but no explicit
reference was found in the text
-- Possible downref: Normative reference to a draft: ref. '1'
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346)
** Obsolete normative reference: RFC 2222 (ref. '5') (Obsoleted by RFC
4422, RFC 4752)
-- Possible downref: Normative reference to a draft: ref. '6'
** Obsolete normative reference: RFC 793 (ref. '7') (Obsoleted by RFC 9293)
** Obsolete normative reference: RFC 1766 (ref. '8') (Obsoleted by RFC
3066, RFC 3282)
** Obsolete normative reference: RFC 2396 (ref. '9') (Obsoleted by RFC 3986)
** Obsolete normative reference: RFC 2401 (ref. '11') (Obsoleted by RFC
4301)
** Obsolete normative reference: RFC 2078 (ref. '12') (Obsoleted by RFC
2743)
-- Possible downref: Non-RFC (?) normative reference: ref. '13'
-- Possible downref: Non-RFC (?) normative reference: ref. '14'
-- Possible downref: Non-RFC (?) normative reference: ref. '15'
-- Possible downref: Non-RFC (?) normative reference: ref. '16'
-- Possible downref: Non-RFC (?) normative reference: ref. '17'
-- Possible downref: Non-RFC (?) normative reference: ref. '18'
-- Possible downref: Non-RFC (?) normative reference: ref. '19'
-- Possible downref: Non-RFC (?) normative reference: ref. '20'
-- Possible downref: Non-RFC (?) normative reference: ref. '21'
-- Possible downref: Non-RFC (?) normative reference: ref. '22'
-- Possible downref: Non-RFC (?) normative reference: ref. '23'
-- Possible downref: Non-RFC (?) normative reference: ref. '24'
-- Possible downref: Non-RFC (?) normative reference: ref. '25'
-- Possible downref: Non-RFC (?) normative reference: ref. '26'
-- Possible downref: Non-RFC (?) normative reference: ref. '27'
-- Possible downref: Non-RFC (?) normative reference: ref. '28'
-- Possible downref: Non-RFC (?) normative reference: ref. '29'
-- Possible downref: Non-RFC (?) normative reference: ref. '30'
-- Possible downref: Non-RFC (?) normative reference: ref. '31'
-- Possible downref: Non-RFC (?) normative reference: ref. '32'
-- Possible downref: Non-RFC (?) normative reference: ref. '33'
-- Possible downref: Non-RFC (?) normative reference: ref. '34'
-- Possible downref: Non-RFC (?) normative reference: ref. '35'
-- Possible downref: Non-RFC (?) normative reference: ref. '36'
Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 33 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M.T. Rose
3 Internet-Draft Invisible Worlds, Inc.
4 Expires: January 11, 2001 July 13, 2000
6 The Blocks eXtensible eXchange Protocol Framework
7 draft-mrose-bxxp-framework-01
9 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that
16 other groups may also distribute working documents as
17 Internet-Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six
20 months and may be updated, replaced, or obsoleted by other documents
21 at any time. It is inappropriate to use Internet-Drafts as reference
22 material or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at
25 http://www.ietf.org/ietf/1id-abstracts.txt.
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
30 This Internet-Draft will expire on January 11, 2001.
32 Copyright Notice
34 Copyright (C) The Internet Society (2000). All Rights Reserved.
36 Abstract
38 This memo describes a generic application protocol framework for
39 connection-oriented, asynchronous request/response interactions. The
40 framework permits multiplexing of independent request/response
41 streams within the context of a single application user-identity,
42 supporting both textual and binary messages.
44 Table of Contents
46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
47 2. The BXXP Framework . . . . . . . . . . . . . . . . . . . . 5
48 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
49 2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7
50 2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
51 2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9
52 2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 12
53 2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 13
54 2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 14
55 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15
56 2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 16
57 2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16
58 2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 18
59 2.3.1.3 The Error Message . . . . . . . . . . . . . . . . . . . . 20
60 2.4 Session Establishment and Release . . . . . . . . . . . . 21
61 2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 23
62 2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 23
63 2.5.2 Data Exchange . . . . . . . . . . . . . . . . . . . . . . 23
64 2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 24
65 2.6.1 Within a single channel . . . . . . . . . . . . . . . . . 24
66 2.6.2 Between different channels . . . . . . . . . . . . . . . . 24
67 2.6.3 Pre-emptive responses . . . . . . . . . . . . . . . . . . 24
68 2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 24
69 2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 25
70 3. Transport Security . . . . . . . . . . . . . . . . . . . . 26
71 3.1 The TLS Transport Security Profile . . . . . . . . . . . . 29
72 3.1.1 Profile Identification and Initialization . . . . . . . . 29
73 3.1.2 Request and Response Messages . . . . . . . . . . . . . . 30
74 3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 31
75 3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 31
76 3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 31
77 4. User Authentication . . . . . . . . . . . . . . . . . . . 32
78 4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 33
79 4.1.1 Profile Identification and Initialization . . . . . . . . 34
80 4.1.2 Request and Response Messages . . . . . . . . . . . . . . 36
81 4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 37
82 5. Profile Registration Template . . . . . . . . . . . . . . 38
83 6. Initial Profile Registrations . . . . . . . . . . . . . . 39
84 6.1 BXXP Channel Management . . . . . . . . . . . . . . . . . 39
85 6.2 BXXP Channel Management DTD . . . . . . . . . . . . . . . 40
86 6.3 Registration: TLS Transport Security Profile . . . . . . . 42
87 6.4 TLS Transport Security Profile DTD . . . . . . . . . . . . 43
88 6.5 Registration: SASL Family of Profiles . . . . . . . . . . 44
89 6.6 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 45
90 7. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 46
91 8. Security Considerations . . . . . . . . . . . . . . . . . 47
92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 48
93 References . . . . . . . . . . . . . . . . . . . . . . . . 49
94 Author's Address . . . . . . . . . . . . . . . . . . . . . 50
95 A. Changes from draft-mrose-bxxp-framework-00 . . . . . . . . 51
96 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 52
97 Full Copyright Statement . . . . . . . . . . . . . . . . . 53
99 1. Introduction
101 This memo describes a generic application protocol framework for
102 connection-oriented, asynchronous request/response interactions.
103 Consult [1] for a description of the framework's design principles.
105 At the core of the BXXP framework is a framing mechanism that allows
106 for peer-to-peer exchanges of requests and responses. The framing
107 mechanism permits multiplexing multiple, simultaneous and
108 independent exchanges. Requests and responses are either textual
109 (structured using XML[2]) or arbitrary (structured using MIME[3]).
111 Frames are exchanged in the context of a "channel". Each channel has
112 an associated "profile" that defines the syntax and semantics of the
113 messages exchanged. Implicit in the operation of BXXP is the notion
114 of channel management. In addition to defining BXXP's channel
115 management profile, this document defines:
117 o the TLS[4] transport security profile; and,
119 o the SASL[5] family of profiles.
121 Other profiles, such as those used for data exchange, are defined by
122 an application protocol designer. A registration template is
123 provided for this purpose.
125 2. The BXXP Framework
127 The BXXP framework is message-oriented. Arbitrary octets are
128 encapsulated within a frame and tagged as either a request or a
129 response. All interactions occur in the context of a channel -- a
130 binding to a well-defined aspect of the application, such as
131 transport security, user authentication, or data exchange.
133 A BXXP session is mapped onto an underlying transport service. A
134 separate series of documents describe how a particular transport
135 service realizes a BXXP session. For example, [6] describes how a
136 BXXP session is mapped onto a single TCP[7] connection.
138 During the creation of a channel, the requestor supplies one or more
139 proposed profiles for that channel. If the responder creates the
140 channel, it selects one of the profiles and returns it in a
141 response; otherwise, it may indicate that none of the profiles are
142 acceptable, and decline creation of the channel.
144 There are no other management capabilities for channels other than
145 creation, as channel usage falls into one of two categories:
147 initial tuning: these are used by profiles that perform
148 initialization once the BXXP session is established (e.g.,
149 negotiating the use of transport security); although several
150 request/response exchanges may be required to perform the
151 initialization, these channels become inactive early in the BXXP
152 session and remain so for the duration.
154 continuous: these are used by profiles that support data exchange;
155 typically, these channels are created after the initial tuning
156 channels have gone quiet.
158 2.1 Roles
160 Although BXXP is peer-to-peer, it is convenient to label each peer
161 in the context of the role it is performing at a given time:
163 o When a BXXP session is established, we designate the peer that
164 awaits new connections as acting in the listening role, and the
165 other peer, which establishes a connection to the listener, as
166 acting in the initiating role. In the examples which follow,
167 these are referred to as "I:" and "L:", respectively.
169 o We designate a BXXP peer making a request as a client (or
170 requestor); similarly, we designate the other BXXP peer as a
171 server (or responder). In the examples which follow, these are
172 referred to as "C:" and "S:", respectively.
174 Typically, a BXXP peer acting in the server role is also acting in a
175 listening role. However, because BXXP is peer-to-peer in nature, no
176 such requirement exists.
178 2.2 Messages and Frames
180 In BXXP, there are two kinds of messages: requests and responses.
182 Each message conveys data content. Normally, a message is sent in a
183 single frame. However, it may be convenient or necesary to segment
184 the data content of a message into multiple frames. (e.g., if only
185 part of a message is ready to be sent). When a message is segmented
186 and sent as several frames, those frames must be sent sequentally,
187 without any intervening frames from other messages on the same
188 channel.
190 Each frame consists of a header, the payload, and a trailer. The
191 header and trailer are each represented using printable ASCII
192 characters and are terminated with a CRLF pair. Between the header
193 and the trailer is the payload, consisting of zero or more octets.
195 For example, here is a request message whose data is contained in a
196 single frame that contains a payload of 94 octets spread over 3
197 lines (each line of the data is terminated with a CRLF pair):
199 C: REQ . 1 14 94 0
200 C:
201 C:
202 C:
203 C:
204 C: END
206 Note that the header is two lines long (the second line is blank
207 signifying a lack of explicit MIME typing information).
209 2.2.1 Frame Syntax
211 The ABNF for a message is:
213 frame = header payload trailer / mapping
215 header = req / rsp
217 req = "REQ" SP more SP serial SP seqno SP size SP channel
218 CR LF [mime] CR LF
220 rsp = "RSP" SP more SP serial SP seqno SP size SP status
221 CR LF [mime] CR LF
223 more = "." / "*"
225 ; use of 0 for is reserved for the initial greeting
226 serial = 0..2147483647
228 seqno = 0..4294967295
230 size = 0..2147483647
232 ; use of 0 for is reserved for BXXP channel management
233 channel = 0..255
235 ; defaults are:
236 ;
237 ; Content-Type: text/xml
238 ; Content-Transfer-Encoding: binary
239 ;
240 mime =
242 status = "+" / "-"
244 payload = *OCTET
246 trailer = "END" CR LF
248 mapping = ;; each transport mapping may define additional frames
250 2.2.1.1 Frame Header
252 The frame header consists of a three-character keyword (one of:
253 "REQ" or "RSP"), followed by a continuation indicator, a serial
254 number, a sequence number, a payload size, and one additional
255 parameter. A single space character (decimal code 32, " ") separates
256 each component. The header is terminated with a CRLF pair.
258 The "REQ" keyword indicates that this frame is part of a request
259 message. Following the "REQ" keyword, the continuation indicator,
260 the serial number, the sequence number, and the payload size is the
261 channel number for the request.
263 The "RSP" keyword indicates that this frame is part of a response
264 message. Following the "RSP" keyword, the continuation indicator,
265 the serial number, the sequence number, and the payload size is the
266 status indicator for the response.
268 The continuation indicator (one of: decimal code 42, "*", or decimal
269 code 46, ".") specifies whether this is the final frame of the
270 message:
272 intermediate ("*"): at least one other frame follows for the
273 message; or,
275 complete ("."): this frame completes the data for the message.
277 The serial number must be a non-negative integer (in the range
278 0..2147483647) and have a different value than all other outstanding
279 request messages (regardless of channel number).
281 The sequence number must be a non-negative integer (in the range
282 0..4294967295) and specifies the sequence number of the first octet
283 in the payload, for the associated channel.
285 The payload size must be a non-negative integer (in the range
286 0..2147483647) and specifies the exact number of octets in the
287 payload. (This does not include the trailer.)
289 The status indicator (one of: decimal code 43, "+", or decimal code
290 45, "-"), specifies whether the request corresponding to this
291 response was performed:
293 positive ("+"): the request was performed and the response's data
294 contains the corresponding the results; or,
296 negative ("-"): the request could not be performed (either for
297 transient or permanent reasons) and the response's data contains
298 the corresponding error information.
300 There are several rules for identifying poorly-formed frames:
302 o if the header doesn't start with "REQ" or "RSP";
304 o if the header starts with "REQ" or "RSP", but any of the
305 continuation indicator, serial number, sequence number, or
306 payload size cannot be determined or is invalid;
308 o if the header starts with "REQ", but the channel number cannot be
309 determined or is invalid;
311 o if the header starts with "RSP", but the status indicator cannot
312 be determined or is invalid;
314 o if the header starts with "RSP", but the serial number does not
315 refer to an outstanding request message;
317 o if the continuation indicator of the previous frame received on
318 the same channel was intermediate ("*"), and if its serial number
319 isn't identical to this frame's serial number;
321 o if the value of the sequence number doesn't correspond to the
322 expected value for the associated channel (c.f., Section 2.2.1.2);
324 o if the header starts with "REQ" and refers to a message for which
325 at least one other "REQ" frame has been received, and if the
326 continuation indicator of the immediately-previous received frame
327 for this message is intermediate ("*"), and if the channel
328 numbers aren't identical; or,
330 o if the header starts with "RSP" and refers to a message for which
331 at least one other "RSP" frame has been received, and if the
332 status indicator of this frame and the immediately-previous
333 received frame for this message are not identical.
335 If a frame is poorly-formed, then the session is terminated without
336 generating a response, and it is recommended that a diagnostic entry
337 be logged.
339 The final frame in a message has a continuation indicator of
340 complete ("."), whilst all earlier frames (if any) have a
341 continuation indicator of intermediate ("*"). Note that any of these
342 frames may have an empty payload, e.g.,
344 S: RSP * 1 284 25 +
345 S:
346 S: ...
347 S: ...
348 S: ...
349 S: END
350 S: RSP . 1 309 0 +
351 S:
352 S: END
354 2.2.1.2 Frame Payload
356 The data conveyed with a message is structured according to the
357 rules of MIME. Accordingly, the header of the first frame for a
358 message may include "entity-headers" (c.f., MIME[3]'s Section 3). If
359 none, or only some, of the entity-headers are present:
361 o the default "Content-Type" is "text/xml"; and,
363 o the default "Content-Transfer-Encoding" is "binary".
365 Hence, in the absence of typing information, a message's data is a
366 well-formed XML[2] document.
368 Note that the "entity-headers" (and the empty line that follows) are
369 part of the of the header, not the payload. Thus, they do not
370 contribute to the size of the payload.
372 Every payload octet sent in each direction on a channel has an
373 associated sequence number. Numbering of payload octets within a
374 frame is such that the first payload octet is the lowest numbered,
375 and the following payload octets are numbered consecutively. (When a
376 channel is created, the sequence number associated with the first
377 payload octet of the first frame is 0.)
379 The actual sequence number space is finite, though very large,
380 ranging from 0..4294967295 (2**32 - 1). Since the space is finite,
381 all arithmetic dealing with sequence numbers is performed modulo
382 2**32. This unsigned arithmetic preserves the relationship of
383 sequence numbers as they cycle from 2**32 - 1 to 0 again.
385 When receiving a frame, the sum of its sequence number and payload
386 size, modulo 4294967296 (2**32), gives the expected sequence number
387 associated with the first payload octet of the next frame received.
388 Accordingly, when receiving a frame if the sequence number isn't the
389 expected value for this channel, then the BXXP peers have lost
390 synchronization, then the session is terminated without generating a
391 response, and it is recommended that a diagnostic entry be logged.
393 2.2.1.3 Frame Trailer
395 The frame trailer consists of "END" followed by a CRLF pair.
397 When receiving a frame, if the characters immediately following the
398 payload don't correspond to a trailer, then the session is
399 terminated without generating a response, and it is recommended that
400 a diagnostic entry be logged.
402 2.2.2 Frame Semantics
404 The semantics of the payload of each frame is channel-specific.
405 Accordingly, the profile associated with a channel must define:
407 o the initialization messages, if any, exchanged during channel
408 creation;
410 o the set of request and response messages may be carried in the
411 payload of the channel; and,
413 o the semantics of these messages.
415 A profile registration template (Section 5) organizes this
416 information.
418 Note that if a profile uses XML to structure its messages, then only
419 XML's baseline facilities (as described in the XML 1.0
420 specification[2]) are allowed. Additional XML features (e.g.,
421 namespaces) are made available only by being referenced and allowed
422 in a given profile's specification.
424 In particular this limitation allows use of only the five predefined
425 general entities references ("&", "<", ">", "'", and
426 """) and numeric entity references in the messages exchanged.
428 Finally, because the profile registration template defines the
429 messages exchanged over a channel, the XML documents exchanged in
430 each message needn't have either a "XML" declaration (e.g., ) or a "DOCTYPE" declaration (e.g., ).
432 Of course, all other XML 1.0 instructions (e.g., CDATA blocks,
433 processing instructions, and so on) are allowed.
435 2.3 Channel Management
437 When a BXXP session starts, only channel number 0 is defined, which
438 is used for channel management. Section 6.1 contains the profile
439 registration for BXXP channel management.
441 Channel management allows each BXXP peer to advertise the profiles
442 that it supports (using the greeting message), and then bind an
443 instance of one of those profiles to a channel (using the start
444 message).
446 2.3.1 Message Semantics
448 2.3.1.1 The Greeting Message
450 When a BXXP session is established, each BXXP peer signifies its
451 availability by immediately sending a positive "RSP" message with a
452 serial number of zero that contains a "greeting" element, e.g.,
454 L:
455 I:
456 L: RSP . 0 0 84 +
457 L:
458 L:
459 L:
460 L:
461 L: END
462 I: RSP . 0 0 14 +
463 I:
464 I:
465 I: END
467 Note that this example implies that the BXXP peer in the initiating
468 role waits until the BXXP peer in the listening role sends its
469 greeting -- this is an artifact of the presentation; in fact, both
470 BXXP peers send their response messages independently.
472 The "greeting" element has two optional attributes ("features" and
473 "localize") and zero or more "profile" elements, one for each
474 profile supported by the BXXP peer acting in a server role:
476 o the "features" attribute, if present, contains one or more
477 feature tokens, each indicating an optional feature of the
478 channel management profile supported by the BXXP peer;
480 o the "localize" attribute, if present, contains one or more
481 language tokens, each identifying a desirable language tag to be
482 used by the remote BXXP peer when generating textual diagnostics
483 for the "error" element (the tokens are ordered from most to
484 least desirable); and,
486 o each "profile" element contained within the "greeting" element
487 identifies a profile, and unlike the "profile" elements that
488 occur within the "start" element, the content of each "profile"
489 element may not contain an optional initialization element.
491 At present, there are no optional features defined for the channel
492 management profile.
494 Each token in the value of the "localize" attribute is defined
495 according to [8]. If not present, the default is "i-default".
497 2.3.1.2 The Start Message
499 When a BXXP peer wants to create a channel, it sends a "start"
500 element as data on channel 0, e.g.,
502 I: REQ . 1 14 94 0
503 I:
504 I:
505 I:
506 I:
507 I: END
509 The "start" element has a "number" attribute, an optional
510 "serverName" attribute, and one or more "profile" elements:
512 o the "number" attribute indicates the channel number (in the range
513 1..255) used to identify the channel in future messages;
515 o the "serverName" attribute, an arbitrary string, indicates the
516 desired server name for this BXXP session; and,
518 o each "profile" element contained within the "start" element
519 identifies a profile, and, optionally, contains an arbitrary XML
520 element exchanged during channel creation as its content.
522 To avoid conflict in assigning channel numbers when requesting the
523 creation of a channel, BXXP peers acting in the initiating role use
524 only positive integers that are odd-numbered; similarly, BXXP peers
525 acting in the listening role use only positive integers that are
526 even-numbered.
528 The "serverName" attribute for the first successful "start" element
529 received by a BXXP peer is memorable. (If the attribute isn't
530 present or it's value is empty, then the sending BXXP peer is
531 requesting a configuration-specific default value.) The BXXP peer
532 decides whether to operate as the indicated "serverName"; if not, an
533 "error" element is returned as data in a negative "RSP" message.
535 When a BXXP peer receives a "start" element as data on channel 0, it
536 examines each of the proposed profiles, and decides whether to use
537 one of them to create the channel. If so, the appropriate "profile"
538 element is returned as data in a positive "RSP" message; otherwise,
539 an "error" element is returned as data in a negative "RSP" message.
541 When creating the channel, the value of the "serverName" attribute
542 from the first successful "start" element is consulted to provide
543 configuration information, e.g., the desired server-side certificate
544 when starting the TLS transport security profile (Section 3.1).
546 For example, a successful channel creation might look like this:
548 I: REQ . 1 14 171 0
549 I:
550 I:
551 I:
552 I:
554 I:
555 I: END
556 L: RSP . 1 284 61 +
557 L:
558 L:
559 L: END
561 Similarly, an unsuccessful channel creation might look like this:
563 I: REQ . 1 14 94 0
564 I:
565 I:
566 I:
567 I:
568 I: END
569 L: RSP . 1 284 89 -
570 L:
571 L: number attribute
572 L: in <start> element must be odd-valued
573 L: END
575 Finally, here's an example in which an initialization element is
576 exchanged during channel creation:
578 C: REQ . 1 14 120 0
579 C:
580 C:
581 C:
582 C:
583 C:
584 C:
585 C: END
586 S: RSP . 1 84 83 +
587 S:
588 S:
589 S:
590 S:
591 S: END
593 2.3.1.3 The Error Message
595 When a BXXP peer declines the creation of a channel, it returns an
596 "error" element as data in a negative "RSP" message, e.g.,
598 I: REQ . 1 14 89 0
599 I:
600 I:
601 I:
602 I:
603 I: END
604 L: RSP . 1 284 67 -
605 L:
606 L: all requested profiles are
607 L: unsupported
608 L: END
610 The "error" element has a "code" attribute, an optional "xml:lang"
611 attribute, and an optional textual diagnostic as its content:
613 o the "code" attribute is a three digit reply code meaningful to
614 programs (c.f., Section 7);
616 o the "xml:lang" attribute identifies the language that the
617 element's content is written in (the value is suggested, but not
618 mandated, by the "localize" attribute of the "greeting" element
619 sent by the remote BXXP peer); and,
621 o the textual diagnostic (which may be multiline) is meaningful to
622 implementers, perhaps administrators, and possibly even users.
624 Note that if the textual diagnostic is present, then the "xml:lang"
625 attribute is absent only if the language indicated as the remote
626 BXXP's first choice is used.
628 In addition, a BXXP peer returns an "error" element whenever:
630 o it receives a "REQ" message containing an unexpected element; or,
632 o a BXXP session is established, the BXXP peer is acting in the
633 listening role, and that BXXP peer is unavailable (in this case,
634 the BXXP acting in the listening role does not send a "greeting"
635 element).
637 In the latter case, both BXXP peers terminate the session, and it is
638 recommended that a diagnostic entry be logged by both BXXP peers.
640 2.4 Session Establishment and Release
642 When a BXXP session is established, each BXXP peer signifies its
643 availability by immediately sending a positive "RSP" message with a
644 serial number of zero that contains a "greeting" element, e.g.,
646 L:
647 I:
648 L: RSP . 0 0 84 +
649 L:
650 L:
651 L:
652 L:
653 L: END
654 I: RSP . 0 0 14 +
655 I:
656 I:
657 I: END
659 which, for the BXXP peer acting in the listening role, indicates
660 that it is available.
662 Alternatively, if the BXXP peer acting in the listening role is
663 unavailable, it returns a negative response, e.g.,
665 L:
666 I:
667 L: RSP . 0 0 22 -
668 L:
669 L:
670 L: END
671 I:
672 L:
673 L:
675 and the "greeting" element sent by the BXXP peer acting in the
676 initiating role is ignored. It is recommended that a diagnostic
677 entry be logged by both BXXP peers.
679 When a BXXP peer wants to release the BXXP session, it sends a "REQ"
680 message on channel 0 with no data. The other BXXP peer may accept
681 the request (by sending a positive "RSP" message), e.g.,
683 C: REQ . 1 14 0 0
684 C:
685 C: END
686 S: RSP . 1 284 0 +
687 S:
688 S: END
689 C:
690 S:
691 L:
693 If the other BXXP peer sends a negative "RSP" message, then the BXXP
694 session should not be terminated, if possible.
696 2.5 Transport Mappings
698 The BXXP framework isn't tied to a particular transport protocol.
700 All transport interactions occur in the context of a session -- a
701 mapping onto a particular transport service. Accordingly, this memo
702 defines the requirements that must be satisified by any document
703 describing how a particular transport service realizes a BXXP
704 session.
706 2.5.1 Session Management
708 A BXXP session is connection-oriented. A mapping document must
709 define:
711 o how a BXXP session is established;
713 o how a BXXP peer is identified as acting in the listening role;
715 o how a BXXP peer is identified as acting in the initiating role;
717 o how a BXXP session is released; and,
719 o how a BXXP session is terminated.
721 2.5.2 Data Exchange
723 A BXXP session is message-oriented. A mapping document must define:
725 o how messages are reliably sent and received;
727 o how messages on the same channel are received in the same order
728 as they were sent; and,
730 o how messages on different channels are multiplexed.
732 2.6 Parallelism
734 2.6.1 Within a single channel
736 A BXXP peer acting in the client role may send multiple "REQ"
737 messages for the same channel without waiting to receive the
738 corresponding "RSP" messages. A BXXP peer acting in the server role
739 must process all "REQ" messages for a given channel in the same
740 order as they are received. As a consequence, that BXXP peer must
741 generate the corresponding "RSP" messages in the same order as the
742 "REQ" messages are received.
744 2.6.2 Between different channels
746 A BXXP peer acting in the client role may send multiple "REQ"
747 messages for different channels without waiting to receive the
748 corresponding "RSP" messages. A BXXP peer acting in the server role
749 may process "REQ" messages received for different channels in
750 parallel. As a consequence, although the "RSP" messages for a given
751 channel are generating according to the order in which the
752 corresponding "REQ" messages are received, there is no ordering
753 constraint between "RSP" messages for different channels.
755 2.6.3 Pre-emptive responses
757 A BXXP peer acting in the server role may send a negative response
758 to a request before it receives the final "REQ" frame of a request.
759 If it does so, that BXXP peer is obliged to ignore any subsequent
760 "REQ" frames for that request, up to and including the final "REQ"
761 frame.
763 If a BXXP peer acting in the client role receives a negative "RSP"
764 frame before it sends the final "REQ" frame for a request, then it
765 is required to send a "REQ" frame with a continuation status of
766 complete (".") and having a zero-length payload.
768 2.6.4 Interference
770 If the processing of a particular frame has sequencing impacts on
771 other frames (either intra-channel or inter-channel), then the
772 corresponding profile should define this behavior, e.g., a profile
773 whose messages alter the underlying transport mapping.
775 2.7 Peer-to-Peer Behavior
777 BXXP is peer-to-peer -- as such both peers must be prepared to
778 receive both "REQ" and "RSP" frames. Accordingly, an initiating BXXP
779 peer capable of acting only in the client role must behave
780 gracefully if it receives a "REQ" message. Accordingly, all profiles
781 must provide an appropriate error message for responding to unwanted
782 requests.
784 As a consequence of the peer-to-peer nature of BXXP, serial numbers
785 are unidirectionally-significant. That is, the serial numbers in
786 "REQ" messages sent by a BXXP peer acting in the initiating role are
787 unrelated to the serial numbers in "REQ" messages sent by a BXXP
788 peer acting in the listening role.
790 For example, these two frames
792 I: REQ . 1 14 94 0
793 I:
794 I:
795 I:
796 I:
797 I: END
798 L: REQ . 1 284 89 0
799 L:
800 L:
801 L:
802 L:
803 L: END
805 have no fundamental relationship to each other.
807 3. Transport Security
809 When a BXXP session is established, plaintext transfer, without
810 privacy, is provided. Accordingly, transport security in BXXP is
811 achieved using an initial tuning profile.
813 This document defines one profile:
815 o the TLS transport security profile, based on TLS version one[4].
817 Other profiles may be defined and deployed on a bilateral basis.
818 Note that because of their intimate relationship with the tranpsort
819 service, a given transport security profile tends to be relevant to
820 a single transort mapping (c.f., Section 2.5).
822 When a channel associated with transport security begins the
823 underlying negotiation process, all channels (including channel 0),
824 are closed on the BXXP session. Upon completion of the negotiation
825 process, regardless of its outcome, a new greeting is issued by both
826 BXXP peers.
828 A BXXP peer may choose to issue different greetings based on whether
829 privacy is in use, e.g.,
831 L:
832 I:
833 L: RSP . 0 0 84 +
834 L:
835 L:
836 L:
837 L:
838 L: END
839 I: RSP . 0 0 14 +
840 I:
841 I:
842 I: END
843 I: REQ . 1 14 120 0
844 I:
845 I:
846 I:
847 I:
848 I:
849 I:
850 I: END
851 L: RSP . 1 84 83 +
852 L:
853 L:
854 L:
855 L:
856 L: END
858 ... successful transport security negotiation ...
860 L: RSP . 0 0 224 +
861 L:
862 L:
863 L:
865 L:
866 L:
867 L:
868 L: END
869 I: RSP . 0 0 14 +
870 I:
871 I:
872 I: END
874 Of course, not all BXXP peers need be as single-minded:
876 L:
877 I:
878 L: RSP . 0 0 284 +
879 L:
880 L:
881 L:
883 L:
884 L:
885 L:
886 L:
887 L: END
888 I: RSP . 0 0 14 +
889 I:
890 I:
891 I: END
892 I: REQ . 1 14 120 0
893 I:
894 I:
895 I:
896 I:
897 I:
898 I:
899 I: END
900 L: RSP . 1 284 83 +
901 L:
902 L:
903 L:
904 L:
905 L: END
907 ... failed transport security negotiation ...
909 L: RSP . 0 0 284 +
910 L:
911 L:
912 L:
914 L:
915 L:
916 L:
917 L:
918 L: END
919 I: RSP . 0 0 14 +
920 I:
921 I:
922 I: END
924 3.1 The TLS Transport Security Profile
926 Section 6.3 contains the registration for this profile.
928 3.1.1 Profile Identification and Initialization
930 The TLS transport security profile is identified as:
932 http://xml.resource.org/profiles/TLS
934 in the BXXP "profile" element during channel creation.
936 During channel creation, the corresponding "profile" element in the
937 BXXP "start" element may contain a "ready" element. If channel
938 creation is successful, then before sending the corresponding "RSP"
939 message, the BXXP peer processes the "ready" element and includes
940 the resulting response in the "RSP" message, e.g.,
942 C: REQ . 1 14 120 0
943 C:
944 C:
945 C:
946 C:
947 C:
948 C:
949 C: END
950 S: RSP . 1 84 83 +
951 S:
952 S:
953 S:
954 S:
955 S: END
957 Note that it is possible for the channel to be created, but for the
958 encapsulated operation to fail, e.g.,
960 C: REQ . 1 14 135 0
961 C:
962 C:
963 C:
964 C:
965 C:
966 C:
967 C: END
968 S: RSP . 1 84 156 +
969 S:
970 S:
971 S: version attribute
972 S: poorly formed in <ready> element
973 S:
974 S: END
976 In this case, a positive "RSP" message is returned (as channel
977 creation succeeded), but the encapsulated response contains an
978 indication as to why the operation failed.
980 3.1.2 Request and Response Messages
982 Section 6.4 defines the messages that are used in the TLS transport
983 security profile:
985 o "REQ" messages carry only the "ready" element as data;
987 o positive "RSP" messages carry only the "proceed" element as data;
988 and,
990 o negative "RSP" messages carry only the "error" element as data.
992 3.1.3 Message Semantics
994 3.1.3.1 The Ready Message
996 The "ready" element has an optional "version" attribute and no
997 content:
999 o the "version" element defines the earliest version of TLS
1000 acceptable for use.
1002 When a BXXP peer sends the "ready" element, it no longer sends any
1003 traffic on any channel until a corresponding "RSP" message is
1004 received; similarly, before processing a "ready" element, the
1005 receiving BXXP peer waits until any pending "RSP" messages have been
1006 generated and sent.
1008 3.1.3.2 The Proceed Message
1010 The "proceed" element has no attributes and no content. It is sent
1011 in response to the "ready" element. When a BXXP peer receives the
1012 "ready" element, it begins the underlying negotiation process for
1013 transport security.
1015 4. User Authentication
1017 When a BXXP session is established, anonymous access, without trace
1018 information, is provided. Accordingly, user authentication in BXXP
1019 is achieved using an initial tuning profile.
1021 This document defines a family of profiles based on SASL mechanisms:
1023 o each mechanism in the IANA SASL registry[13] has an associated
1024 profile.
1026 Other profiles may be defined and deployed on a bilateral basis.
1028 Whenever a successful authentication occurs, on any channel, the
1029 authenticated identity is updated for all existing and future
1030 channels on the BXXP session; further, no additional attempts at
1031 authentication are allowed.
1033 Note that regardless of transport security and user authentication,
1034 authorization is an internal matter for each BXXP peer. As such,
1035 each peer may choose to restrict the operations it allows based on
1036 the authentication credentials provided (i.e., unauthorized
1037 operations are rejected with error code 530).
1039 4.1 The SASL Family of Profiles
1041 Section 6.5 contains the registration for this profile.
1043 Note that SASL may provide both user authentication and transport
1044 security. Once transport security is successfully negotiated for a
1045 BXXP session, then a SASL security layer may not be negotiated;
1046 similarly, once any SASL negotiation is successful, a transport
1047 security profile may not be started or otherwise used.
1049 Section 4 of the SASL specification[5] requires the following
1050 information be supplied by a protocol definition:
1052 service name: "bxxp" will be registered with the IANA as a GSSAPI
1053 service name when this draft is published as an RFC.
1055 initiation sequence: Creating a channel using a BXXP profile
1056 corresponding to a SASL mechanism starts the exchange. An
1057 optional parameter corresponding to the "initial response" sent
1058 by the client is carried within a "blob" element during channel
1059 creation.
1061 exchange sequence: "Challenges" and "responses" are carried in the
1062 "blob" element during data exchange. The "status" attribute of
1063 the "blob" element is used both by a server indicating a
1064 successful completion of the exchange, and a client aborting the
1065 exchange, The server indicates failure of the exchange by sending
1066 an "error" element.
1068 security layer negotiation: Prior to beginning the negotiation of a
1069 security layer, any pending "RSP" messages are generated and
1070 sent; further, once negotiation begins, no traffic is sent on any
1071 other channels until the negotiation completes.
1073 If a security layer is successfully negotiated, it takes effect
1074 immediately following the message that concludes the server's
1075 successful completion reply. When a security layer takes effect,
1076 all channels (including channel 0), are closed on the BXXP
1077 session, and a new greeting is issued by both BXXP peers.
1079 use of the authorization identity: This is made available to all
1080 channels for the duration of the BXXP session.
1082 4.1.1 Profile Identification and Initialization
1084 Each SASL mechanism registered with the IANA is identified as:
1086 http://xml.resource.org/profiles/sasl/MECHANISM
1088 where "MECHANISM" is the token assigned to that mechanism by the
1089 IANA.
1091 Note that during channel creation, a BXXP peer may provide multiple
1092 profiles to the remote peer, e.g.,
1094 C: REQ . 1 14 171 0
1095 C:
1096 C:
1097 C:
1099 C:
1100 C:
1101 C: END
1102 S: RSP . 1 284 61 +
1103 S:
1104 S:
1105 S: END
1107 During channel creation, the corresponding "profile" element in the
1108 BXXP "start" element may provide data in a "blob" element. Note that
1109 it is possible for the channel to be created, but for the
1110 encapsulated operation to fail, e.g.,
1112 C: REQ . 1 14 145 0
1113 C:
1114 C:
1115 C:
1116 C: AGJsb2NrbWFzdGVy
1117 C:
1118 C:
1119 C: END
1120 S: RSP . 1 284 140 +
1121 S:
1122 S:
1123 S: authentication mechanism is
1124 S: too weak
1125 S:
1126 S: END
1128 In this case, a positive "RSP" message is returned (as channel
1129 creation succeeded), but the encapsulated response contains an
1130 indication as to why the operation failed.
1132 Otherwise, the server returns a challenge (or signifies success),
1133 e.g.,
1135 C: REQ . 1 14 145 0
1136 C:
1137 C:
1138 C:
1139 C: AGJsb2NrbWFzdGVy
1140 C:
1141 C:
1142 C: END
1143 S: RSP . 1 284 144 +
1144 S:
1145 S:
1146 S: b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
1147 S:
1148 S: END
1150 If a challenge is received, then the client responds and awaits a
1151 reply, e.g.,
1153 C: REQ . 2 0 67 1
1154 C:
1155 C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
1156 C: END
1157 S: RSP . 2 0 13 +
1158 S:
1159 S:
1160 S: END
1162 Of course, the client could abort the authentication process by
1163 sending "" instead.
1165 Alternatively, the server might reject the response with an error:
1166 e.g.,
1168 C: REQ . 2 0 67 1
1169 C:
1170 C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
1171 C: END
1172 S: RSP . 2 0 22 -
1173 S:
1174 S:
1175 S: END
1177 Finally, depending on the SASL mechanism, an initialization element
1178 may be exchanged unidirectionally during channel creation, e.g.,
1180 C: REQ . 1 14 107 0
1181 C:
1182 C:
1183 C:
1185 C:
1186 C: END
1187 S: RSP . 1 284 148 +
1188 S:
1189 S:
1190 S: PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
1191
1192 S:
1193 S: END
1195 Note that this example implies that the "blob" element in the
1196 server's reply appears on two lines -- this is an artifact of the
1197 presentation; in fact, only one line is used.
1199 4.1.2 Request and Response Messages
1201 Section 6.6 defines the messages that are used for each profile in
1202 the SASL family:
1204 o "REQ" messages carry only the "blob" element as data;
1206 o positive "RSP" messages carry only the "blob" element as data;
1207 and,
1209 o negative "RSP" messages carry only the "error" element as data.
1211 Because many SASL mechanisms exchange binary data, the content of
1212 the "blob" element is always a base64-encoded string.
1214 4.1.3 Message Semantics
1216 The "blob" element has an optional "status" attribute, and arbitrary
1217 octets as its content:
1219 o the "status" attribute, if present, takes one of three values:
1221 abort: used by a client to indicate that it is aborting the
1222 authentication process;
1224 complete: used by a server to indicate that the exchange is
1225 complete and successful; or,
1227 continue: used by either a client or server, otherwise.
1229 Finally, note that SASL's EXTERNAL mechanism works with an "external
1230 authentication" service, which is provided by one of:
1232 o a transport security profile, capable of providing authentication
1233 information (e.g., Section 3.1), being active on the connection;
1235 o a network service, capable of providing strong authentication
1236 (e.g., IPSec[11]), underlying the connection; or,
1238 o a locally-defined security service.
1240 For authentication to succeed, two conditions must hold:
1242 o an external authentication service must be active; and,
1244 o if present, the authentication identity must be consistent with
1245 the credentials provided by the external authentication service
1246 (if the authentication identity is empty, then an authorization
1247 identity is automatically derived from the credentials provided
1248 by the external authentication service).
1250 5. Profile Registration Template
1252 When a profile is registered, the following information is supplied:
1254 Profile Identification: specify a URI[9] that authoritatively
1255 identifies this profile.
1257 Elements Exchanged during Channel Creation: specify the elements
1258 that may be exchanged during channel creation (note that if the
1259 profile doesn't exchange XML elements, then initialization
1260 information may not be exchanged during channel creation).
1262 Messages in "REQ" frames: specify the datatypes that may be present
1263 in a request.
1265 Messages in positive "RSP" frames: specify the datatypes that may be
1266 present in a positive response.
1268 Messages in negative "RSP" frames: specify the datatypes that may be
1269 present in negative response.
1271 Message Syntax: specify the syntax of the datatypes exchanged by the
1272 profile.
1274 Message Semantics: specify the semantics of the datatypes exchanged
1275 by the profile.
1277 Note that "datatype" refers to any MIME media type, whilst "element"
1278 refers to any well-formed XML document.
1280 6. Initial Profile Registrations
1282 6.1 BXXP Channel Management
1284 Profile Identification: not applicable
1286 Elements Exchanged during Channel Creation: not applicable
1288 Messages in "REQ" frames: "start"
1290 Messages in positive "RSP" frames: "greeting" or "profile"
1292 Messages in negative "RSP" frames: "error"
1294 Message Syntax: c.f., Section 6.2
1296 Message Semantics: c.f., Section 2.3.1
1298 6.2 BXXP Channel Management DTD
1300
1316
1337
1338
1339
1340
1341
1342
1353
1354
1358
1359
1363
1364
1367
1368
1372 6.3 Registration: TLS Transport Security Profile
1374 Profile Identification: http://xml.resource.org/profiles/TLS
1376 Elements Exchanged during Channel Creation: "ready"
1378 Messages in "REQ" frames: "ready"
1380 Messages in positive "RSP" frames: "proceed"
1382 Messages in negative "RSP" frames: "error"
1384 Message Syntax: c.f., Section 6.4
1386 Message Semantics: c.f., Section 3.1.3
1388 6.4 TLS Transport Security Profile DTD
1390
1406
1415
1416
1419
1421 6.5 Registration: SASL Family of Profiles
1423 Profile Identification:
1424 http://xml.resource.org/profiles/sasl/MECHANISM, where
1425 "MECHANISM" is a token registered with the IANA[14]
1427 Elements Exchanged during Channel Creation: "blob"
1429 Messages in "REQ" frames: "blob"
1431 Messages in positive "RSP" frames: "blob"
1433 Messages in negative "RSP" frames: "error"
1435 Message Syntax: c.f., Section 6.6
1437 Message Semantics: c.f., Section 4.1.3
1439 6.6 SASL Family of Profiles DTD
1441
1457
1466
1467
1473 7. Reply Codes
1475 code meaning
1476 ==== =======
1477 421 service not available
1479 450 requested action not taken
1480 (e.g., lock already in use)
1482 451 requested action aborted
1483 (e.g., local error in processing)
1485 454 temporary authentication failure
1487 500 general syntax error
1488 (e.g., poorly-formed XML)
1490 501 syntax error in parameters
1491 (e.g., non-valid XML)
1493 504 parameter not implemented
1495 530 authentication required
1497 534 authentication mechanism insufficient
1498 (e.g., too weak, sequence exhausted, etc.)
1500 535 authentication failure
1502 537 action not authorized for user
1504 538 authentication mechanism requires encryption
1506 550 requested action not taken
1507 (e.g., no requested profiles are acceptable)
1509 553 parameter invalid
1511 554 transaction failed
1512 (e.g., policy violation)
1514 8. Security Considerations
1516 The BXXP framing mechanism, per se, provides no protection against
1517 attack; however, judicious use of initial tuning profiles provides
1518 varying degrees of assurance:
1520 1. If one of the profiles from the SASL family is used, refer to
1521 [5]'s Section 9 for a discussion of security considerations.
1523 2. If the TLS transport security profile is used (or if a SASL
1524 security layer is negotiated), then:
1526 1. A man-in-the-middle may remove the security-related profiles
1527 from the BXXP greeting or generate an error response to the
1528 "ready" element of the TLS transport security profile. A
1529 BXXP peer may be configurable to refuse to proceed without
1530 an acceptable level of privacy.
1532 2. A man-in-the-middle may cause a down-negotiation to the
1533 weakest cipher suite available. A BXXP peer should be
1534 configurable to refuse weak cipher suites.
1536 3. A man-in-the-middle may modify any protocol interactions
1537 prior to a successful negotiation. Upon completing the
1538 negotiation, a BXXP peer must discard previously cached
1539 information about the BXXP session.
1541 As different TLS ciphersuites provide varying levels of
1542 security, administrators should carefully choose which
1543 ciphersuites are provisioned.
1545 9. IANA Considerations
1547 The IANA registers "bxxp" as a GSSAPI[12] service name.
1549 The IANA maintains a list of:
1551 o BXXP reply codes, c.f., Section 7; and,
1553 o BXXP profiles that are defined in the RFC series.
1555 The IANA makes the registrations specified in Section 6.3 and
1556 Section 6.5.
1558 References
1560 [1] Rose, M.T., "On the Design of Application Protocols",
1561 draft-mrose-bxxp-design-00 (work in progress), July 2000.
1563 [2] World Wide Web Consortium, "Extensible Markup Language (XML)
1564 1.0", W3C XML, February 1998,
1565 .
1567 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1568 Extensions (MIME) Part One: Format of Internet Message
1569 Bodies", RFC 2045, November 1996.
1571 [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
1572 2246, January 1999.
1574 [5] Myers, J.G., "Simple Authentication and Security Layer
1575 (SASL)", RFC 2222, October 1997.
1577 [6] Rose, M.T., "Mapping the BXXP Framework onto TCP",
1578 draft-mrose-bxxp-tcpmapping-01 (work in progress), July 2000.
1580 [7] Postel, J., "Transmission Control Protocol", RFC 793, STD 7,
1581 Sep 1981.
1583 [8] Alvestrand, H., "Tags for the Identification of Languages",
1584 RFC 1766, March 1995.
1586 [9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
1587 Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1588 1998.
1590 [10] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
1591 October 1998.
1593 [11] Kent, S. and R. Atkinson, "Security Architecture for the
1594 Internet Protocol", RFC 2401, November 1998.
1596 [12] Linn, J., "Generic Security Service Application Program
1597 Interface, Version 2", RFC 2078, January 1997.
1599 [13] http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms
1601 [14] http://www.iana.org/
1603 [15] mailto:ddc@lcs.mit.edu
1605 [16] mailto:dcrocker@brandenburg.com
1607 [17] mailto:deering@cisco.com
1609 [18] mailto:gazzetta@invisible.net
1611 [19] mailto:dannyg@dannyg.com
1613 [20] mailto:sharris@primus.com
1615 [21] mailto:Robert.Herriot@pahv.xerox.com
1617 [22] mailto:kenhirsch@myself.com
1619 [23] mailto:ben@algroup.co.uk
1621 [24] mailto:lear@cisco.com
1623 [25] mailto:carl@invisible.net
1625 [26] mailto:michaelm@netsol.com
1627 [27] mailto:pvm@a21.com
1629 [28] mailto:rlmorgan@washington.edu
1631 [29] mailto:fmorton@invisible.net
1633 [30] mailto:dnew@san.rr.com
1635 [31] mailto:chris.newman@innosoft.com
1637 [32] mailto:craig@bbn.com
1639 [33] mailto:touch@isi.edu
1641 [34] mailto:paul@vix.com
1643 [35] mailto:gwachob@wachob.com
1645 [36] mailto:woods@invisible.net
1647 Author's Address
1649 Marshall T. Rose
1650 Invisible Worlds, Inc.
1651 1179 North McDowell Boulevard
1652 Petaluma, CA 94954-6559
1653 US
1655 Phone: +1 707 789 3700
1656 EMail: mrose@invisible.net
1657 URI: http://invisible.net/
1659 Appendix A. Changes from draft-mrose-bxxp-framework-00
1661 o The IPR notice is changed to be in full conformance with all
1662 provisions of Section 10 of RFC2026.
1664 o At the beginning of Section 2.2 (and in the ABNF in Section
1665 2.2.1) the relationship between messages and frames is clarified.
1667 o A typo involving the final CR LF in the ABNF in Section 2.2.1 is
1668 corrected.
1670 o In Section 2.2.1.1, the "contiguous message" rule replaces the
1671 "transport-specific" assertion (the sixth rule for identifying
1672 poorly-formed frames).
1674 o At the beginning of Section 2.3, an explanation of the
1675 relstionship between profiles and channels (and the greeting and
1676 start messages) is added.
1678 o In Section 2.3.1, the order of the sections for the greeting and
1679 start messages is reversed for readability.
1681 Appendix B. Acknowledgements
1683 The author gratefully acknowledges the contributions of: David
1684 Clark[15], Dave Crocker[16], Steve Deering[17], Marco Gazzetta[18],
1685 Danny Goodman[19], Steve Harris[20], Robert Herriot[21], Ken
1686 Hirsch[22], Ben Laurie[23], Eliot Lear[24], Carl Malamud[25],
1687 Michael Mealling[26], Paul Mockapetris[27], RL 'Bob' Morgan[28],
1688 Frank Morton[29], Darren New[30], Chris Newman[31], Craig
1689 Partridge[32], Joe Touch[33], Paul Vixie[34], and Gabe Wachob[35],
1690 Daniel Woods[36]. In particular, Dave Crocker provided helpful
1691 suggestions on the nature of segmentation in the framing protocol.
1693 Full Copyright Statement
1695 Copyright (C) The Internet Society (2000). All Rights Reserved.
1697 This document and translations of it may be copied and furnished to
1698 others, and derivative works that comment on or otherwise explain it
1699 or assist in its implementation may be prepared, copied, published
1700 and distributed, in whole or in part, without restriction of any
1701 kind, provided that the above copyright notice and this paragraph
1702 are included on all such copies and derivative works. However, this
1703 document itself may not be modified in any way, such as by removing
1704 the copyright notice or references to the Internet Society or other
1705 Internet organizations, except as needed for the purpose of
1706 developing Internet standards in which case the procedures for
1707 copyrights defined in the Internet Standards process must be
1708 followed, or as required to translate it into languages other than
1709 English.
1711 The limited permissions granted above are perpetual and will not be
1712 revoked by the Internet Society or its successors or assigns.
1714 This document and the information contained herein is provided on an
1715 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1716 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1717 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1718 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1719 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1721 Acknowledgement
1723 Funding for the RFC editor function is currently provided by the
1724 Internet Society.