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