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