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.