idnits 2.17.1
draft-mrose-bxxp-framework-00.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 1469 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 (June 29, 2000) is 8700 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 1319
-- Looks like a reference, but probably isn't: 'RFC-1766' on line 1325
-- Looks like a reference, but probably isn't: '1-5' on line 1328
-- Looks like a reference, but probably isn't: '1-9' on line 1328
== Unused Reference: '10' is defined on line 1584, 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)
== Outdated reference: A later version (-01) exists of
draft-mrose-bxxp-tcpmapping-00
-- 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'
Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 30 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: December 28, 2000 June 29, 2000
6 The Blocks eXtensible eXchange Protocol Framework
7 draft-mrose-bxxp-framework-00
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 except that the right to
13 produce derivative works is not granted. (If this document becomes
14 part of an IETF working group activity, then it will be brought into
15 full compliance with Section 10 of RFC2026.)
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as
20 Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six
23 months and may be updated, replaced, or obsoleted by other documents
24 at any time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on December 28, 2000.
35 Copyright Notice
37 Copyright (C) The Internet Society (2000). All Rights Reserved.
39 Abstract
41 This memo describes a generic application protocol framework for
42 connection-oriented, asynchronous request/response interactions. The
43 framework permits multiplexing of independent request/response
44 streams within the context of a single application user-identity,
45 supporting both textual and binary messages.
47 Table of Contents
49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
50 2. The BXXP Framework . . . . . . . . . . . . . . . . . . . . 5
51 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
52 2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7
53 2.2.1 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 8
54 2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9
55 2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 12
56 2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 13
57 2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 14
58 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15
59 2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 15
60 2.3.1.1 The Start Message . . . . . . . . . . . . . . . . . . . . 15
61 2.3.1.2 The Greeting Message . . . . . . . . . . . . . . . . . . . 18
62 2.3.1.3 The Error Message . . . . . . . . . . . . . . . . . . . . 19
63 2.4 Session Establishment and Release . . . . . . . . . . . . 20
64 2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 22
65 2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 22
66 2.5.2 Data Exchange . . . . . . . . . . . . . . . . . . . . . . 22
67 2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 23
68 2.6.1 Within a single channel . . . . . . . . . . . . . . . . . 23
69 2.6.2 Between different channels . . . . . . . . . . . . . . . . 23
70 2.6.3 Pre-emptive responses . . . . . . . . . . . . . . . . . . 23
71 2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 23
72 2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 24
73 3. Transport Security . . . . . . . . . . . . . . . . . . . . 25
74 3.1 The TLS Transport Security Profile . . . . . . . . . . . . 28
75 3.1.1 Profile Identification and Initialization . . . . . . . . 28
76 3.1.2 Request and Response Messages . . . . . . . . . . . . . . 29
77 3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 30
78 3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 30
79 3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 30
80 4. User Authentication . . . . . . . . . . . . . . . . . . . 31
81 4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 32
82 4.1.1 Profile Identification and Initialization . . . . . . . . 33
83 4.1.2 Request and Response Messages . . . . . . . . . . . . . . 35
84 4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 36
85 5. Profile Registration Template . . . . . . . . . . . . . . 37
86 6. Initial Profile Registrations . . . . . . . . . . . . . . 38
87 6.1 BXXP Channel Management . . . . . . . . . . . . . . . . . 38
88 6.2 BXXP Channel Management DTD . . . . . . . . . . . . . . . 39
89 6.3 Registration: TLS Transport Security Profile . . . . . . . 41
90 6.4 TLS Transport Security Profile DTD . . . . . . . . . . . . 42
91 6.5 Registration: SASL Family of Profiles . . . . . . . . . . 43
92 6.6 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 44
93 7. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 45
94 8. Security Considerations . . . . . . . . . . . . . . . . . 46
95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 47
96 References . . . . . . . . . . . . . . . . . . . . . . . . 48
97 Author's Address . . . . . . . . . . . . . . . . . . . . . 49
98 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 50
99 Full Copyright Statement . . . . . . . . . . . . . . . . . 51
101 1. Introduction
103 This memo describes a generic application protocol framework for
104 connection-oriented, asynchronous request/response interactions.
105 Consult [1] for a description of the framework's design principles.
107 At the core of the BXXP framework is a framing mechanism that allows
108 for peer-to-peer exchanges of requests and responses. The framing
109 mechanism permits multiplexing multiple, simultaneous and
110 independent exchanges. Requests and responses are either textual
111 (structured using XML[2]) or arbitrary (structured using MIME[3]).
113 Frames are exchanged in the context of a "channel". Each channel has
114 an associated "profile" that defines the syntax and semantics of the
115 messages exchanged. Implicit in the operation of BXXP is the notion
116 of channel management. In addition to defining BXXP's channel
117 management profile, this document defines:
119 o the TLS[4] transport security profile; and,
121 o the SASL[5] family of profiles.
123 Other profiles, such as those used for data exchange, are defined by
124 an application protocol designer. A registration template is
125 provided for this purpose.
127 2. The BXXP Framework
129 The BXXP framework is message-oriented. Arbitrary octets are
130 encapsulated within a frame and tagged as either a request or a
131 response. All interactions occur in the context of a channel -- a
132 binding to a well-defined aspect of the application, such as
133 transport security, user authentication, or data exchange.
135 A BXXP session is mapped onto an underlying transport service. A
136 separate series of documents describe how a particular transport
137 service realizes a BXXP session. For example, [6] describes how a
138 BXXP session is mapped onto a single TCP[7] connection.
140 During the creation of a channel, the requestor supplies one or more
141 proposed profiles for that channel. If the responder creates the
142 channel, it selects one of the profiles and returns it in a
143 response; otherwise, it may indicate that none of the profiles are
144 acceptable, and decline creation of the channel.
146 There are no other management capabilities for channels other than
147 creation, as channel usage falls into one of two categories:
149 initial tuning: these are used by profiles that perform
150 initialization once the BXXP session is established (e.g.,
151 negotiating the use of transport security); although several
152 request/response exchanges may be required to perform the
153 initialization, these channels become inactive early in the BXXP
154 session and remain so for the duration.
156 continuous: these are used by profiles that support data exchange;
157 typically, these channels are created after the initial tuning
158 channels have gone quiet.
160 2.1 Roles
162 Although BXXP is peer-to-peer, it is convenient to label each peer
163 in the context of the role it is performing at a given time:
165 o When a BXXP session is established, we designate the peer that
166 awaits new connections as acting in the listening role, and the
167 other peer, which establishes a connection to the listener, as
168 acting in the initiating role. In the examples which follow,
169 these are referred to as "I:" and "L:", respectively.
171 o We designate a BXXP peer making a request as a client (or
172 requestor); similarly, we designate the other BXXP peer as a
173 server (or responder). In the examples which follow, these are
174 referred to as "C:" and "S:", respectively.
176 Typically, a BXXP peer acting in the server role is also acting in a
177 listening role. However, because BXXP is peer-to-peer in nature, no
178 such requirement exists.
180 2.2 Messages and Frames
182 In BXXP, there are two kinds of messages: requests and responses.
184 Each request or response conveys data, which is segmented as the
185 payload of one or more frames. Each frame consists of a header, the
186 payload, and a trailer. The header and trailer are each represented
187 using printable ASCII characters and are terminated with a CRLF
188 pair. Between the header and the trailer is the payload, consisting
189 of zero or more octets.
191 For example, here is a request message whose data is contained in a
192 single frame that contains a payload of 94 octets spread over 3
193 lines (each line of the data is terminated with a CRLF pair):
195 C: REQ . 1 14 94 0
196 C:
197 C:
198 C:
199 C:
200 C: END
202 Note that the header is two lines long (the second line is blank
203 signifying a lack of explicit MIME typing information).
205 2.2.1 Message Syntax
207 The ABNF for a message is:
209 message = frame / mapping
211 frame = header payload trailer
213 header = req / rsp
215 req = "REQ" SP more SP serial SP seqno SP size SP channel
216 CR LF [[mime] CR LF]
218 rsp = "RSP" SP more SP serial SP seqno SP size SP status
219 CR LF [[mime] CR LF]
221 more = "." / "*"
223 ; use of 0 for is reserved for the initial greeting
224 serial = 0..2147483647
226 seqno = 0..4294967295
228 size = 0..2147483647
230 ; use of 0 for is reserved for BXXP channel management
231 channel = 0..255
233 ; defaults are:
234 ;
235 ; Content-Type: text/xml
236 ; Content-Transfer-Encoding: binary
237 ;
238 mime =
240 status = "+" / "-"
242 payload = *OCTET
244 trailer = "END" CR LF
246 mapping = ;; each transport mapping may define additional messages
248 2.2.1.1 Frame Header
250 The frame header consists of a three-character keyword (one of:
251 "REQ" or "RSP"), followed by a continuation indicator, a serial
252 number, a sequence number, a payload size, and one additional
253 parameter. A single space character (decimal code 32, " ") separates
254 each component. The header is terminated with a CRLF pair.
256 The "REQ" keyword indicates that this frame is part of a request
257 message. Following the "REQ" keyword, the continuation indicator,
258 the serial number, the sequence number, and the payload size is the
259 channel number for the request.
261 The "RSP" keyword indicates that this frame is part of a response
262 message. Following the "RSP" keyword, the continuation indicator,
263 the serial number, the sequence number, and the payload size is the
264 status indicator for the response.
266 The continuation indicator (one of: decimal code 42, "*", or decimal
267 code 46, ".") specifies whether this is the final frame of the
268 message:
270 intermediate ("*"): at least one other frame follows for the
271 message; or,
273 complete ("."): this frame completes the data for the message.
275 The serial number must be a non-negative integer (in the range
276 0..2147483647) and have a different value than all other outstanding
277 request messages (regardless of channel number).
279 The sequence number must be a non-negative integer (in the range
280 0..4294967295) and specifies the sequence number of the first octet
281 in the payload, for the associated channel.
283 The payload size must be a non-negative integer (in the range
284 0..2147483647) and specifies the exact number of octets in the
285 payload. (This does not include the trailer.)
287 The status indicator (one of: decimal code 43, "+", or decimal code
288 45, "-"), specifies whether the request corresponding to this
289 response was performed:
291 positive ("+"): the request was performed and the response's data
292 contains the corresponding the results; or,
294 negative ("-"): the request could not be performed (either for
295 transient or permanent reasons) and the response's data contains
296 the corresponding error information.
298 There are several rules for identifying poorly-formed frames:
300 o if the header doesn't start with "REQ" or "RSP";
302 o if the header starts with "REQ" or "RSP", but any of the
303 continuation indicator, serial number, sequence number, or
304 payload size cannot be determined or is invalid;
306 o if the header starts with "REQ", but the channel number cannot be
307 determined or is invalid;
309 o if the header starts with "RSP", but the status indicator cannot
310 be determined or is invalid;
312 o if the header starts with "RSP", but the serial number does not
313 refer to an outstanding request message;
315 o if the value of the sequence number doesn't correspond to the
316 expected value for the associated channel (c.f., Section 2.2.1.2);
318 o if some transport-specific assertion isn't satisified (e.g., an
319 unexpected sequence number is encountered);
321 o if the header starts with "REQ" and refers to a message for which
322 at least one other "REQ" frame has been received, and if the
323 continuation indicator of the immediately-previous received frame
324 for this message is intermediate ("*"), and if the channel
325 numbers aren't identical; or,
327 o if the header starts with "RSP" and refers to a message for which
328 at least one other "RSP" frame has been received, and if the
329 status indicator of this frame and the immediately-previous
330 received frame for this message are not identical.
332 If a frame is poorly-formed, then the session is terminated without
333 generating a response, and it is recommended that a diagnostic entry
334 be logged.
336 The final frame in a message has a continuation indicator of
337 complete ("."), whilst all earlier frames (if any) have a
338 continuation indicator of intermediate ("*"). Note that any of these
339 frames may have an empty payload, e.g.,
341 S: RSP * 1 284 25 +
342 S:
343 S: ...
344 S: ...
345 S: ...
346 S: END
347 S: RSP . 1 309 0 +
348 S:
349 S: END
351 2.2.1.2 Frame Payload
353 The data conveyed with a message is structured according to the
354 rules of MIME. Accordingly, the header of the first frame for a
355 message may include "entity-headers" (c.f., MIME[3]'s Section 3). If
356 none, or only some, of the entity-headers are present:
358 o the default "Content-Type" is "text/xml"; and,
360 o the default "Content-Transfer-Encoding" is "binary".
362 Hence, in the absence of typing information, a message's data is a
363 well-formed XML[2] document.
365 Note that the "entity-headers" (and the empty line that follows) are
366 part of the of the header, not the payload. Thus, they do not
367 contribute to the size of the payload.
369 Every payload octet sent in each direction on a channel has an
370 associated sequence number. Numbering of payload octets within a
371 frame is such that the first payload octet is the lowest numbered,
372 and the following payload octets are numbered consecutively. (When a
373 channel is created, the sequence number associated with the first
374 payload octet of the first frame is 0.)
376 The actual sequence number space is finite, though very large,
377 ranging from 0..4294967295 (2**32 - 1). Since the space is finite,
378 all arithmetic dealing with sequence numbers is performed modulo
379 2**32. This unsigned arithmetic preserves the relationship of
380 sequence numbers as they cycle from 2**32 - 1 to 0 again.
382 When receiving a frame, the sum of its sequence number and payload
383 size, modulo 4294967296 (2**32), gives the expected sequence number
384 associated with the first payload octet of the next frame received.
385 Accordingly, when receiving a frame if the sequence number isn't the
386 expected value for this channel, then the BXXP peers have lost
387 synchronization, then the session is terminated without generating a
388 response, and it is recommended that a diagnostic entry be logged.
390 2.2.1.3 Frame Trailer
392 The frame trailer consists of "END" followed by a CRLF pair.
394 When receiving a frame, if the characters immediately following the
395 payload don't correspond to a trailer, then the session is
396 terminated without generating a response, and it is recommended that
397 a diagnostic entry be logged.
399 2.2.2 Frame Semantics
401 The semantics of the payload of each frame is channel-specific.
402 Accordingly, the profile associated with a channel must define:
404 o the initialization messages, if any, exchanged during channel
405 creation;
407 o the set of request and response messages may be carried in the
408 payload of the channel; and,
410 o the semantics of these messages.
412 A profile registration template (Section 5) organizes this
413 information.
415 Note that if a profile uses XML to structure its messages, then only
416 XML's baseline facilities (as described in the XML 1.0
417 specification[2]) are allowed. Additional XML features (e.g.,
418 namespaces) are made available only by being referenced and allowed
419 in a given profile's specification.
421 In particular this limitation allows use of only the five predefined
422 general entities references ("&", "<", ">", "'", and
423 """) and numeric entity references in the messages exchanged.
425 Finally, because the profile registration template defines the
426 messages exchanged over a channel, the XML documents exchanged in
427 each message needn't have either a "XML" declaration (e.g., ) or a "DOCTYPE" declaration (e.g., ).
429 Of course, all other XML 1.0 instructions (e.g., CDATA blocks,
430 processing instructions, and so on) are allowed.
432 2.3 Channel Management
434 When a BXXP session starts, only channel number 0 is defined, which
435 is used for channel management. Section 6.1 contains the profile
436 registration for BXXP channel management.
438 2.3.1 Message Semantics
440 2.3.1.1 The Start Message
442 When a BXXP peer wants to create a channel, it sends a "start"
443 element as data on channel 0, e.g.,
445 I: REQ . 1 14 94 0
446 I:
447 I:
448 I:
449 I:
450 I: END
452 The "start" element has a "number" attribute, an optional
453 "serverName" attribute, and one or more "profile" elements:
455 o the "number" attribute indicates the channel number (in the range
456 1..255) used to identify the channel in future messages;
458 o the "serverName" attribute, an arbitrary string, indicates the
459 desired server name for this BXXP session; and,
461 o each "profile" element contained within the "start" element
462 identifies a profile, and, optionally, contains an arbitrary XML
463 element exchanged during channel creation as its content.
465 To avoid conflict in assigning channel numbers when requesting the
466 creation of a channel, BXXP peers acting in the initiating role use
467 only positive integers that are odd-numbered; similarly, BXXP peers
468 acting in the listening role use only positive integers that are
469 even-numbered.
471 The "serverName" attribute for the first successful "start" element
472 received by a BXXP peer is memorable. (If the attribute isn't
473 present or it's value is empty, then the sending BXXP peer is
474 requesting a configuration-specific default value.) The BXXP peer
475 decides whether to operate as the indicated "serverName"; if not, an
476 "error" element is returned as data in a negative "RSP" message.
478 When a BXXP peer receives a "start" element as data on channel 0, it
479 examines each of the proposed profiles, and decides whether to use
480 one of them to create the channel. If so, the appropriate "profile"
481 element is returned as data in a positive "RSP" message; otherwise,
482 an "error" element is returned as data in a negative "RSP" message.
484 When creating the channel, the value of the "serverName" attribute
485 from the first successful "start" element is consulted to provide
486 configuration information, e.g., the desired server-side certificate
487 when starting the TLS transport security profile (Section 3.1).
489 For example, a successful channel creation might look like this:
491 I: REQ . 1 14 171 0
492 I:
493 I:
494 I:
495 I:
497 I:
498 I: END
499 L: RSP . 1 284 61 +
500 L:
501 L:
502 L: END
504 Similarly, an unsuccessful channel creation might look like this:
506 I: REQ . 1 14 94 0
507 I:
508 I:
509 I:
510 I:
511 I: END
512 L: RSP . 1 284 89 -
513 L:
514 L: number attribute
515 L: in <start> element must be odd-valued
516 L: END
518 Finally, here's an example in which an initialization element is
519 exchanged during channel creation:
521 C: REQ . 1 14 120 0
522 C:
523 C:
524 C:
525 C:
526 C:
527 C:
528 C: END
529 S: RSP . 1 84 83 +
530 S:
531 S:
532 S:
533 S:
534 S: END
536 2.3.1.2 The Greeting Message
538 When a BXXP session is established, each BXXP peer signifies its
539 availability by immediately sending a positive "RSP" message with a
540 serial number of zero that contains a "greeting" element, e.g.,
542 L:
543 I:
544 L: RSP . 0 0 84 +
545 L:
546 L:
547 L:
548 L:
549 L: END
550 I: RSP . 0 0 14 +
551 I:
552 I:
553 I: END
555 Note that this example implies that the BXXP peer in the initiating
556 role waits until the BXXP peer in the listening role sends its
557 greeting -- this is an artifact of the presentation; in fact, both
558 BXXP peers send their response messages independently.
560 The "greeting" element has two optional attributes ("features" and
561 "localize") and zero or more "profile" elements, one for each
562 profile supported by the BXXP peer acting in a server role:
564 o the "features" attribute, if present, contains one or more
565 feature tokens, each indicating an optional feature of the
566 channel management profile supported by the BXXP peer;
568 o the "localize" attribute, if present, contains one or more
569 language tokens, each identifying a desirable language tag to be
570 used by the remote BXXP peer when generating textual diagnostics
571 for the "error" element (the tokens are ordered from most to
572 least desirable); and,
574 o each "profile" element contained within the "greeting" element
575 identifies a profile, and unlike the "profile" elements that
576 occur within the "start" element, the content of each "profile"
577 element may not contain an optional initialization element.
579 At present, there are no optional features defined for the channel
580 management profile.
582 Each token in the value of the "localize" attribute is defined
583 according to [8]. If not present, the default is "i-default".
585 2.3.1.3 The Error Message
587 When a BXXP peer declines the creation of a channel, it returns an
588 "error" element as data in a negative "RSP" message, e.g.,
590 I: REQ . 1 14 89 0
591 I:
592 I:
593 I:
594 I:
595 I: END
596 L: RSP . 1 284 67 -
597 L:
598 L: all requested profiles are
599 L: unsupported
600 L: END
602 The "error" element has a "code" attribute, an optional "xml:lang"
603 attribute, and an optional textual diagnostic as its content:
605 o the "code" attribute is a three digit reply code meaningful to
606 programs (c.f., Section 7);
608 o the "xml:lang" attribute identifies the language that the
609 element's content is written in (the value is suggested, but not
610 mandated, by the "localize" attribute of the "greeting" element
611 sent by the remote BXXP peer); and,
613 o the textual diagnostic (which may be multiline) is meaningful to
614 implementers, perhaps administrators, and possibly even users.
616 Note that if the textual diagnostic is present, then the "xml:lang"
617 attribute is absent only if the language indicated as the remote
618 BXXP's first choice is used.
620 In addition, a BXXP peer returns an "error" element whenever:
622 o it receives a "REQ" message containing an unexpected element; or,
624 o a BXXP session is established, the BXXP peer is acting in the
625 listening role, and that BXXP peer is unavailable (in this case,
626 the BXXP acting in the listening role does not send a "greeting"
627 element).
629 In the latter case, both BXXP peers terminate the session, and it is
630 recommended that a diagnostic entry be logged by both BXXP peers.
632 2.4 Session Establishment and Release
634 When a BXXP session is established, each BXXP peer signifies its
635 availability by immediately sending a positive "RSP" message with a
636 serial number of zero that contains a "greeting" element, e.g.,
638 L:
639 I:
640 L: RSP . 0 0 84 +
641 L:
642 L:
643 L:
644 L:
645 L: END
646 I: RSP . 0 0 14 +
647 I:
648 I:
649 I: END
651 which, for the BXXP peer acting in the listening role, indicates
652 that it is available.
654 Alternatively, if the BXXP peer acting in the listening role is
655 unavailable, it returns a negative response, e.g.,
657 L:
658 I:
659 L: RSP . 0 0 22 -
660 L:
661 L:
662 L: END
663 I:
664 L:
665 L:
667 and the "greeting" element sent by the BXXP peer acting in the
668 initiating role is ignored. It is recommended that a diagnostic
669 entry be logged by both BXXP peers.
671 When a BXXP peer wants to release the BXXP session, it sends a "REQ"
672 message on channel 0 with no data. The other BXXP peer may accept
673 the request (by sending a positive "RSP" message), e.g.,
675 C: REQ . 1 14 0 0
676 C:
677 C: END
678 S: RSP . 1 284 0 +
679 S:
680 S: END
681 C:
682 S:
683 L:
685 If the other BXXP peer sends a negative "RSP" message, then the BXXP
686 session should not be terminated, if possible.
688 2.5 Transport Mappings
690 The BXXP framework isn't tied to a particular transport protocol.
692 All transport interactions occur in the context of a session -- a
693 mapping onto a particular transport service. Accordingly, this memo
694 defines the requirements that must be satisified by any document
695 describing how a particular transport service realizes a BXXP
696 session.
698 2.5.1 Session Management
700 A BXXP session is connection-oriented. A mapping document must
701 define:
703 o how a BXXP session is established;
705 o how a BXXP peer is identified as acting in the listening role;
707 o how a BXXP peer is identified as acting in the initiating role;
709 o how a BXXP session is released; and,
711 o how a BXXP session is terminated.
713 2.5.2 Data Exchange
715 A BXXP session is message-oriented. A mapping document must define:
717 o how messages are reliably sent and received;
719 o how messages on the same channel are received in the same order
720 as they were sent; and,
722 o how messages on different channels are multiplexed.
724 2.6 Parallelism
726 2.6.1 Within a single channel
728 A BXXP peer acting in the client role may send multiple "REQ"
729 messages for the same channel without waiting to receive the
730 corresponding "RSP" messages. A BXXP peer acting in the server role
731 must process all "REQ" messages for a given channel in the same
732 order as they are received. As a consequence, that BXXP peer must
733 generate the corresponding "RSP" messages in the same order as the
734 "REQ" messages are received.
736 2.6.2 Between different channels
738 A BXXP peer acting in the client role may send multiple "REQ"
739 messages for different channels without waiting to receive the
740 corresponding "RSP" messages. A BXXP peer acting in the server role
741 may process "REQ" messages received for different channels in
742 parallel. As a consequence, although the "RSP" messages for a given
743 channel are generating according to the order in which the
744 corresponding "REQ" messages are received, there is no ordering
745 constraint between "RSP" messages for different channels.
747 2.6.3 Pre-emptive responses
749 A BXXP peer acting in the server role may send a negative response
750 to a request before it receives the final "REQ" frame of a request.
751 If it does so, that BXXP peer is obliged to ignore any subsequent
752 "REQ" frames for that request, up to and including the final "REQ"
753 frame.
755 If a BXXP peer acting in the client role receives a negative "RSP"
756 frame before it sends the final "REQ" frame for a request, then it
757 is required to send a "REQ" frame with a continuation status of
758 complete (".") and having a zero-length payload.
760 2.6.4 Interference
762 If the processing of a particular frame has sequencing impacts on
763 other frames (either intra-channel or inter-channel), then the
764 corresponding profile should define this behavior, e.g., a profile
765 whose messages alter the underlying transport mapping.
767 2.7 Peer-to-Peer Behavior
769 BXXP is peer-to-peer -- as such both peers must be prepared to
770 receive both "REQ" and "RSP" frames. Accordingly, an initiating BXXP
771 peer capable of acting only in the client role must behave
772 gracefully if it receives a "REQ" message. Accordingly, all profiles
773 must provide an appropriate error message for responding to unwanted
774 requests.
776 As a consequence of the peer-to-peer nature of BXXP, serial numbers
777 are unidirectionally-significant. That is, the serial numbers in
778 "REQ" messages sent by a BXXP peer acting in the initiating role are
779 unrelated to the serial numbers in "REQ" messages sent by a BXXP
780 peer acting in the listening role.
782 For example, these two frames
784 I: REQ . 1 14 94 0
785 I:
786 I:
787 I:
788 I:
789 I: END
790 L: REQ . 1 284 89 0
791 L:
792 L:
793 L:
794 L:
795 L: END
797 have no fundamental relationship to each other.
799 3. Transport Security
801 When a BXXP session is established, plaintext transfer, without
802 privacy, is provided. Accordingly, transport security in BXXP is
803 achieved using an initial tuning profile.
805 This document defines one profile:
807 o the TLS transport security profile, based on TLS version one[4].
809 Other profiles may be defined and deployed on a bilateral basis.
810 Note that because of their intimate relationship with the tranpsort
811 service, a given transport security profile tends to be relevant to
812 a single transort mapping (c.f., Section 2.5).
814 When a channel associated with transport security begins the
815 underlying negotiation process, all channels (including channel 0),
816 are closed on the BXXP session. Upon completion of the negotiation
817 process, regardless of its outcome, a new greeting is issued by both
818 BXXP peers.
820 A BXXP peer may choose to issue different greetings based on whether
821 privacy is in use, e.g.,
823 L:
824 I:
825 L: RSP . 0 0 84 +
826 L:
827 L:
828 L:
829 L:
830 L: END
831 I: RSP . 0 0 14 +
832 I:
833 I:
834 I: END
835 I: REQ . 1 14 120 0
836 I:
837 I:
838 I:
839 I:
840 I:
841 I:
842 I: END
843 L: RSP . 1 84 83 +
844 L:
845 L:
846 L:
847 L:
848 L: END
850 ... successful transport security negotiation ...
852 L: RSP . 0 0 224 +
853 L:
854 L:
855 L:
857 L:
858 L:
859 L:
860 L: END
861 I: RSP . 0 0 14 +
862 I:
863 I:
864 I: END
866 Of course, not all BXXP peers need be as single-minded:
868 L:
869 I:
870 L: RSP . 0 0 284 +
871 L:
872 L:
873 L:
875 L:
876 L:
877 L:
878 L:
879 L: END
880 I: RSP . 0 0 14 +
881 I:
882 I:
883 I: END
884 I: REQ . 1 14 120 0
885 I:
886 I:
887 I:
888 I:
889 I:
890 I:
891 I: END
892 L: RSP . 1 284 83 +
893 L:
894 L:
895 L:
896 L:
897 L: END
899 ... failed transport security negotiation ...
901 L: RSP . 0 0 284 +
902 L:
903 L:
904 L:
906 L:
907 L:
908 L:
909 L:
910 L: END
911 I: RSP . 0 0 14 +
912 I:
913 I:
914 I: END
916 3.1 The TLS Transport Security Profile
918 Section 6.3 contains the registration for this profile. This profile
919 is relevant only when the underlying transport mapping is onto a
920 single TCP connection (c.f., [6]).
922 3.1.1 Profile Identification and Initialization
924 The TLS transport security profile is identified as:
926 http://xml.resource.org/profiles/TLS
928 in the BXXP "profile" element during channel creation.
930 During channel creation, the corresponding "profile" element in the
931 BXXP "start" element may contain a "ready" element. If channel
932 creation is successful, then before sending the corresponding "RSP"
933 message, the BXXP peer processes the "ready" element and includes
934 the resulting response in the "RSP" message, e.g.,
936 C: REQ . 1 14 120 0
937 C:
938 C:
939 C:
940 C:
941 C:
942 C:
943 C: END
944 S: RSP . 1 84 83 +
945 S:
946 S:
947 S:
948 S:
949 S: END
951 Note that it is possible for the channel to be created, but for the
952 encapsulated operation to fail, e.g.,
954 C: REQ . 1 14 135 0
955 C:
956 C:
957 C:
958 C:
959 C:
960 C:
961 C: END
962 S: RSP . 1 84 156 +
963 S:
964 S:
965 S: version attribute
966 S: poorly formed in <ready> element
967 S:
968 S: END
970 In this case, a positive "RSP" message is returned (as channel
971 creation succeeded), but the encapsulated response contains an
972 indication as to why the operation failed.
974 3.1.2 Request and Response Messages
976 Section 6.4 defines the messages that are used in the TLS transport
977 security profile:
979 o "REQ" messages carry only the "ready" element as data;
981 o positive "RSP" messages carry only the "proceed" element as data;
982 and,
984 o negative "RSP" messages carry only the "error" element as data.
986 3.1.3 Message Semantics
988 3.1.3.1 The Ready Message
990 The "ready" element has an optional "version" attribute and no
991 content:
993 o the "version" element defines the earliest version of TLS
994 acceptable for use.
996 When a BXXP peer sends the "ready" element, it no longer sends any
997 traffic on any channel until a corresponding "RSP" message is
998 received; similarly, before processing a "ready" element, the
999 receiving BXXP peer waits until any pending "RSP" messages have been
1000 generated and sent.
1002 3.1.3.2 The Proceed Message
1004 The "proceed" element has no attributes and no content. It is sent
1005 in response to the "ready" element. When a BXXP peer receives the
1006 "ready" element, it begins the underlying negotiation process for
1007 transport security.
1009 4. User Authentication
1011 When a BXXP session is established, anonymous access, without trace
1012 information, is provided. Accordingly, user authentication in BXXP
1013 is achieved using an initial tuning profile.
1015 This document defines a family of profiles based on SASL mechanisms:
1017 o each mechanism in the IANA SASL registry[13] has an associated
1018 profile.
1020 Other profiles may be defined and deployed on a bilateral basis.
1022 Whenever a successful authentication occurs, on any channel, the
1023 authenticated identity is updated for all existing and future
1024 channels on the BXXP session; further, no additional attempts at
1025 authentication are allowed.
1027 Note that regardless of transport security and user authentication,
1028 authorization is an internal matter for each BXXP peer. As such,
1029 each peer may choose to restrict the operations it allows based on
1030 the authentication credentials provided (i.e., unauthorized
1031 operations are rejected with error code 530).
1033 4.1 The SASL Family of Profiles
1035 Section 6.5 contains the registration for this profile.
1037 Note that SASL may provide both user authentication and transport
1038 security. Once transport security is successfully negotiated for a
1039 BXXP session, then a SASL security layer may not be negotiated;
1040 similarly, once any SASL negotiation is successful, a transport
1041 security profile may not be started or otherwise used.
1043 Section 4 of the SASL specification[5] requires the following
1044 information be supplied by a protocol definition:
1046 service name: "bxxp" will be registered with the IANA as a GSSAPI
1047 service name when this draft is published as an RFC.
1049 initiation sequence: Creating a channel using a BXXP profile
1050 corresponding to a SASL mechanism starts the exchange. An
1051 optional parameter corresponding to the "initial response" sent
1052 by the client is carried within a "blob" element during channel
1053 creation.
1055 exchange sequence: "Challenges" and "responses" are carried in the
1056 "blob" element during data exchange. The "status" attribute of
1057 the "blob" element is used both by a server indicating a
1058 successful completion of the exchange, and a client aborting the
1059 exchange, The server indicates failure of the exchange by sending
1060 an "error" element.
1062 security layer negotiation: Prior to beginning the negotiation of a
1063 security layer, any pending "RSP" messages are generated and
1064 sent; further, once negotiation begins, no traffic is sent on any
1065 other channels until the negotiation completes.
1067 If a security layer is successfully negotiated, it takes effect
1068 immediately following the message that concludes the server's
1069 successful completion reply. When a security layer takes effect,
1070 all channels (including channel 0), are closed on the BXXP
1071 session, and a new greeting is issued by both BXXP peers.
1073 use of the authorization identity: This is made available to all
1074 channels for the duration of the BXXP session.
1076 4.1.1 Profile Identification and Initialization
1078 Each SASL mechanism registered with the IANA is identified as:
1080 http://xml.resource.org/profiles/sasl/MECHANISM
1082 where "MECHANISM" is the token assigned to that mechanism by the
1083 IANA.
1085 Note that during channel creation, a BXXP peer may provide multiple
1086 profiles to the remote peer, e.g.,
1088 C: REQ . 1 14 171 0
1089 C:
1090 C:
1091 C:
1093 C:
1094 C:
1095 C: END
1096 S: RSP . 1 284 61 +
1097 S:
1098 S:
1099 S: END
1101 During channel creation, the corresponding "profile" element in the
1102 BXXP "start" element may provide data in a "blob" element. Note that
1103 it is possible for the channel to be created, but for the
1104 encapsulated operation to fail, e.g.,
1106 C: REQ . 1 14 145 0
1107 C:
1108 C:
1109 C:
1110 C: AGJsb2NrbWFzdGVy
1111 C:
1112 C:
1113 C: END
1114 S: RSP . 1 284 140 +
1115 S:
1116 S:
1117 S: authentication mechanism is
1118 S: too weak
1119 S:
1120 S: END
1122 In this case, a positive "RSP" message is returned (as channel
1123 creation succeeded), but the encapsulated response contains an
1124 indication as to why the operation failed.
1126 Otherwise, the server returns a challenge (or signifies success),
1127 e.g.,
1129 C: REQ . 1 14 145 0
1130 C:
1131 C:
1132 C:
1133 C: AGJsb2NrbWFzdGVy
1134 C:
1135 C:
1136 C: END
1137 S: RSP . 1 284 144 +
1138 S:
1139 S:
1140 S: b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
1141 S:
1142 S: END
1144 If a challenge is received, then the client responds and awaits a
1145 reply, e.g.,
1147 C: REQ . 2 0 67 1
1148 C:
1149 C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
1150 C: END
1151 S: RSP . 2 0 13 +
1152 S:
1153 S:
1154 S: END
1156 Of course, the client could abort the authentication process by
1157 sending "" instead.
1159 Alternatively, the server might reject the response with an error:
1160 e.g.,
1162 C: REQ . 2 0 67 1
1163 C:
1164 C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
1165 C: END
1166 S: RSP . 2 0 22 -
1167 S:
1168 S:
1169 S: END
1171 Finally, depending on the SASL mechanism, an initialization element
1172 may be exchanged unidirectionally during channel creation, e.g.,
1174 C: REQ . 1 14 107 0
1175 C:
1176 C:
1177 C:
1179 C:
1180 C: END
1181 S: RSP . 1 284 148 +
1182 S:
1183 S:
1184 S: PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
1185
1186 S:
1187 S: END
1189 Note that this example implies that the "blob" element in the
1190 server's reply appears on two lines -- this is an artifact of the
1191 presentation; in fact, only one line is used.
1193 4.1.2 Request and Response Messages
1195 Section 6.6 defines the messages that are used for each profile in
1196 the SASL family:
1198 o "REQ" messages carry only the "blob" element as data;
1200 o positive "RSP" messages carry only the "blob" element as data;
1201 and,
1203 o negative "RSP" messages carry only the "error" element as data.
1205 Because many SASL mechanisms exchange binary data, the content of
1206 the "blob" element is always a base64-encoded string.
1208 4.1.3 Message Semantics
1210 The "blob" element has an optional "status" attribute, and arbitrary
1211 octets as its content:
1213 o the "status" attribute, if present, takes one of three values:
1215 abort: used by a client to indicate that it is aborting the
1216 authentication process;
1218 complete: used by a server to indicate that the exchange is
1219 complete and successful; or,
1221 continue: used by either a client or server, otherwise.
1223 Finally, note that SASL's EXTERNAL mechanism works with an "external
1224 authentication" service, which is provided by one of:
1226 o a transport security profile, capable of providing authentication
1227 information (e.g., Section 3.1), being active on the connection;
1229 o a network service, capable of providing strong authentication
1230 (e.g., IPSec[11]), underlying the connection; or,
1232 o a locally-defined security service.
1234 For authentication to succeed, two conditions must hold:
1236 o an external authentication service must be active; and,
1238 o if present, the authentication identity must be consistent with
1239 the credentials provided by the external authentication service
1240 (if the authentication identity is empty, then an authorization
1241 identity is automatically derived from the credentials provided
1242 by the external authentication service).
1244 5. Profile Registration Template
1246 When a profile is registered, the following information is supplied:
1248 Profile Identification: specify a URI[9] that authoritatively
1249 identifies this profile.
1251 Elements Exchanged during Channel Creation: specify the elements
1252 that may be exchanged during channel creation (note that if the
1253 profile doesn't exchange XML elements, then initialization
1254 information may not be exchanged during channel creation).
1256 Messages in "REQ" frames: specify the datatypes that may be present
1257 in a request.
1259 Messages in positive "RSP" frames: specify the datatypes that may be
1260 present in a positive response.
1262 Messages in negative "RSP" frames: specify the datatypes that may be
1263 present in negative response.
1265 Message Syntax: specify the syntax of the datatypes exchanged by the
1266 profile.
1268 Message Semantics: specify the semantics of the datatypes exchanged
1269 by the profile.
1271 Note that "datatype" refers to any MIME media type, whilst "element"
1272 refers to any well-formed XML document.
1274 6. Initial Profile Registrations
1276 6.1 BXXP Channel Management
1278 Profile Identification: not applicable
1280 Elements Exchanged during Channel Creation: not applicable
1282 Messages in "REQ" frames: "start"
1284 Messages in positive "RSP" frames: "greeting" or "profile"
1286 Messages in negative "RSP" frames: "error"
1288 Message Syntax: c.f., Section 6.2
1290 Message Semantics: c.f., Section 2.3.1
1292 6.2 BXXP Channel Management DTD
1294
1310
1331
1332
1333
1334
1335
1336
1347
1348
1352
1353
1357
1358
1361
1362
1366 6.3 Registration: TLS Transport Security Profile
1368 Profile Identification: http://xml.resource.org/profiles/TLS
1370 Elements Exchanged during Channel Creation: "ready"
1372 Messages in "REQ" frames: "ready"
1374 Messages in positive "RSP" frames: "proceed"
1376 Messages in negative "RSP" frames: "error"
1378 Message Syntax: c.f., Section 6.4
1380 Message Semantics: c.f., Section 3.1.3
1382 6.4 TLS Transport Security Profile DTD
1384
1400
1409
1410
1413
1415 6.5 Registration: SASL Family of Profiles
1417 Profile Identification:
1418 http://xml.resource.org/profiles/sasl/MECHANISM, where
1419 "MECHANISM" is a token registered with the IANA[14]
1421 Elements Exchanged during Channel Creation: "blob"
1423 Messages in "REQ" frames: "blob"
1425 Messages in positive "RSP" frames: "blob"
1427 Messages in negative "RSP" frames: "error"
1429 Message Syntax: c.f., Section 6.6
1431 Message Semantics: c.f., Section 4.1.3
1433 6.6 SASL Family of Profiles DTD
1435
1451
1460
1461
1467 7. Reply Codes
1469 code meaning
1470 ==== =======
1471 421 service not available
1473 450 requested action not taken
1474 (e.g., lock already in use)
1476 451 requested action aborted
1477 (e.g., local error in processing)
1479 454 temporary authentication failure
1481 500 general syntax error
1482 (e.g., poorly-formed XML)
1484 501 syntax error in parameters
1485 (e.g., non-valid XML)
1487 504 parameter not implemented
1489 530 authentication required
1491 534 authentication mechanism insufficient
1492 (e.g., too weak, sequence exhausted, etc.)
1494 535 authentication failure
1496 537 action not authorized for user
1498 538 authentication mechanism requires encryption
1500 550 requested action not taken
1501 (e.g., no requested profiles are acceptable)
1503 553 parameter invalid
1505 554 transaction failed
1506 (e.g., policy violation)
1508 8. Security Considerations
1510 The BXXP framing mechanism, per se, provides no protection against
1511 attack; however, judicious use of initial tuning profiles provides
1512 varying degrees of assurance:
1514 1. If one of the profiles from the SASL family is used, refer to
1515 [5]'s Section 9 for a discussion of security considerations.
1517 2. If the TLS transport security profile is used (or if a SASL
1518 security layer is negotiated), then:
1520 1. A man-in-the-middle may remove the security-related profiles
1521 from the BXXP greeting or generate an error response to the
1522 "ready" element of the TLS transport security profile. A
1523 BXXP peer may be configurable to refuse to proceed without
1524 an acceptable level of privacy.
1526 2. A man-in-the-middle may cause a down-negotiation to the
1527 weakest cipher suite available. A BXXP peer should be
1528 configurable to refuse weak cipher suites.
1530 3. A man-in-the-middle may modify any protocol interactions
1531 prior to a successful negotiation. Upon completing the
1532 negotiation, a BXXP peer must discard previously cached
1533 information about the BXXP session.
1535 As different TLS ciphersuites provide varying levels of
1536 security, administrators should carefully choose which
1537 ciphersuites are provisioned.
1539 9. IANA Considerations
1541 The IANA registers "bxxp" as a GSSAPI[12] service name.
1543 The IANA maintains a list of:
1545 o BXXP reply codes, c.f., Section 7; and,
1547 o BXXP profiles that are defined in the RFC series.
1549 The IANA makes the registrations specified in Section 6.3 and
1550 Section 6.5.
1552 References
1554 [1] Rose, M.T., "On the Design of Application Protocols",
1555 draft-mrose-bxxp-design-00 (work in progress), June 2000.
1557 [2] World Wide Web Consortium, "Extensible Markup Language (XML)
1558 1.0", W3C XML, February 1998,
1559 .
1561 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1562 Extensions (MIME) Part One: Format of Internet Message
1563 Bodies", RFC 2045, November 1996.
1565 [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
1566 2246, January 1999.
1568 [5] Myers, J.G., "Simple Authentication and Security Layer
1569 (SASL)", RFC 2222, October 1997.
1571 [6] Rose, M.T., "Mapping the BXXP Framework onto TCP",
1572 draft-mrose-bxxp-tcpmapping-00 (work in progress), June 2000.
1574 [7] Postel, J., "Transmission Control Protocol", RFC 793, STD 7,
1575 Sep 1981.
1577 [8] Alvestrand, H., "Tags for the Identification of Languages",
1578 RFC 1766, March 1995.
1580 [9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
1581 Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1582 1998.
1584 [10] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
1585 October 1998.
1587 [11] Kent, S. and R. Atkinson, "Security Architecture for the
1588 Internet Protocol", RFC 2401, November 1998.
1590 [12] Linn, J., "Generic Security Service Application Program
1591 Interface, Version 2", RFC 2078, January 1997.
1593 [13] http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms
1595 [14] http://www.iana.org/
1597 [15] mailto:ddc@lcs.mit.edu
1599 [16] mailto:dcrocker@brandenburg.com
1601 [17] mailto:deering@cisco.com
1603 [18] mailto:gazzetta@invisible.net
1605 [19] mailto:dannyg@dannyg.com
1607 [20] mailto:Robert.Herriot@pahv.xerox.com
1609 [21] mailto:ben@algroup.co.uk
1611 [22] mailto:lear@cisco.com
1613 [23] mailto:carl@invisible.net
1615 [24] mailto:michaelm@netsol.com
1617 [25] mailto:pvm@a21.com
1619 [26] mailto:rlmorgan@washington.edu
1621 [27] mailto:fmorton@invisible.net
1623 [28] mailto:dnew@san.rr.com
1625 [29] mailto:chris.newman@innosoft.com
1627 [30] mailto:craig@bbn.com
1629 [31] mailto:touch@isi.edu
1631 [32] mailto:paul@vix.com
1633 [33] mailto:woods@invisible.net
1635 Author's Address
1637 Marshall T. Rose
1638 Invisible Worlds, Inc.
1639 1179 North McDowell Boulevard
1640 Petaluma, CA 94954-6559
1641 US
1643 Phone: +1 707 789 3700
1644 EMail: mrose@invisible.net
1645 URI: http://invisible.net/
1647 Appendix A. Acknowledgements
1649 The author gratefully acknowledges the contributions of: David
1650 Clark[15], Dave Crocker[16], Steve Deering[17], Marco Gazzetta[18],
1651 Danny Goodman[19], Robert Herriot[20], Ben Laurie[21], Eliot
1652 Lear[22], Carl Malamud[23], Michael Mealling[24], Paul
1653 Mockapetris[25], RL 'Bob' Morgan[26], Frank Morton[27], Darren
1654 New[28], Chris Newman[29], Craig Partridge[30], Joe Touch[31], Paul
1655 Vixie[32], and Daniel Woods[33]. In particular, Dave Crocker
1656 provided helpful suggestions on the nature of segmentation in the
1657 framing protocol.
1659 Full Copyright Statement
1661 Copyright (C) The Internet Society (2000). All Rights Reserved.
1663 This document and translations of it may be copied and furnished to
1664 others, and derivative works that comment on or otherwise explain it
1665 or assist in its implementation may be prepared, copied, published
1666 and distributed, in whole or in part, without restriction of any
1667 kind, provided that the above copyright notice and this paragraph
1668 are included on all such copies and derivative works. However, this
1669 document itself may not be modified in any way, such as by removing
1670 the copyright notice or references to the Internet Society or other
1671 Internet organizations, except as needed for the purpose of
1672 developing Internet standards in which case the procedures for
1673 copyrights defined in the Internet Standards process must be
1674 followed, or as required to translate it into languages other than
1675 English.
1677 The limited permissions granted above are perpetual and will not be
1678 revoked by the Internet Society or its successors or assigns.
1680 This document and the information contained herein is provided on an
1681 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1682 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1683 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1684 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1685 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1687 Invisible Worlds expressly disclaims any and all warranties
1688 regarding this contribution including any warranty that (a) this
1689 contribution does not violate the rights of others, (b) the owners,
1690 if any, of other rights in this contribution have been informed of
1691 the rights and permissions granted to IETF herein, and (c) any
1692 required authorizations from such owners have been obtained. This
1693 document and the information contained herein is provided on an "AS
1694 IS" basis and INVISIBLE WORLDS DISCLAIMS ALL WARRANTIES, EXPRESS OR
1695 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1696 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1697 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1699 IN NO EVENT WILL INVISIBLE WORLDS BE LIABLE TO ANY OTHER PARTY
1700 INCLUDING THE IETF AND ITS MEMBERS FOR THE COST OF PROCURING
1701 SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF
1702 DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES
1703 WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY
1704 WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT,
1705 WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF
1706 SUCH DAMAGES.
1708 Acknowledgement
1710 Funding for the RFC editor function is currently provided by the
1711 Internet Society.