idnits 2.17.1 draft-mrose-bxxp-design-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 an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 208 has weird spacing: '...f which fit w...' == Line 514 has weird spacing: '...plexing pipel...' == Line 517 has weird spacing: '...er/pass user/...' == Line 663 has weird spacing: '...plexing indep...' -- 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 8692 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) -- Missing reference section? '1' on line 959 looks like a reference -- Missing reference section? '2' on line 962 looks like a reference -- Missing reference section? '3' on line 966 looks like a reference -- Missing reference section? '4' on line 969 looks like a reference -- Missing reference section? '5' on line 972 looks like a reference -- Missing reference section? '6' on line 975 looks like a reference -- Missing reference section? '7' on line 979 looks like a reference -- Missing reference section? '39' on line 1088 looks like a reference -- Missing reference section? '8' on line 983 looks like a reference -- Missing reference section? '9' on line 986 looks like a reference -- Missing reference section? '10' on line 989 looks like a reference -- Missing reference section? '11' on line 992 looks like a reference -- Missing reference section? '12' on line 995 looks like a reference -- Missing reference section? '13' on line 998 looks like a reference -- Missing reference section? '14' on line 1001 looks like a reference -- Missing reference section? '15' on line 1004 looks like a reference -- Missing reference section? '40' on line 1090 looks like a reference -- Missing reference section? '16' on line 1007 looks like a reference -- Missing reference section? '17' on line 1010 looks like a reference -- Missing reference section? '18' on line 1013 looks like a reference -- Missing reference section? '19' on line 1016 looks like a reference -- Missing reference section? '20' on line 1019 looks like a reference -- Missing reference section? '21' on line 1022 looks like a reference -- Missing reference section? '22' on line 1026 looks like a reference -- Missing reference section? '23' on line 1029 looks like a reference -- Missing reference section? '24' on line 1032 looks like a reference -- Missing reference section? '25' on line 1035 looks like a reference -- Missing reference section? '26' on line 1038 looks like a reference -- Missing reference section? '27' on line 1045 looks like a reference -- Missing reference section? '28' on line 1048 looks like a reference -- Missing reference section? '29' on line 1051 looks like a reference -- Missing reference section? '30' on line 1055 looks like a reference -- Missing reference section? '31' on line 1059 looks like a reference -- Missing reference section? '32' on line 1063 looks like a reference -- Missing reference section? '33' on line 1067 looks like a reference -- Missing reference section? '35' on line 1073 looks like a reference -- Missing reference section? '34' on line 1070 looks like a reference -- Missing reference section? '37' on line 1080 looks like a reference -- Missing reference section? '38' on line 1082 looks like a reference -- Missing reference section? '36' on line 1077 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 42 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 On the Design of Application Protocols 7 draft-mrose-bxxp-design-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 the design principles for the Blocks eXtensible 42 eXchange Protocol (BXXP). BXXP is a generic application protocol 43 framework for connection-oriented, asynchronous request/response 44 interactions. The framework permits multiplexing of independent 45 request/response streams over a single transport connection, 46 supporting both textual and binary messages. 48 Table of Contents 50 1. A Problem 19 Years in the Making . . . . . . . . . . . . . . . 3 51 2. You can Solve Any Problem... . . . . . . . . . . . . . . . . . 6 52 3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . . . 8 53 3.1 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 54 3.2 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 55 3.3 Error Reporting . . . . . . . . . . . . . . . . . . . . . . . 9 56 3.4 Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . 10 57 3.5 User Authentication . . . . . . . . . . . . . . . . . . . . . 11 58 3.6 Transport Security . . . . . . . . . . . . . . . . . . . . . . 12 59 3.7 Let's Recap . . . . . . . . . . . . . . . . . . . . . . . . . 13 60 4. Protocol Properties . . . . . . . . . . . . . . . . . . . . . 14 61 4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 4.2 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . 15 63 4.3 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . 15 64 4.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 65 5. The BXXP Framework . . . . . . . . . . . . . . . . . . . . . . 17 66 5.1 Framing and Encoding . . . . . . . . . . . . . . . . . . . . . 17 67 5.2 Error Reporting . . . . . . . . . . . . . . . . . . . . . . . 19 68 5.3 Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 5.4 User Authentication . . . . . . . . . . . . . . . . . . . . . 21 70 5.5 Transport Security . . . . . . . . . . . . . . . . . . . . . . 21 71 5.6 Things We Left Out . . . . . . . . . . . . . . . . . . . . . . 22 72 6. Current Status . . . . . . . . . . . . . . . . . . . . . . . . 23 73 7. To Be Determined... . . . . . . . . . . . . . . . . . . . . . 24 74 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27 76 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 28 78 1. A Problem 19 Years in the Making 80 SMTP[1] is close to being the perfect application protocol: it 81 solves a large, important problem in a minimalist way. It's simple 82 enough for an entry-level implementation to fit on one or two 83 screens of code, and flexible enough to form the basis of very 84 powerful product offerings in a robust and competitive market. 85 Modulo a few oddities (e.g., SAML), the design is well conceived and 86 the resulting specification is well-written and largely 87 self-contained. There is very little about good application protocol 88 design that you can't learn by reading the SMTP specification. 90 Unfortunately, there's one little problem: SMTP was originally 91 published in 1981 and since that time, a lot of application 92 protocols have been designed for the Internet, but there hasn't been 93 a lot of reuse going on. You might expect this if the application 94 protocols were all radically different, but this isn't the case: 95 most are surprisingly similar in their functional behavior, even 96 though the actual details vary considerably. 98 In late 1998, as Carl Malamud and I were sitting down to review the 99 Blocks architecture[2], we realized that we needed to have a 100 protocol for exchanging Blocks. The conventional wisdom is that when 101 you need an application protocol, there are four ways to proceed: 103 1. find an existing exchange protocol that (more or less) does what 104 you want; 106 2. define an exchange model on top of the world-wide web 107 infrastructure that (more or less) does what you want; 109 3. define an exchange model on top of the electronic mail 110 infrastructure that (more or less) does what you want; or, 112 4. define a new protocol from scratch that does exactly what you 113 want. 115 An engineer can make reasoned arguments about the merits of each of 116 the these approaches. Here's the process we followed... 118 The most appealing option is to find an existing protocol and use 119 that. (In other words, we'd rather "buy" than "make".) So, we did a 120 survey of many existing application protocols and found that none of 121 them were a good match for the semantics of the protocol we needed. 123 For example, most application protocols are oriented toward 124 client/server behavior, and emphasize the client pulling data from 125 the server; in contrast with Blocks, a client usually pulls data 126 from the server, but it also may request the server to 127 asynchronously push (new) data to it. Clearly, we could mutate a 128 protocol such as FTP[3] or SMTP into what we wanted, but by the time 129 we did all that, the base protocol and our protocol would have more 130 differences than similarities. In other words, the cost of modifying 131 an off-the-shelf implementation becomes comparable with starting 132 from scratch. 134 Another approach is to use HTTP[4] as the exchange protocol and 135 define the rules for data exchange over that. For example, IPP[5] 136 (the Internet Printing Protocol) uses this approach. The basic idea 137 is that HTTP defines the rules for exchanging data and then you 138 define the data's syntax and semantics. Because you inherit the 139 entire HTTP infrastructure (e.g., HTTP's authentication mechanisms, 140 caching proxies, and so on), there's less for you to have to invent 141 (and code!). Or, conversely, you might view the HTTP infrastructure 142 as too helpful. As an added bonus, if you decide that your protocol 143 runs over port 80, you may be able to sneak your traffic past older 144 firewalls, at the cost of port 80 saturation. 146 HTTP has many strengths: it's ubiquitous, it's familiar, and there 147 are a lot of tools available for developing HTTP-based systems. 148 Another good thing about HTTP is that it uses MIME[6] for encoding 149 data. 151 Unfortunately for us, even with HTTP 1.1[7], there still wasn't a 152 good fit. As a consequence of the highly-desirable goal of 153 maintaining compatibility with the original HTTP, HTTP's framing 154 mechanism isn't flexible enough to support server-side asynchronous 155 behavior and its authentication model isn't similar to other 156 Internet applications. 158 Mapping IPP onto HTTP 1.1 illustrates the latter issue. For example, 159 the IPP server is supposed to signal its client when a job 160 completes. Since the HTTP client must originate all requests and 161 since the decision to close a persistent connection in HTTP is 162 unilateral, the best that the IPP specification can do is specify 163 this functionality in a non-deterministic fashion. 165 Further, the IPP mapping onto HTTP shows that even subtle shifts in 166 behavior have unintended consequences. For example, requests in IPP 167 are typically much larger than those seen by many HTTP server 168 implementations -- resulting in oddities in many HTTP servers (e.g., 169 requests are sometimes silently truncated). The lesson is that 170 HTTP's framing mechanism is very rigid with respect to its view of 171 the request/response model. 173 Lastly, given our belief that the port field of the TCP header isn't 174 a constant 80, we were immune to the seductive allure of wanting to 175 sneak our traffic past unwary site administrators. 177 The third choice, layering the protocol on top of e-mail, was 178 attractive. Unfortunately, the nature of our application includes a 179 lot of interactivity with relatively small response times. So, this 180 left us the final alternative: defining a protocol from scratch. 182 To begin, we figured that our requirements, while a little more 183 stringent than most, could fit inside a framework suitable for a 184 large number of future application protocols. The trick is to avoid 185 the kitchen-sink approach. (Dave Clark[39] has a saying: "One of the 186 roles of architecture is to tell you what you can't do.") 188 2. You can Solve Any Problem... 190 ...if you're willing to make the problem small enough. 192 Our most important step is to limit the problem to application 193 protocols that exhibit certain features: 195 o they are connection-oriented; 197 o they use requests and responses to exchange messages; and, 199 o they allow for asynchronous message exchange. 201 Let's look at each, in turn. 203 First, we're only going to consider connection-oriented application 204 protocols (e.g., those that work on top of TCP[8]). Another branch 205 in the taxonomy, connectionless, consists of those that don't want 206 the delay or overhead of establishing and maintaining a reliable 207 stream. For example, most DNS[9] traffic is characterized by a 208 single request and response, both of which fit within a single IP 209 datagram. In this case, it makes sense to implement a basic 210 reliability service above the transport layer in the application 211 protocol itself. 213 Second, we're only going to consider message-oriented application 214 protocols. A "message" -- in our lexicon -- is simply structured 215 data exchanged between loosely-coupled systems. Another branch in 216 the taxonomy, tightly-coupled systems, uses remote procedure calls 217 as the exchange paradigm. Unlike the 218 connection-oriented/connectionless dichotomy, the issue of loosely- 219 or tightly-coupled systems is similar to a continuous spectrum. 220 Fortunately, the edges are fairly sharp. 222 For example, NFS[10] is a tightly-coupled system using RPCs. When 223 running in a properly-configured LAN, a remote disk accessible via 224 NFS is virtually indistinguishable from a local disk. To achieve 225 this, tightly-coupled systems are highly concerned with issues of 226 latency. Hence, most (but not all) tightly-coupled systems use 227 connection-less RPC mechanisms; further, most tend to be implemented 228 as operating system functions rather than user-level programs. (In 229 some environments, the tightly-coupled systems are implemented as 230 single-purpose servers, on hardware specifically optimized for that 231 one function.) 233 Finally, we're going to consider the needs of application protocols 234 that exchange messages asynchronously. The classic client/server 235 model is that the client sends a request and the server sends a 236 response. If you think of requests as "questions" and responses as 237 "answers", then the server answers only those questions that it's 238 asked and it never asks any questions of its own. We'll need to 239 support a more general model, peer-to-peer. In this model, for a 240 given transaction one peer might be the "client" and the other the 241 "server", but for the next transaction, the two peers might switch 242 roles. 244 It turns out that the client/server model is a proper subset of the 245 peer-to-peer model: it's acceptable for a particular application 246 protocol to dictate that the peer that establishes the connection 247 always acts as the client (initiates requests), and that the peer 248 that listens for incoming connections always acts as the server 249 (issuing responses to requests). 251 There are quite a few existing application domains that don't fit 252 our requirements, e.g., nameservice (via the DNS), fileservice (via 253 NFS), multicast-enabled applications such as distributed video 254 conferencing, and so on. However, there are a lot of application 255 domains that do fit these requirements, e.g., electronic mail, file 256 transfer, remote shell, and the world-wide web. So, the bet we are 257 placing in going forward is that there will continue to be reasons 258 for defining protocols that fit within our framework. 260 3. Protocol Mechanisms 262 The next step is to look at the tasks that an application protocol 263 must perform and how it goes about performing them. Although an 264 exhaustive exposition might identify a dozen (or so) areas, the ones 265 we're interested in are: 267 o framing, which tells how the beginning and ending of each message 268 is delimited; 270 o encoding, which tells how a message is represented when exchanged; 272 o error reporting, which tells how errors are described; 274 o multiplexing, which tells how independent parallel exchanges are 275 handled; 277 o user authentication, which tells how the peers at each end of the 278 connection are identified and verified; and, 280 o transport security, which tells how the exchanges are protected 281 against third-party interception or modification. 283 A notable absence in this list is naming -- we'll explain why later 284 on. 286 3.1 Framing 288 There are three commonly used approaches to delimiting messages: 289 octet-stuffing, octet-counting, and connection-blasting. 291 An example of a protocol that uses octet-stuffing is SMTP. Commands 292 in SMTP are line-oriented (each command ends in a CR-LF pair). When 293 an SMTP peer sends a message, it first transmits the "DATA" command, 294 then it transmits the message, then it transmits a "." (dot) 295 followed by a CR-LF. If the message contains any lines that begin 296 with a dot, the sending SMTP peer sends two dots; similarly, when 297 the other SMTP peer receives a line that begins with a dot, it 298 discards the dot, and, if the line is empty, then it knows it's 299 received the entire message. Octet-stuffing has the property that 300 you don't need the entire message in front of you before you start 301 sending it. Unfortunately, it's slow because both the sender and 302 receiver must scan each line of the message to see if they need to 303 transform it. 305 An example of a protocol that uses octet-counting is HTTP. Commands 306 in HTTP consist of a request line followed by headers and a body. 307 The headers contain an octet count indicating how large the body is. 308 The properties of octet-counting are the inverse of octet-stuffing: 310 before you can start sending a message you need to know the length 311 of the whole message, but you don't need to look at the content of 312 the message once you start sending or receiving. 314 An example of a protocol that uses connection-blasting is FTP. 315 Commands in FTP are line-oriented, and when it's time to exchange a 316 message, a new TCP connection is established to transmit the 317 message. Both octet-counting and connection-blasting have the 318 property that the messages can be arbitrary binary data; however, 319 the drawback of the connection-blasting approach is that the peers 320 need to communicate IP addresses and TCP port numbers, which may be 321 "transparently" altered by NATS[11] and network bugs. In addition, 322 if the messages being exchanged are small (say less than 32k), then 323 the overhead of establishing a connection for each message 324 contributes significant latency during data exchange. 326 3.2 Encoding 328 There are many schemes used for encoding data (and many more 329 encoding schemes have been proposed than are actually in use). 330 Fortunately, only a few are burning brightly on the radar. 332 The messages exchanged using SMTP are encoded using the 333 822-style[12]. The 822-style divides a message into textual headers 334 and an unstructured body. Each header consists of a name and a value 335 and is terminated with a CR-LF pair. An additional CR-LF separates 336 the headers from the body. 338 It is this structure that HTTP uses to indicate the length of the 339 body for framing purposes. More formally, HTTP uses MIME, an 340 application of the 822-style to encode both the data itself (the 341 body) and information about the data (the headers). That is, 342 although HTTP is commonly viewed as a retrieval mechanism for 343 HTML[13], it is really a retrieval mechanism for objects encoded 344 using MIME, most of which are either HTML pages or referenced 345 objects such as GIFs. 347 3.3 Error Reporting 349 An application protocol needs a mechanism for conveying error 350 information between peers. The first formal method for doing this 351 was defined by SMTP's "theory of reply codes". The basic idea is 352 that an error is identified by a three-digit string, with each 353 position having a different significance: 355 the first digit: indicating success or failure, either permanent or 356 transient; 358 the second digit: indicating the part of the system reporting the 359 situation (e.g., the syntax analyzer); and, 361 the third digit: identifying the actual situation. 363 Operational experience with SMTP suggests that the range of error 364 conditions is larger than can be comfortably encoded using a 365 three-digit string (i.e., you can report on only 10 different things 366 going wrong for any given part of the system). So, [14] provides a 367 convenient mechanism for extending the number of values that can 368 occur in the second and third positions. 370 Virtually all of the application protocols we've discussed thus far 371 use the three-digit reply codes, although there is less coordination 372 between the designers of different application protocols than most 373 would care to admit. (A notable exception to the theory of reply 374 codes is IMAP[15] which uses error "tokens" instead of three-digit 375 codes.) 377 In addition to conveying a reply code, most application protocols 378 also send a textual diagnostic suitable for human, not machine, 379 consumption. (More accurately, the textual diagnostic is suitable 380 for people who can read a widely used variant of the English 381 language.) Since reply codes reflect both positive and negative 382 outcomes, there have been some innovative uses made for the text 383 accompanying positive responses, e.g., prayer wheels[40]. 384 Regardless, some of the more modern application protocols include a 385 language localization parameter for the diagnostic text. 387 Finally, since the introduction of reply codes in 1981, two 388 unresolved criticisms have been raised: 390 o a reply code is used both to signal the outcome of an operation 391 and a change in the application protocol's state; and, 393 o a reply code doesn't specify whether the associated textual 394 diagnostic is destined for the end-user, administrator, or 395 programmer. 397 3.4 Multiplexing 399 Few application protocols today allow independent parallel exchanges 400 over the same connection. In fact, the more widely implemented 401 approach is to allow pipelining, e.g., command pipelining[16] in 402 SMTP or persistent connections in HTTP 1.1. Pipelining allows a 403 client to make multiple requests of a server, but requires the 404 requests to be processed serially. (Note that a protocol needs to 405 explicitly provide support for pipelining, since, without explicit 406 guidance, many implementors produce systems that don't handle 407 pipelining properly; typically, an error in a request causes 408 subsequent requests in the pipeline to be discarded). 410 Pipelining is a powerful method for reducing network latency. For 411 example, without persistent connections, HTTP's framing mechanism is 412 really closer to connection-blasting than octet-counting, and it 413 enjoys the same latency and efficiency problems. 415 In addition to reducing network latency (the pipelining effect), 416 parallelism also reduces server latency by allowing multiple 417 requests to be processed by multi-threaded implementations. Note 418 that if you allow any form of asynchronous exchange, then support 419 for parallelism is also required, because exchanges aren't 420 necessarily occurring under the synchronous direction of a single 421 peer. 423 Unfortunately, when you allow parallelism, you also need a flow 424 control mechanism to avoid starvation and deadlock. Otherwise, a 425 single set of exchanges can monopolize the bandwidth provided by the 426 transport layer. Further, if a peer is resource-starved, then it may 427 not have enough buffers to receive a message and deadlock results. 429 Flow control is typically implemented at the transport layer. For 430 example, TCP uses sequence numbers and a sliding window: each 431 receiver manages a sliding window that indicates the number of data 432 octets that may be transmitted before receiving further permission. 433 However, it's now time for the third shoe of multiplexing to drop: 434 segmentation. If you do flow control then you also need a 435 segmentation mechanism to fragment messages into smaller pieces 436 before sending and then re-assemble them as they're received. 438 All three of the multiplexing issues: parallelism, flow control, and 439 segmentation have an impact on how the protocol does framing. Before 440 we defined framing as "how to tell the beginning and end of each 441 message" -- in addition, we need to be able to identify independent 442 messages, send messages only when flow control allows us to, and 443 segment them if they're larger than the available window (or too 444 large for comfort). 446 Segmentation impacts framing in another way -- it relaxes the 447 octet-counting requirement that you need to know the length of the 448 whole message before sending it. With segmentation, you can start 449 sending segments before the whole message is available. In HTTP 1.1 450 you can "chunk" (segment) data to get this advantage. 452 3.5 User Authentication 454 Perhaps for historical (or hysterical) reasons, most application 455 protocols don't do authentication. That is, they don't authenticate 456 the identity of the peers on the connection or the authenticity of 457 the messages being exchanged. Or, if authentication is done, it is 458 domain-specific for each protocol. For example, FTP and HTTP use 459 entirely different models and mechanisms for authenticating the 460 initiator of a connection. (Independent of mainstream HTTP, there is 461 a little-used variant[17] that authenticates the messages it 462 exchanges.) 464 A few years ago, SASL[18] (the Simple Authentication and Security 465 Layer) was developed to provide a framework for authenticating 466 protocol peers. SASL let's you describe how an authentication 467 mechanism works, e.g., an OTP[19] (One-Time Password) exchange. It's 468 then up to each protocol designer to specify how SASL exchanges are 469 conveyed by the protocol. For example, [20] explains how SASL works 470 with SMTP. 472 A notable exception to the SASL bandwagon is HTTP, which defines its 473 own authentication mechanisms[21]. There is little reason why SASL 474 couldn't be introduced to HTTP, although to avoid race-conditions 475 with the use of OTP, the persistent connection mechanism of HTTP 1.1 476 must be used. 478 SASL has an interesting feature in that in addition to explicit 479 protocol exchanges to authenticate identity, it can also use 480 implicit information provided from the layer below. For example, if 481 the connection is running over IPsec[22], then the credentials of 482 each peer are known and verified when the TCP connection is 483 established. 485 3.6 Transport Security 487 HTTP is the first widely used protocol to make use of transport 488 security to encrypt the data sent on the connection. The current 489 version of this mechanism, TLS[23], is also available for SMTP and 490 other application protocols such as ACAP[24] (the Application 491 Configuration Access Protocol). 493 The key difference between the original mechanism and TLS, is one of 494 provisioning. In the initial approach, a world-wide web server would 495 listen on two ports, one for plaintext traffic and the other for 496 secured traffic; in contrast, a server implementing an application 497 protocol that is TLS-enabled listens on a single port for plaintext 498 traffic; once a connection is established, the use of TLS is 499 negotiated by the peers. 501 3.7 Let's Recap 503 Let's briefly compare the properties of the three main 504 connection-oriented application protocols in use today: 506 Mechanism SMTP FTP HTTP 507 ------------------- ---------- --------- ------------- 508 Framing Stuffing Blasting Counting 510 Encoding 822-style Binary MIME 512 Error Reporting 3-digit 3-digit 3-digit 514 Multiplexing pipelining none persistent 515 and chunky 517 User Authentication SASL user/pass user/pass 519 Transport Security TLS none TLS (nee SSL) 521 Note that the username/password mechanisms used by FTP and HTTP are 522 entirely different with one exception: both can be termed a 523 "username/password" mechanism. 525 These three choices are broadly representative: as more protocols 526 are considered, the patterns are reinforced. For example, POP[25] 527 uses octet-stuffing, but IMAP uses octet-counting, and so on. 529 4. Protocol Properties 531 When we design an application protocol, there are a few properties 532 that we should keep an eye on. 534 4.1 Scalability 536 A well-designed protocol is scalable. 538 Because few application protocols support multiplexing, a common 539 trick is for a program to open multiple simultaneous connections to 540 a single destination. The theory is that this reduces latency and 541 increases throughput. The reality is that both the transport layer 542 and the server view each connection as an independent instance of 543 the application protocol, and this causes problems. 545 In terms of the transport layer, TCP uses adaptive algorithms to 546 efficiently transmit data as networks conditions change. But what 547 TCP learns is limited to each connection. So, if you have multiple 548 TCP connections, you have to go through the same learning process 549 multiple times -- even if you're going to the same host. Not only 550 does this introduce unnecessary traffic spikes into the network, 551 because TCP uses a slow-start algorithm when establishing a 552 connection, the program still sees additional latency. To deal with 553 the fact that a lack of multiplexing in application protocols causes 554 implementors to make sloppy use of the transport layer, network 555 protocols are now provisioned with increasing sophistication, e.g., 556 RED[26]. Further, suggestions are also being considered for 557 modification of TCP implementations to reduce concurrent learning, 558 e.g., [27]. 560 In terms of the server, each incoming connection must be dispatched 561 and (probably) authenticated against the same resources. 562 Consequently, server overhead increases based on the number of 563 connections established, rather than the number of remote users. The 564 same issues of fairness arise: it's much harder for servers to 565 allocate resources on a per-user basis, when a user can cause an 566 arbitrary number of connections to pound on the server. 568 Another important aspect of scalability to consider is the relative 569 numbers of clients and servers. (This is true even in the 570 peer-to-peer model, where a peer can act both in the client and 571 server role.) Typically, there are many more client peers than 572 server peers. In this case, functional requirements should be 573 shifted from the servers onto the clients. The reason is that a 574 server is likely to be interacting with multiple clients and this 575 functional shift makes it easier to scale. 577 4.2 Efficiency 579 A well-designed protocol is efficient. 581 For example, although a compelling argument can be made than 582 octet-stuffing leads to more elegant implementations than 583 octet-counting, experience shows that octet-counting consumes far 584 fewer cycles. 586 Regrettably, we sometimes have to compromise efficiency in order to 587 satisfy other properties. For example, 822 (and MIME) use textual 588 headers. We could certainly define a more efficient representation 589 for the headers if we were willing to limit the header names and 590 values that could be used. In this case, extensibility is viewed as 591 more important than efficiency. Of course, if we were designing a 592 network protocol instead of an application protocol, then we'd make 593 the trade-offs using a razor with a different edge. 595 4.3 Simplicity 597 A well-designed protocol is simple. 599 Here's a good rule of thumb: a poorly-designed application protocol 600 is one in which it is equally as "challenging" to do something basic 601 as it is to do something complex. Easy things should be easy to do 602 and hard things should be harder to do. The reason is simple: the 603 pain should be proportional to the gain. 605 Another rule of thumb is that if an application protocol has two 606 ways of doing the exact same thing, then there's a problem somewhere 607 in the architecture underlying the design of the application 608 protocol. 610 Hopefully, simple doesn't mean simple-minded: something that's 611 well-designed accommodates everything in the problem domain, even 612 the troublesome things at the edges. What makes the design simple is 613 that it does this in a consistent fashion. Typically, this leads to 614 an elegant design. 616 4.4 Extensibility 618 A well-designed protocol is extensible. 620 As clever as application protocol designers are, there are likely to 621 be unforeseen problems that the application protocol will be asked 622 to solve. So, it's important to provide the hooks that can be used 623 to add functionality or customize behavior. This means that the 624 protocol is evolutionary, and there must be a way for 625 implementations reflecting different steps in the evolutionary path 626 to negotiate which extensions will be used. 628 But, it's important to avoid falling into the extensibility trap: 629 the hooks provided should not be targeted at half-baked future 630 requirements. Above all, the hooks should be simple. 632 Of course good design goes a long way towards minimizing the need 633 for extensibility. For example, although SMTP initially didn't have 634 an extension framework, it was only after ten years of experience 635 that its excellent design was altered. In contrast, a 636 poorly-designed protocol such as Telnet[28] can't function without 637 being built around the notion of extensions. 639 5. The BXXP Framework 641 Finally, we get to the money shot: here's what we did. 643 We defined an application protocol framework called BXXP (the Blocks 644 eXtensible eXchange Protocol). The reason it's a "framework" instead 645 of an application protocol is that we provide all the mechanisms 646 discussed earlier without actually specifying the kind of messages 647 that get exchanged. So, when someone else needs an application 648 protocol that requires connection-oriented, asynchronous 649 request/response interactions, they can start with BXXP. It's then 650 their responsibility to define the last 10% of the application 651 protocol, the part that does, as we say, "the useful work". 653 So, what does BXXP look like? 655 Mechanism BXXP 656 ------------------- ---------------------------------------- 657 Framing Counting, with a trailer 659 Encoding MIME, defaulting to text/xml 661 Error Reporting 3-digit and localized textual diagnostic 663 Multiplexing independent request/response streams 665 User Authentication SASL 667 Transport Security SASL or TLS 669 5.1 Framing and Encoding 671 Framing in BXXP looks a lot like SMTP or HTTP: there's a command 672 line that identifies the beginning of the frame, then there's a MIME 673 object (headers and body). Unlike SMTP, BXXP uses octet-counting, 674 but unlike HTTP, the command line is where you find the size of the 675 payload. Finally, there's a trailer after the MIME object to aid in 676 detecting framing errors. 678 Actually, the command line for BXXP has a lot of information, it 679 tells you: 681 o whether this frame contains a request or response; 683 o whether there's more to the message than just what's in this 684 frame (a continuation flag); 686 o how to distinguish the message contained in this frame from other 687 messages (a serial number); 689 o where the payload occurs in the sliding window (a sequence 690 number) along with how many octets are in the payload of this 691 frame; and, 693 o which part of the system should get the message (for requests) or 694 whether this is a positive or negative response. 696 (The command line is textual and ends in a CR-LF pair, and the 697 arguments are separated by a space.) 699 Since you need to know all this stuff to process a frame, we put it 700 all in one easy to parse location. You could probably devise a more 701 efficient encoding, but the command line is a very small part of the 702 frame, so you wouldn't get much bounce from optimizing it. Further, 703 because framing is at the heart of BXXP, the frame format has 704 several consistency checks that catch the majority of programming 705 errors. (The combination of a sequence number, an octet count, and a 706 trailer allows for very robust error detection.) 708 Another trick is in the headers: because the command line contains 709 all the framing information, the headers may contain minimal MIME 710 information (such as Content-Type). Usually, however, the headers 711 are empty. That's because the BXXP default payload is XML[29]. 712 (Actually, a "Content-Type: text/xml" with binary transfer encoding). 714 We chose XML as the default because it provides a simple mechanism 715 for nested, textual representations. (Alas, the 822-style encoding 716 doesn't easily support nesting.) By design, XML's nature isn't 717 optimized for compact representations. That's okay because we're 718 focusing on loosely-coupled systems and besides there are efficient 719 XML parsers available. Further, there's a fair amount of anecdotal 720 experience -- and we'll stress the word "anecdotal" -- that if you 721 have any kind of compression (either at the link-layer or during 722 encryption), then XML encodings squeeze down nicely. 724 Even so, use of XML is probably the most controversial part of BXXP. 725 After all, there are more efficient representations around. We 726 agree, but the real issue isn't efficiency, it's ease of use: there 727 are a lot of people who grok the XML thing and there are a lot of 728 XML tools out there. The pain of recreating this social 729 infrastructure far outweighs any benefits of devising a new 730 representation. So, if the "make" option is too expensive, is there 731 something else we can "buy" besides XML? Well, there's ASN.1/BER 732 (just kidding). 734 In the early days of the SNMP[30], which does use ASN.1, the same 735 issues arose. In the end, the working group agreed that the use of 736 ASN.1 for SNMP was axiomatic, but not because anyone thought that 737 ASN.1 was the most efficient, or the easiest to explain, or even 738 well liked. ASN.1 was given axiomatic status because the working 739 group decided it was not going to spend the next three years 740 explaining an alternative encoding scheme to the developer community. 742 So -- and we apologize for appealing to dogma -- use of XML as the 743 favored encoding scheme in BXXP is axiomatic. 745 5.2 Error Reporting 747 We use 3-digit error codes, with a localized textual diagnostic. 748 (Each peer specifies a preferred ordering of languages.) 750 In addition, the response message to a request is flagged as either 751 positive or negative. This makes it easy to signal success or 752 failure and allow the receiving peer some freedom in the amount of 753 parsing it wants to do on failure. 755 5.3 Multiplexing 757 Despite the lessons of SMTP and HTTP, there isn't a lot of field 758 experience to rely on when designing the multiplexing features of 759 BXXP. (Actually, there were several efforts in 1998 related to 760 application layer framing, e.g., [31], but none appear to have 761 achieved orbit.) 763 So, here's what we did: frames are exchanged in the context of a 764 "channel". Each channel has an associated "profile" that defines the 765 syntax and semantics of the messages exchanged over a channel. 767 Channels provide both an extensibility mechanism for BXXP and the 768 basis for multiplexing. Remember the last parameter in the command 769 line of a BXXP frame? The "part of the system" that gets the message 770 is identified by a channel number. 772 A profile is defined according to a "Profile Registration" template. 773 The template defines how the profile is identified (using a 774 URI[32]), what kind of messages get exchanged during channel 775 creation, what kind of messages get sent in requests and responses, 776 along with the syntax and semantics of those messages. When you 777 create a channel, you identify a profile and maybe piggyback your 778 first request. If the channel is successfully created, you get back 779 a positive response; otherwise, you get back a negative response 780 explaining why. 782 Perhaps the easiest way to see how channels provide an extensibility 783 mechanism is to consider what happens when a connection is 784 established. The BXXP peer that accepted the connection sends a 785 greeting on channel zero identifying the profiles that it supports. 786 (Channel 0 is used for channel management -- it's automatically 787 created when a connection is opened.) If you want transport 788 security, the very first thing you do is to create a channel that 789 negotiates transport security, and, once the channel is created, you 790 tell it to do its thing. Next, if you want to authenticate, you 791 create a channel that performs user authentication, and, once the 792 channel is created, you tell it to get busy. At this point, you 793 create one or more channels for data exchange. This process is 794 called "tuning"; once you've tuned the connection, you start using 795 the data exchange channels to do "the useful work". 797 The first channel that's successfully started has a trick associated 798 with it: when you ask to start the channel, you're allowed to 799 specify a "service name" that goes with it. This allows a server 800 with multiple configurations to select one based on the client's 801 suggestion. (A useful analogy is HTTP 1.1's "Host:" header.) If the 802 server accepts the "service name", then this configuration is used 803 for the rest of the connection. 805 To allow parallelism, BXXP allows you to use multiple channels 806 simultaneously. Each channel processes requests serially, but there 807 are no constraints on the processing order for different channels. 808 So, in a multi-threaded implementation, each channel maps to its own 809 thread. 811 This is the most general case, of course. For one reason or another, 812 an implementor may not be able to support this. So, BXXP allows for 813 both positive and negative responses when a request is made. So, if 814 you want the classic client/server model, the client program should 815 simply reject any requests made by the server. This effectively 816 throttles any asynchronous messages from the server. 818 Of course, we now need to provide mechanisms for segmentation and 819 flow control. For the former, we just put a "continuation" or "more 820 to come" flag in the command line for the frame. For the latter, we 821 introduced the notion of a "transport mapping". 823 What this means is that BXXP doesn't directly define how it sits of 824 top of TCP. Instead, it lists a bunch of requirements for how a 825 transport service needs to support a BXXP session. Then, in a 826 separate document, we defined how you can use TCP to meet these 827 requirements. 829 This second document pretty much says "use TCP directly", except 830 that it introduces a flow control mechanism for multiplexing 831 channels over a single TCP connection. The mechanism we use is the 832 same one used by TCP (sequence numbers and a sliding window). It's 833 proven, and can be trivially implemented by a minimal implementation 834 of BXXP. 836 The introduction of flow control is a burden from an implementation 837 perspective -- although TCP's mechanism is conceptually simple, an 838 implementor must take great care. For example, issues such as 839 priorities, queue management, and the like should be addressed. 840 Regardless, we feel that the benefits of allowing parallelism for 841 intra-application streams is worth it. (Besides, our belief is that 842 few application implementors will actually code the BXXP framework 843 directly -- rather, we expect them to use third-party packages that 844 implement BXXP.) 846 5.4 User Authentication 848 We use SASL. If you successfully authenticate using a channel, then 849 there is a single user identity for each peer on that connection 850 (i.e., authentication is per-connection, not per-channel). This 851 design decision mandates that each connection correspond to a single 852 user regardless of how many channels are open on that connection. 853 One reason why this is important is that it allows service 854 provisioning, such as quality of service (e.g., as in [33]) to be 855 done on a per-user granularity. 857 5.5 Transport Security 859 We use SASL and TLS. If you successfully complete a transport 860 security negotiation using a channel, then all traffic on that 861 connection is secured (i.e., confidentiality is per-connection, not 862 per-channel, just like authentication). 864 We defined a BXXP profile that's used to start the TLS engine. 866 5.6 Things We Left Out 868 We purposefully excluded two things that are common to most 869 application protocols: naming and authorization. 871 Naming was excluded from the framework because, outside of URIs, 872 there isn't a commonly accepted framework for naming things. To our 873 view, this remains a domain-specific problem for each application 874 protocol. Maybe URIs are appropriate in the context of a 875 particularly problem domain, maybe not. So, when an application 876 protocol designer defines their own profile to do "the useful work", 877 they'll have to deal with naming issues themselves. BXXP provides a 878 mechanism for identifying profiles and binding them to channels. 879 It's up to you to define the profile and use the channel. 881 Similarly, authorization was explicitly excluded from the framework. 882 Every approach to authorization we've seen uses names to identify 883 principals (i.e., targets and subjects), so if a framework doesn't 884 include naming, it can't very well include authorization. 886 Of course, application protocols do have to deal with naming and 887 authorization -- those are two of the issues addressed by the 888 applications protocol designer when defining a profile for use with 889 BXXP. 891 6. Current Status 893 So, how do you go about using BXXP? 895 First, get the framework specification[35] and read it. Next, define 896 your own profile. Finally, get one of the open source SDKs (in Perl 897 or Java) and start coding. 899 The BXXP specification defines several profiles itself: a channel 900 management profile, a family of profiles for SASL, and a transport 901 layer security profile. These provide good examples. Of course, 902 we've been using BXXP internally for a year and a half now, so if 903 you want to look at a rather detailed profile definition, check out 904 the Blocks Simple Exchange[34] profile. It addresses the issue of 905 naming for its application domain, and, in doing so, opens the door 906 for authorization. 908 7. To Be Determined... 910 Since the initial publication of BXXP, we've gotten some pretty good 911 feedback. As a result, a number of changes and clarifications were 912 incorporated. There are, however, a few open issues that we'll need 913 to decide soon: 915 closing channels: At present, channel management doesn't allow you 916 to close a channel -- we never envisioned the need given that 917 BXXP allows 127 channels to be open by each peer. However, the 918 question comes up a lot. We can either add this functionality to 919 channel management, increase the number of channels, or do 920 nothing. 922 reply code limitations: At present, BXXP has a generic "error" 923 element used to convey a reply code and textual diagnostic. This 924 element doesn't address either of the two issues currently raised 925 with reply codes: overloading of the first digit and diagnostic 926 targeting. 928 textual debugging: At present, it's hard to debug BXXP sessions by 929 hand because the framing protocol includes an octet count. One 930 suggestion is to add an optional feature to BXXP that uses the 931 trailer as the final delimiter, at the cost of reducing both the 932 efficiency and robustness of the framing protocol. 934 transport mappings: At present, only one transport mapping for BXXP 935 has been defined (the mapping of a BXXP session onto a single TCP 936 connection). Other mappings are possible, most notably onto 937 UDP[37] or onto SCTP[38]. 939 In mapping the BXXP framework onto UDP, additional mechanisms 940 must be added, e.g., achieving reliability through 941 retransmission. 943 In mapping the BXXP framework onto SCTP, BXXP can achieve 944 multiplexing without having to provide a mechanism for flow 945 control. The reason is that SCTP explicitly separates reliabilty 946 from flow control (in TCP they are bundled together). In essence, 947 each BXXP channel would have a separate window managed by SCTP, 948 and yet retain congestion avoidance characteristics across the 949 entire BXXP connection. Accordingly, a future mapping of BXXP 950 onto SCTP is simpler than the TCP mapping defined in [36]. 952 the name: A lot of folks on slashdot think that we should call this 953 BEEP. We have to admit, there are a lot of comic possibilities... 955 If you have an opinion on any of these issues, let us know! 957 References 959 [1] Postel, J., "Simple Mail Transfer Protocol", RFC 821, STD 10, 960 Aug 1982. 962 [2] Rose, M.T. and C. Malamud, "Blocks: Architectural Precepts", 963 draft-mrose-blocks-architecture-01 (work in progress), March 964 2000. 966 [3] Postel, J. and J.K. Reynolds, "File Transfer Protocol", RFC 967 959, STD 9, Oct 1985. 969 [4] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext 970 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 972 [5] Herriot, R., "Internet Printing Protocol/1.0: Encoding and 973 Transport", RFC 2565, April 1999. 975 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 976 Extensions (MIME) Part One: Format of Internet Message 977 Bodies", RFC 2045, November 1996. 979 [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 980 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol 981 -- HTTP/1.1", RFC 2616, June 1999. 983 [8] Postel, J., "Transmission Control Protocol", RFC 793, STD 7, 984 Sep 1981. 986 [9] Mockapetris, P.V., "Domain names - concepts and facilities", 987 RFC 1034, STD 13, Nov 1987. 989 [10] Microsystems, Sun, "NFS: Network File System Protocol 990 specification", RFC 1094, Mar 1989. 992 [11] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 993 (NAT) Terminology and Considerations", RFC 2663, August 1999. 995 [12] Crocker, D., "Standard for the format of ARPA Internet text 996 messages", RFC 822, STD 11, Aug 1982. 998 [13] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 999 2.0", RFC 1866, November 1995. 1001 [14] Freed, N., "SMTP Service Extension for Returning Enhanced 1002 Error Codes", RFC 2034, October 1996. 1004 [15] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, 1005 December 1994. 1007 [16] Freed, N., "SMTP Service Extension for Command Pipelining", 1008 RFC 2197, September 1997. 1010 [17] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer 1011 Protocol", RFC 2660, August 1999. 1013 [18] Myers, J.G., "Simple Authentication and Security Layer 1014 (SASL)", RFC 2222, October 1997. 1016 [19] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, 1017 October 1998. 1019 [20] Myers, J., "SMTP Service Extension for Authentication", RFC 1020 2554, March 1999. 1022 [21] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1023 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 1024 Basic and Digest Access Authentication", RFC 2617, June 1999. 1026 [22] Kent, S. and R. Atkinson, "Security Architecture for the 1027 Internet Protocol", RFC 2401, November 1998. 1029 [23] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1030 2246, January 1999. 1032 [24] Newman, C. and J. G. Myers, "ACAP -- Application Configuration 1033 Access Protocol", RFC 2244, November 1997. 1035 [25] Myers, J. and M. Rose, "Post Office Protocol - Version 3", RFC 1036 1939, STD 53, May 1996. 1038 [26] Braden, B., Clark, D.D., Crowcroft, J., Davie, B., Deering, 1039 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 1040 Partridge, C., Peterson, L., Ramakrishnan, K.K., Shenker, S., 1041 Wroclawski, J. and L. Zhang, "Recommendations on Queue 1042 Management and Congestion Avoidance in the Internet", RFC 1043 2309, April 1998. 1045 [27] Touch, J., "TCP Control Block Interdependence", RFC 2140, 1046 April 1997. 1048 [28] Postel, J. and J.K. Reynolds, "Telnet Protocol Specification", 1049 RFC 854, May 1983. 1051 [29] World Wide Web Consortium, "Extensible Markup Language (XML) 1052 1.0", W3C XML, February 1998, 1053 . 1055 [30] Case, J.D., Fedor, M., Schoffstall, M.L. and C. Davin, "Simple 1056 Network Management Protocol (SNMP)", RFC 1157, STD 15, May 1057 1990. 1059 [31] World Wide Web Consortium, "SMUX Protocol Specification", 1060 Working Draft, July 1998, 1061 . 1063 [32] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform 1064 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1065 1998. 1067 [33] Waitzman, D., "IP over Avian Carriers with Quality of 1068 Service", RFC 2549, April 1999. 1070 [34] Rose, M.T., "The Blocks Simple Exchange Profile", 1071 draft-mrose-blocks-exchange-01 (work in progress), April 2000. 1073 [35] Rose, M.T., "The Blocks eXtensible eXchange Protocol 1074 Framework", draft-mrose-bxxp-framework-00 (work in progress), 1075 June 2000. 1077 [36] Rose, M.T., "Mapping the BXXP Framework onto TCP", 1078 draft-mrose-bxxp-tcpmapping-00 (work in progress), June 2000. 1080 [37] Postel, J., "User Datagram Protocol", RFC 768, STD 6, Aug 1980. 1082 [38] Stewart, R.R., Xie, Q., Morneault, K., Sharp, C., 1083 Schwarzbauer, H.J., Taylor, T., Rytina, I., Kalla, M., Zhang, 1084 L. and V. Paxson, "Stream Control Transmission Control 1085 Protocol", draft-ietf-sigtran-sctp-10 (work in progress), 1086 April 2000. 1088 [39] mailto:ddc@lcs.mit.edu 1090 [40] http://mappa.mundi.net/cartography/Wheel/ 1092 Author's Address 1094 Marshall T. Rose 1095 Invisible Worlds, Inc. 1096 1179 North McDowell Boulevard 1097 Petaluma, CA 94954-6559 1098 US 1100 Phone: +1 707 789 3700 1101 EMail: mrose@invisible.net 1102 URI: http://invisible.net/ 1104 Full Copyright Statement 1106 Copyright (C) The Internet Society (2000). All Rights Reserved. 1108 This document and translations of it may be copied and furnished to 1109 others, and derivative works that comment on or otherwise explain it 1110 or assist in its implementation may be prepared, copied, published 1111 and distributed, in whole or in part, without restriction of any 1112 kind, provided that the above copyright notice and this paragraph 1113 are included on all such copies and derivative works. However, this 1114 document itself may not be modified in any way, such as by removing 1115 the copyright notice or references to the Internet Society or other 1116 Internet organizations, except as needed for the purpose of 1117 developing Internet standards in which case the procedures for 1118 copyrights defined in the Internet Standards process must be 1119 followed, or as required to translate it into languages other than 1120 English. 1122 The limited permissions granted above are perpetual and will not be 1123 revoked by the Internet Society or its successors or assigns. 1125 This document and the information contained herein is provided on an 1126 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1127 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1128 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1129 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1130 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1132 Invisible Worlds expressly disclaims any and all warranties 1133 regarding this contribution including any warranty that (a) this 1134 contribution does not violate the rights of others, (b) the owners, 1135 if any, of other rights in this contribution have been informed of 1136 the rights and permissions granted to IETF herein, and (c) any 1137 required authorizations from such owners have been obtained. This 1138 document and the information contained herein is provided on an "AS 1139 IS" basis and INVISIBLE WORLDS DISCLAIMS ALL WARRANTIES, EXPRESS OR 1140 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1141 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1142 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1144 IN NO EVENT WILL INVISIBLE WORLDS BE LIABLE TO ANY OTHER PARTY 1145 INCLUDING THE IETF AND ITS MEMBERS FOR THE COST OF PROCURING 1146 SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF 1147 DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES 1148 WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY 1149 WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, 1150 WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF 1151 SUCH DAMAGES. 1153 Acknowledgement 1155 Funding for the RFC editor function is currently provided by the 1156 Internet Society.