idnits 2.17.1 draft-mrose-beep-design-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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 206 has weird spacing: '...f which fit w...' == Line 513 has weird spacing: '...2-style bina...' == Line 517 has weird spacing: '...llelism pipel...' == Line 520 has weird spacing: '...er/pass user/...' == Line 690 has weird spacing: '...llelism 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 (November 13, 2000) is 8555 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 955 looks like a reference -- Missing reference section? '2' on line 958 looks like a reference -- Missing reference section? '3' on line 962 looks like a reference -- Missing reference section? '4' on line 965 looks like a reference -- Missing reference section? '5' on line 968 looks like a reference -- Missing reference section? '6' on line 972 looks like a reference -- Missing reference section? '7' on line 976 looks like a reference -- Missing reference section? '41' on line 1092 looks like a reference -- Missing reference section? '8' on line 980 looks like a reference -- Missing reference section? '9' on line 983 looks like a reference -- Missing reference section? '10' on line 986 looks like a reference -- Missing reference section? '11' on line 989 looks like a reference -- Missing reference section? '12' on line 992 looks like a reference -- Missing reference section? '13' on line 995 looks like a reference -- Missing reference section? '14' on line 998 looks like a reference -- Missing reference section? '15' on line 1001 looks like a reference -- Missing reference section? '42' on line 1094 looks like a reference -- Missing reference section? '16' on line 1004 looks like a reference -- Missing reference section? '17' on line 1007 looks like a reference -- Missing reference section? '18' on line 1010 looks like a reference -- Missing reference section? '19' on line 1013 looks like a reference -- Missing reference section? '20' on line 1016 looks like a reference -- Missing reference section? '21' on line 1019 looks like a reference -- Missing reference section? '22' on line 1024 looks like a reference -- Missing reference section? '23' on line 1027 looks like a reference -- Missing reference section? '24' on line 1031 looks like a reference -- Missing reference section? '25' on line 1034 looks like a reference -- Missing reference section? '26' on line 1037 looks like a reference -- Missing reference section? '27' on line 1040 looks like a reference -- Missing reference section? '28' on line 1043 looks like a reference -- Missing reference section? '29' on line 1050 looks like a reference -- Missing reference section? '30' on line 1053 looks like a reference -- Missing reference section? '31' on line 1056 looks like a reference -- Missing reference section? '32' on line 1060 looks like a reference -- Missing reference section? '33' on line 1064 looks like a reference -- Missing reference section? '34' on line 1068 looks like a reference -- Missing reference section? '35' on line 1072 looks like a reference -- Missing reference section? '37' on line 1078 looks like a reference -- Missing reference section? '38' on line 1082 looks like a reference -- Missing reference section? '39' on line 1085 looks like a reference -- Missing reference section? '43' on line 1096 looks like a reference -- Missing reference section? '36' on line 1075 looks like a reference -- Missing reference section? '40' on line 1088 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 45 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: May 14, 2001 November 13, 2000 6 On the Design of Application Protocols 7 draft-mrose-beep-design-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on May 14, 2001. 32 Copyright Notice 34 Copyright (C) The Internet Society (2000). All Rights Reserved. 36 Abstract 38 This memo describes the design principles for the Blocks eXtensible 39 eXchange Protocol (BXXP). BXXP is a generic application protocol 40 framework for connection-oriented, asynchronous interactions. The 41 framework permits simultaneous and independent exchanges within the 42 context of a single application user-identity, supporting both 43 textual and binary messages. 45 Table of Contents 47 1. A Problem 19 Years in the Making . . . . . . . . . . . . . . . 3 48 2. You can Solve Any Problem... . . . . . . . . . . . . . . . . . 6 49 3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . . . 8 50 3.1 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 51 3.2 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 52 3.3 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 9 53 3.4 Parallelism . . . . . . . . . . . . . . . . . . . . . . . . . 10 54 3.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 11 55 3.6 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 56 3.7 Let's Recap . . . . . . . . . . . . . . . . . . . . . . . . . 13 57 4. Protocol Properties . . . . . . . . . . . . . . . . . . . . . 14 58 4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 14 59 4.2 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . 15 60 4.3 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . 15 61 4.4 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . 15 62 4.5 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 16 63 5. The BXXP Framework . . . . . . . . . . . . . . . . . . . . . . 17 64 5.1 Framing and Encoding . . . . . . . . . . . . . . . . . . . . . 17 65 5.2 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 19 66 5.3 Parallelism . . . . . . . . . . . . . . . . . . . . . . . . . 19 67 5.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 21 68 5.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 69 5.6 Things We Left Out . . . . . . . . . . . . . . . . . . . . . . 22 70 5.7 From Framework to Protocol . . . . . . . . . . . . . . . . . . 22 71 6. BXXP is now BEEP . . . . . . . . . . . . . . . . . . . . . . . 23 72 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27 74 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 28 76 1. A Problem 19 Years in the Making 78 SMTP[1] is close to being the perfect application protocol: it 79 solves a large, important problem in a minimalist way. It's simple 80 enough for an entry-level implementation to fit on one or two 81 screens of code, and flexible enough to form the basis of very 82 powerful product offerings in a robust and competitive market. 83 Modulo a few oddities (e.g., SAML), the design is well conceived and 84 the resulting specification is well-written and largely 85 self-contained. There is very little about good application protocol 86 design that you can't learn by reading the SMTP specification. 88 Unfortunately, there's one little problem: SMTP was originally 89 published in 1981 and since that time, a lot of application 90 protocols have been designed for the Internet, but there hasn't been 91 a lot of reuse going on. You might expect this if the application 92 protocols were all radically different, but this isn't the case: 93 most are surprisingly similar in their functional behavior, even 94 though the actual details vary considerably. 96 In late 1998, as Carl Malamud and I were sitting down to review the 97 Blocks architecture[2], we realized that we needed to have a 98 protocol for exchanging Blocks. The conventional wisdom is that when 99 you need an application protocol, there are four ways to proceed: 101 1. find an existing exchange protocol that (more or less) does what 102 you want; 104 2. define an exchange model on top of the world-wide web 105 infrastructure that (more or less) does what you want; 107 3. define an exchange model on top of the electronic mail 108 infrastructure that (more or less) does what you want; or, 110 4. define a new protocol from scratch that does exactly what you 111 want. 113 An engineer can make reasoned arguments about the merits of each of 114 the these approaches. Here's the process we followed... 116 The most appealing option is to find an existing protocol and use 117 that. (In other words, we'd rather "buy" than "make".) So, we did a 118 survey of many existing application protocols and found that none of 119 them were a good match for the semantics of the protocol we needed. 121 For example, most application protocols are oriented toward 122 client/server behavior, and emphasize the client pulling data from 123 the server; in contrast with Blocks, a client usually pulls data 124 from the server, but it also may request the server to 125 asynchronously push (new) data to it. Clearly, we could mutate a 126 protocol such as FTP[3] or SMTP into what we wanted, but by the time 127 we did all that, the base protocol and our protocol would have more 128 differences than similarities. In other words, the cost of modifying 129 an off-the-shelf implementation becomes comparable with starting 130 from scratch. 132 Another approach is to use HTTP[4] as the exchange protocol and 133 define the rules for data exchange over that. For example, IPP[5] 134 (the Internet Printing Protocol) uses this approach. The basic idea 135 is that HTTP defines the rules for exchanging data and then you 136 define the data's syntax and semantics. Because you inherit the 137 entire HTTP infrastructure (e.g., HTTP's authentication mechanisms, 138 caching proxies, and so on), there's less for you to have to invent 139 (and code!). Or, conversely, you might view the HTTP infrastructure 140 as too helpful. As an added bonus, if you decide that your protocol 141 runs over port 80, you may be able to sneak your traffic past older 142 firewalls, at the cost of port 80 saturation. 144 HTTP has many strengths: it's ubiquitous, it's familiar, and there 145 are a lot of tools available for developing HTTP-based systems. 146 Another good thing about HTTP is that it uses MIME[6] for encoding 147 data. 149 Unfortunately for us, even with HTTP 1.1[7], there still wasn't a 150 good fit. As a consequence of the highly-desirable goal of 151 maintaining compatibility with the original HTTP, HTTP's framing 152 mechanism isn't flexible enough to support server-side asynchronous 153 behavior and its authentication model isn't similar to other 154 Internet applications. 156 Mapping IPP onto HTTP 1.1 illustrates the latter issue. For example, 157 the IPP server is supposed to signal its client when a job 158 completes. Since the HTTP client must originate all requests and 159 since the decision to close a persistent connection in HTTP is 160 unilateral, the best that the IPP specification can do is specify 161 this functionality in a non-deterministic fashion. 163 Further, the IPP mapping onto HTTP shows that even subtle shifts in 164 behavior have unintended consequences. For example, requests in IPP 165 are typically much larger than those seen by many HTTP server 166 implementations -- resulting in oddities in many HTTP servers (e.g., 167 requests are sometimes silently truncated). The lesson is that 168 HTTP's framing mechanism is very rigid with respect to its view of 169 the request/response model. 171 Lastly, given our belief that the port field of the TCP header isn't 172 a constant 80, we were immune to the seductive allure of wanting to 173 sneak our traffic past unwary site administrators. 175 The third choice, layering the protocol on top of e-mail, was 176 attractive. Unfortunately, the nature of our application includes a 177 lot of interactivity with relatively small response times. So, this 178 left us the final alternative: defining a protocol from scratch. 180 To begin, we figured that our requirements, while a little more 181 stringent than most, could fit inside a framework suitable for a 182 large number of future application protocols. The trick is to avoid 183 the kitchen-sink approach. (Dave Clark[41] has a saying: "One of the 184 roles of architecture is to tell you what you can't do.") 186 2. You can Solve Any Problem... 188 ...if you're willing to make the problem small enough. 190 Our most important step is to limit the problem to application 191 protocols that exhibit certain features: 193 o they are connection-oriented; 195 o they use requests and responses to exchange messages; and, 197 o they allow for asynchronous message exchange. 199 Let's look at each, in turn. 201 First, we're only going to consider connection-oriented application 202 protocols (e.g., those that work on top of TCP[8]). Another branch 203 in the taxonomy, connectionless, consists of those that don't want 204 the delay or overhead of establishing and maintaining a reliable 205 stream. For example, most DNS[9] traffic is characterized by a 206 single request and response, both of which fit within a single IP 207 datagram. In this case, it makes sense to implement a basic 208 reliability service above the transport layer in the application 209 protocol itself. 211 Second, we're only going to consider message-oriented application 212 protocols. A "message" -- in our lexicon -- is simply structured 213 data exchanged between loosely-coupled systems. Another branch in 214 the taxonomy, tightly-coupled systems, uses remote procedure calls 215 as the exchange paradigm. Unlike the 216 connection-oriented/connectionless dichotomy, the issue of loosely- 217 or tightly-coupled systems is similar to a continuous spectrum. 218 Fortunately, the edges are fairly sharp. 220 For example, NFS[10] is a tightly-coupled system using RPCs. When 221 running in a properly-configured LAN, a remote disk accessible via 222 NFS is virtually indistinguishable from a local disk. To achieve 223 this, tightly-coupled systems are highly concerned with issues of 224 latency. Hence, most (but not all) tightly-coupled systems use 225 connection-less RPC mechanisms; further, most tend to be implemented 226 as operating system functions rather than user-level programs. (In 227 some environments, the tightly-coupled systems are implemented as 228 single-purpose servers, on hardware specifically optimized for that 229 one function.) 231 Finally, we're going to consider the needs of application protocols 232 that exchange messages asynchronously. The classic client/server 233 model is that the client sends a request and the server sends a 234 response. If you think of requests as "questions" and responses as 235 "answers", then the server answers only those questions that it's 236 asked and it never asks any questions of its own. We'll need to 237 support a more general model, peer-to-peer. In this model, for a 238 given transaction one peer might be the "client" and the other the 239 "server", but for the next transaction, the two peers might switch 240 roles. 242 It turns out that the client/server model is a proper subset of the 243 peer-to-peer model: it's acceptable for a particular application 244 protocol to dictate that the peer that establishes the connection 245 always acts as the client (initiates requests), and that the peer 246 that listens for incoming connections always acts as the server 247 (issuing responses to requests). 249 There are quite a few existing application domains that don't fit 250 our requirements, e.g., nameservice (via the DNS), fileservice (via 251 NFS), multicast-enabled applications such as distributed video 252 conferencing, and so on. However, there are a lot of application 253 domains that do fit these requirements, e.g., electronic mail, file 254 transfer, remote shell, and the world-wide web. So, the bet we are 255 placing in going forward is that there will continue to be reasons 256 for defining protocols that fit within our framework. 258 3. Protocol Mechanisms 260 The next step is to look at the tasks that an application protocol 261 must perform and how it goes about performing them. Although an 262 exhaustive exposition might identify a dozen (or so) areas, the ones 263 we're interested in are: 265 o framing, which tells how the beginning and ending of each message 266 is delimited; 268 o encoding, which tells how a message is represented when exchanged; 270 o reporting, which tells how errors are described; 272 o parallelism, which tells how independent exchanges are handled; 274 o authentication, which tells how the peers at each end of the 275 connection are identified and verified; and, 277 o privacy, which tells how the exchanges are protected against 278 third-party interception or modification. 280 A notable absence in this list is naming -- we'll explain why later 281 on. 283 3.1 Framing 285 There are three commonly used approaches to delimiting messages: 286 octet-stuffing, octet-counting, and connection-blasting. 288 An example of a protocol that uses octet-stuffing is SMTP. Commands 289 in SMTP are line-oriented (each command ends in a CR-LF pair). When 290 an SMTP peer sends a message, it first transmits the "DATA" command, 291 then it transmits the message, then it transmits a "." (dot) 292 followed by a CR-LF. If the message contains any lines that begin 293 with a dot, the sending SMTP peer sends two dots; similarly, when 294 the other SMTP peer receives a line that begins with a dot, it 295 discards the dot, and, if the line is empty, then it knows it's 296 received the entire message. Octet-stuffing has the property that 297 you don't need the entire message in front of you before you start 298 sending it. Unfortunately, it's slow because both the sender and 299 receiver must scan each line of the message to see if they need to 300 transform it. 302 An example of a protocol that uses octet-counting is HTTP. Commands 303 in HTTP consist of a request line followed by headers and a body. 304 The headers contain an octet count indicating how large the body is. 305 The properties of octet-counting are the inverse of octet-stuffing: 306 before you can start sending a message you need to know the length 307 of the whole message, but you don't need to look at the content of 308 the message once you start sending or receiving. 310 An example of a protocol that uses connection-blasting is FTP. 311 Commands in FTP are line-oriented, and when it's time to exchange a 312 message, a new TCP connection is established to transmit the 313 message. Both octet-counting and connection-blasting have the 314 property that the messages can be arbitrary binary data; however, 315 the drawback of the connection-blasting approach is that the peers 316 need to communicate IP addresses and TCP port numbers, which may be 317 "transparently" altered by NATS[11] and network bugs. In addition, 318 if the messages being exchanged are small (say less than 32k), then 319 the overhead of establishing a connection for each message 320 contributes significant latency during data exchange. 322 3.2 Encoding 324 There are many schemes used for encoding data (and many more 325 encoding schemes have been proposed than are actually in use). 326 Fortunately, only a few are burning brightly on the radar. 328 The messages exchanged using SMTP are encoded using the 329 822-style[12]. The 822-style divides a message into textual headers 330 and an unstructured body. Each header consists of a name and a value 331 and is terminated with a CR-LF pair. An additional CR-LF separates 332 the headers from the body. 334 It is this structure that HTTP uses to indicate the length of the 335 body for framing purposes. More formally, HTTP uses MIME, an 336 application of the 822-style to encode both the data itself (the 337 body) and information about the data (the headers). That is, 338 although HTTP is commonly viewed as a retrieval mechanism for 339 HTML[13], it is really a retrieval mechanism for objects encoded 340 using MIME, most of which are either HTML pages or referenced 341 objects such as GIFs. 343 3.3 Reporting 345 An application protocol needs a mechanism for conveying error 346 information between peers. The first formal method for doing this 347 was defined by SMTP's "theory of reply codes". The basic idea is 348 that an error is identified by a three-digit string, with each 349 position having a different significance: 351 the first digit: indicating success or failure, either permanent or 352 transient; 354 the second digit: indicating the part of the system reporting the 355 situation (e.g., the syntax analyzer); and, 357 the third digit: identifying the actual situation. 359 Operational experience with SMTP suggests that the range of error 360 conditions is larger than can be comfortably encoded using a 361 three-digit string (i.e., you can report on only 10 different things 362 going wrong for any given part of the system). So, [14] provides a 363 convenient mechanism for extending the number of values that can 364 occur in the second and third positions. 366 Virtually all of the application protocols we've discussed thus far 367 use the three-digit reply codes, although there is less coordination 368 between the designers of different application protocols than most 369 would care to admit. (A notable exception to the theory of reply 370 codes is IMAP[15] which uses error "tokens" instead of three-digit 371 codes.) 373 In addition to conveying a reply code, most application protocols 374 also send a textual diagnostic suitable for human, not machine, 375 consumption. (More accurately, the textual diagnostic is suitable 376 for people who can read a widely used variant of the English 377 language.) Since reply codes reflect both positive and negative 378 outcomes, there have been some innovative uses made for the text 379 accompanying positive responses, e.g., prayer wheels[42]. 380 Regardless, some of the more modern application protocols include a 381 language localization parameter for the diagnostic text. 383 Finally, since the introduction of reply codes in 1981, two 384 unresolved criticisms have been raised: 386 o a reply code is used both to signal the outcome of an operation 387 and a change in the application protocol's state; and, 389 o a reply code doesn't specify whether the associated textual 390 diagnostic is destined for the end-user, administrator, or 391 programmer. 393 3.4 Parallelism 395 Few application protocols today allow independent exchanges over the 396 same connection. In fact, the more widely implemented approach is to 397 allow pipelining, e.g., command pipelining[16] in SMTP or persistent 398 connections in HTTP 1.1. Pipelining allows a client to make multiple 399 requests of a server, but requires the requests to be processed 400 serially. (Note that a protocol needs to explicitly provide support 401 for pipelining, since, without explicit guidance, many implementors 402 produce systems that don't handle pipelining properly; typically, an 403 error in a request causes subsequent requests in the pipeline to be 404 discarded). 406 Pipelining is a powerful method for reducing network latency. For 407 example, without persistent connections, HTTP's framing mechanism is 408 really closer to connection-blasting than octet-counting, and it 409 enjoys the same latency and efficiency problems. 411 In addition to reducing network latency (the pipelining effect), 412 parallelism also reduces server latency by allowing multiple 413 requests to be processed by multi-threaded implementations. Note 414 that if you allow any form of asynchronous exchange, then support 415 for parallelism is also required, because exchanges aren't 416 necessarily occurring under the synchronous direction of a single 417 peer. 419 Unfortunately, when you allow parallelism, you also need a flow 420 control mechanism to avoid starvation and deadlock. Otherwise, a 421 single set of exchanges can monopolize the bandwidth provided by the 422 transport layer. Further, if a peer is resource-starved, then it may 423 not have enough buffers to receive a message and deadlock results. 425 Flow control is typically implemented at the transport layer. For 426 example, TCP uses sequence numbers and a sliding window: each 427 receiver manages a sliding window that indicates the number of data 428 octets that may be transmitted before receiving further permission. 429 However, it's now time for the second shoe to drop: segmentation. If 430 you do flow control then you also need a segmentation mechanism to 431 fragment messages into smaller pieces before sending and then 432 re-assemble them as they're received. 434 Both flow control and segmentation have an impact on how the 435 protocol does framing. Before we defined framing as "how to tell the 436 beginning and end of each message" -- in addition, we need to be 437 able to identify independent messages, send messages only when flow 438 control allows us to, and segment them if they're larger than the 439 available window (or too large for comfort). 441 Segmentation impacts framing in another way -- it relaxes the 442 octet-counting requirement that you need to know the length of the 443 whole message before sending it. With segmentation, you can start 444 sending segments before the whole message is available. In HTTP 1.1 445 you can "chunk" (segment) data to get this advantage. 447 3.5 Authentication 449 Perhaps for historical (or hysterical) reasons, most application 450 protocols don't do authentication. That is, they don't authenticate 451 the identity of the peers on the connection or the authenticity of 452 the messages being exchanged. Or, if authentication is done, it is 453 domain-specific for each protocol. For example, FTP and HTTP use 454 entirely different models and mechanisms for authenticating the 455 initiator of a connection. (Independent of mainstream HTTP, there is 456 a little-used variant[17] that authenticates the messages it 457 exchanges.) 459 A large part of the problem is that different security mechanisms 460 optimize for strength, scalability, or ease of deployment. So, a few 461 years ago, SASL[18] (the Simple Authentication and Security Layer) 462 was developed to provide a framework for authenticating protocol 463 peers. SASL let's you describe how an authentication mechanism 464 works, e.g., an OTP[19] (One-Time Password) exchange. It's then up 465 to each protocol designer to specify how SASL exchanges are 466 generically conveyed by the protocol. For example, [20] explains how 467 SASL works with SMTP. 469 A notable exception to the SASL bandwagon is HTTP, which defines its 470 own authentication mechanisms[21]. There is little reason why SASL 471 couldn't be introduced to HTTP, although to avoid certain 472 race-conditions, the persistent connection mechanism of HTTP 1.1 473 must be used. 475 SASL has an interesting feature in that in addition to explicit 476 protocol exchanges to authenticate identity, it can also use 477 implicit information provided from the layer below. For example, if 478 the connection is running over IPsec[22], then the credentials of 479 each peer are known and verified when the TCP connection is 480 established. 482 Finally, as its name implies, SASL can do more than authentication 483 -- depending on which SASL mechanism is in use, message integity or 484 privacy services may also be provided. 486 3.6 Privacy 488 HTTP is the first widely used protocol to make use of a transport 489 security protocol to encrypt the data sent on the connection. The 490 current version of this mechanism, TLS[23], is available to all 491 application protocols, e.g., SMTP and ACAP[24] (the Application 492 Configuration Access Protocol). 494 The key difference between the original mechanism and TLS, is one of 495 provisioning not technology. In the original approach to 496 provisioning, a world-wide web server listens on two ports (one for 497 plaintext traffic and the other for secured traffic); in contrast, 498 by today's conventions, a server implementing an application 499 protocol that is specified as TLS-enabled (e.g., [25] and [26]) 500 listens on a single port for plaintext traffic, and, once a 501 connection is established, the use of TLS on that connection is 502 negotiable. 504 3.7 Let's Recap 506 Let's briefly compare the properties of the three main 507 connection-oriented application protocols in use today: 509 Mechanism SMTP FTP HTTP 510 ------------------- ---------- --------- ------------- 511 Framing Stuffing Blasting Counting 513 Encoding 822-style binary MIME 515 Reporting 3-digit 3-digit 3-digit 517 Parallelism pipelining none persistent 518 and chunking 520 Authentication SASL user/pass user/pass 522 Privacy TLS none TLS (nee SSL) 524 Note that the username/password mechanisms used by FTP and HTTP are 525 entirely different with one exception: both can be termed a 526 "username/password" mechanism. 528 These three choices are broadly representative: as more protocols 529 are considered, the patterns are reinforced. For example, POP[27] 530 uses octet-stuffing, but IMAP uses octet-counting, and so on. 532 4. Protocol Properties 534 When we design an application protocol, there are a few properties 535 that we should keep an eye on. 537 4.1 Scalability 539 A well-designed protocol is scalable. 541 Because few application protocols support parallelism, a common 542 trick is for a program to open multiple simultaneous connections to 543 a single destination. The theory is that this reduces latency and 544 increases throughput. The reality is that both the transport layer 545 and the server view each connection as an independent instance of 546 the application protocol, and this causes problems. 548 In terms of the transport layer, TCP uses adaptive algorithms to 549 efficiently transmit data as networks conditions change. But what 550 TCP learns is limited to each connection. So, if you have multiple 551 TCP connections, you have to go through the same learning process 552 multiple times -- even if you're going to the same host. Not only 553 does this introduce unnecessary traffic spikes into the network, 554 because TCP uses a slow-start algorithm when establishing a 555 connection, the program still sees additional latency. To deal with 556 the fact that a lack of parallelism in application protocols causes 557 implementors to make sloppy use of the transport layer, network 558 protocols are now provisioned with increasing sophistication, e.g., 559 RED[28]. Further, suggestions are also being considered for 560 modification of TCP implementations to reduce concurrent learning, 561 e.g., [29]. 563 In terms of the server, each incoming connection must be dispatched 564 and (probably) authenticated against the same resources. 565 Consequently, server overhead increases based on the number of 566 connections established, rather than the number of remote users. The 567 same issues of fairness arise: it's much harder for servers to 568 allocate resources on a per-user basis, when a user can cause an 569 arbitrary number of connections to pound on the server. 571 Another important aspect of scalability to consider is the relative 572 numbers of clients and servers. (This is true even in the 573 peer-to-peer model, where a peer can act both in the client and 574 server role.) Typically, there are many more client peers than 575 server peers. In this case, functional requirements should be 576 shifted from the servers onto the clients. The reason is that a 577 server is likely to be interacting with multiple clients and this 578 functional shift makes it easier to scale. 580 4.2 Efficiency 582 A well-designed protocol is efficient. 584 For example, although a compelling argument can be made than 585 octet-stuffing leads to more elegant implementations than 586 octet-counting, experience shows that octet-counting consumes far 587 fewer cycles. 589 Regrettably, we sometimes have to compromise efficiency in order to 590 satisfy other properties. For example, 822 (and MIME) use textual 591 headers. We could certainly define a more efficient representation 592 for the headers if we were willing to limit the header names and 593 values that could be used. In this case, extensibility is viewed as 594 more important than efficiency. Of course, if we were designing a 595 network protocol instead of an application protocol, then we'd make 596 the trade-offs using a razor with a different edge. 598 4.3 Simplicity 600 A well-designed protocol is simple. 602 Here's a good rule of thumb: a poorly-designed application protocol 603 is one in which it is equally as "challenging" to do something basic 604 as it is to do something complex. Easy things should be easy to do 605 and hard things should be harder to do. The reason is simple: the 606 pain should be proportional to the gain. 608 Another rule of thumb is that if an application protocol has two 609 ways of doing the exact same thing, then there's a problem somewhere 610 in the architecture underlying the design of the application 611 protocol. 613 Hopefully, simple doesn't mean simple-minded: something that's 614 well-designed accommodates everything in the problem domain, even 615 the troublesome things at the edges. What makes the design simple is 616 that it does this in a consistent fashion. Typically, this leads to 617 an elegant design. 619 4.4 Robustness 621 A well-designed protocol is robust. 623 Robustness and efficiency are often at odds. For example, although 624 defaults are useful to reduce packet sizes and processing time, they 625 tend to encourage implementation errors. 627 Counter-intuitively, Postel's robustness principle ("be conservative 628 in what you send, liberal in what you accept") often leads to 629 deployment problems. Why? When a new implementation is initially 630 fielded, it is likely that it will encounter only a subset of 631 existing implementations. If those implementations follow the 632 robustness principle, then errors in the new implementation will 633 likely go undetected. The new implementation then sees some, but not 634 widespread deployment. This process repeats for several new 635 implementations. Eventually, the not-quite-correct implementations 636 run into other implementations that are less liberal than the 637 initial set of implementations. The reader should be able to figure 638 out what happens next. 640 Accordingly, explicit consistency checks in a protocol are very 641 useful, even if they impose implementation overhead. 643 4.5 Extensibility 645 A well-designed protocol is extensible. 647 As clever as application protocol designers are, there are likely to 648 be unforeseen problems that the application protocol will be asked 649 to solve. So, it's important to provide the hooks that can be used 650 to add functionality or customize behavior. This means that the 651 protocol is evolutionary, and there must be a way for 652 implementations reflecting different steps in the evolutionary path 653 to negotiate which extensions will be used. 655 But, it's important to avoid falling into the extensibility trap: 656 the hooks provided should not be targeted at half-baked future 657 requirements. Above all, the hooks should be simple. 659 Of course good design goes a long way towards minimizing the need 660 for extensibility. For example, although SMTP initially didn't have 661 an extension framework, it was only after ten years of experience 662 that its excellent design was altered. In contrast, a 663 poorly-designed protocol such as Telnet[30] can't function without 664 being built around the notion of extensions. 666 5. The BXXP Framework 668 Finally, we get to the money shot: here's what we did. 670 We defined an application protocol framework called BXXP (the Blocks 671 eXtensible eXchange Protocol). The reason it's a "framework" instead 672 of an application protocol is that we provide all the mechanisms 673 discussed earlier without actually specifying the kind of messages 674 that get exchanged. So, when someone else needs an application 675 protocol that requires connection-oriented, asynchronous 676 interactions, they can start with BXXP. It's then their 677 responsibility to define the last 10% of the application protocol, 678 the part that does, as we say, "the useful work". 680 So, what does BXXP look like? 682 Mechanism BXXP 683 ------------------- ---------------------------------------- 684 Framing Counting, with a trailer 686 Encoding MIME, defaulting to text/xml 688 Reporting 3-digit and localized textual diagnostic 690 Parallelism independent channels 692 Authentication SASL 694 Privacy SASL or TLS 696 5.1 Framing and Encoding 698 Framing in BXXP looks a lot like SMTP or HTTP: there's a command 699 line that identifies the beginning of the frame, then there's a MIME 700 object (headers and body). Unlike SMTP, BXXP uses octet-counting, 701 but unlike HTTP, the command line is where you find the size of the 702 payload. Finally, there's a trailer after the MIME object to aid in 703 detecting framing errors. 705 Actually, the command line for BXXP has a lot of information, it 706 tells you: 708 o what kind of message is in this frame; 710 o whether there's more to the message than just what's in this 711 frame (a continuation flag); 713 o how to distinguish the message contained in this frame from other 714 messages (a message number); 716 o where the payload occurs in the sliding window (a sequence 717 number) along with how many octets are in the payload of this 718 frame; and, 720 o which part of the application should get the message (a channel 721 number). 723 (The command line is textual and ends in a CR-LF pair, and the 724 arguments are separated by a space.) 726 Since you need to know all this stuff to process a frame, we put it 727 all in one easy to parse location. You could probably devise a more 728 efficient encoding, but the command line is a very small part of the 729 frame, so you wouldn't get much bounce from optimizing it. Further, 730 because framing is at the heart of BXXP, the frame format has 731 several consistency checks that catch the majority of programming 732 errors. (The combination of a sequence number, an octet count, and a 733 trailer allows for very robust error detection.) 735 Another trick is in the headers: because the command line contains 736 all the framing information, the headers may contain minimal MIME 737 information (such as Content-Type). Usually, however, the headers 738 are empty. That's because the BXXP default payload is XML[31]. 739 (Actually, a "Content-Type: text/xml" with binary transfer encoding). 741 We chose XML as the default because it provides a simple mechanism 742 for nested, textual representations. (Alas, the 822-style encoding 743 doesn't easily support nesting.) By design, XML's nature isn't 744 optimized for compact representations. That's okay because we're 745 focusing on loosely-coupled systems and besides there are efficient 746 XML parsers available. Further, there's a fair amount of anecdotal 747 experience -- and we'll stress the word "anecdotal" -- that if you 748 have any kind of compression (either at the link-layer or during 749 encryption), then XML encodings squeeze down nicely. 751 Even so, use of XML is probably the most controversial part of BXXP. 752 After all, there are more efficient representations around. We 753 agree, but the real issue isn't efficiency, it's ease of use: there 754 are a lot of people who grok the XML thing and there are a lot of 755 XML tools out there. The pain of recreating this social 756 infrastructure far outweighs any benefits of devising a new 757 representation. So, if the "make" option is too expensive, is there 758 something else we can "buy" besides XML? Well, there's ASN.1/BER 759 (just kidding). 761 In the early days of the SNMP[32], which does use ASN.1, the same 762 issues arose. In the end, the working group agreed that the use of 763 ASN.1 for SNMP was axiomatic, but not because anyone thought that 764 ASN.1 was the most efficient, or the easiest to explain, or even 765 well liked. ASN.1 was given axiomatic status because the working 766 group decided it was not going to spend the next three years 767 explaining an alternative encoding scheme to the developer community. 769 So -- and we apologize for appealing to dogma -- use of XML as the 770 favored encoding scheme in BXXP is axiomatic. 772 5.2 Reporting 774 We use 3-digit error codes, with a localized textual diagnostic. 775 (Each peer specifies a preferred ordering of languages.) 777 In addition, the reply to a message is flagged as either positive or 778 negative. This makes it easy to signal success or failure and allow 779 the receiving peer some freedom in the amount of parsing it wants to 780 do on failure. 782 5.3 Parallelism 784 Despite the lessons of SMTP and HTTP, there isn't a lot of field 785 experience to rely on when designing the parallelism features of 786 BXXP. (Actually, there were several efforts in 1998 related to 787 application layer framing, e.g., [33], but none appear to have 788 achieved orbit.) 790 So, here's what we did: frames are exchanged in the context of a 791 "channel". Each channel has an associated "profile" that defines the 792 syntax and semantics of the messages exchanged over a channel. 794 Channels provide both an extensibility mechanism for BXXP and the 795 basis for parallelism. Remember the last parameter in the command 796 line of a BXXP frame? The "part of the application" that gets the 797 message is identified by a channel number. 799 A profile is defined according to a "Profile Registration" template. 800 The template defines how the profile is identified (using a 801 URI[34]), what kind of messages get exchanged, along with the syntax 802 and semantics of those messages. When you create a channel, you 803 identify a profile and maybe piggyback your first message. If the 804 channel is successfully created, you get back a positive response; 805 otherwise, you get back a negative response explaining why. 807 Perhaps the easiest way to see how channels provide an extensibility 808 mechanism is to consider what happens when a session is established. 809 Each BXXP peer immediately sends a greeting on channel zero 810 identifying the profiles that each support. (Channel 0 is used for 811 channel management -- it's automatically created when a session is 812 opened.) If you want transport security, the very first thing you do 813 is to create a channel that negotiates transport security, and, once 814 the channel is created, you tell it to do its thing. Next, if you 815 want to authenticate, you create a channel that performs user 816 authentication, and, once the channel is created, you tell it to get 817 busy. At this point, you create one or more channels for data 818 exchange. This process is called "tuning"; once you've tuned the 819 session, you start using the data exchange channels to do "the 820 useful work". 822 The first channel that's successfully started has a trick associated 823 with it: when you ask to start the channel, you're allowed to 824 specify a "service name" that goes with it. This allows a server 825 with multiple configurations to select one based on the client's 826 suggestion. (A useful analogy is HTTP 1.1's "Host:" header.) If the 827 server accepts the "service name", then this configuration is used 828 for the rest of the session. 830 To allow parallelism, BXXP allows you to use multiple channels 831 simultaneously. Each channel processes messages serially, but there 832 are no constraints on the processing order for different channels. 833 So, in a multi-threaded implementation, each channel maps to its own 834 thread. 836 This is the most general case, of course. For one reason or another, 837 an implementor may not be able to support this. So, BXXP allows for 838 both positive and negative replies when a message is sent. So, if 839 you want the classic client/server model, the client program should 840 simply reject any new message sent by the server. This effectively 841 throttles any asynchronous messages from the server. 843 Of course, we now need to provide mechanisms for segmentation and 844 flow control. For the former, we just put a "continuation" or "more 845 to come" flag in the command line for the frame. For the latter, we 846 introduced the notion of a "transport mapping". 848 What this means is that BXXP doesn't directly define how it sits of 849 top of TCP. Instead, it lists a bunch of requirements for how a 850 transport service needs to support a BXXP session. Then, in a 851 separate document, we defined how you can use TCP to meet these 852 requirements. 854 This second document pretty much says "use TCP directly", except 855 that it introduces a flow control mechanism for multiplexing 856 channels over a single TCP connection. The mechanism we use is the 857 same one used by TCP (sequence numbers and a sliding window). It's 858 proven, and can be trivially implemented by a minimal implementation 859 of BXXP. 861 The introduction of flow control is a burden from an implementation 862 perspective -- although TCP's mechanism is conceptually simple, an 863 implementor must take great care. For example, issues such as 864 priorities, queue management, and the like should be addressed. 865 Regardless, we feel that the benefits of allowing parallelism for 866 intra-application streams is worth it. (Besides, our belief is that 867 few application implementors will actually code the BXXP framework 868 directly -- rather, we expect them to use third-party packages that 869 implement BXXP.) 871 5.4 Authentication 873 We use SASL. If you successfully authenticate using a channel, then 874 there is a single user identity for each peer on that session (i.e., 875 authentication is per-session, not per-channel). This design 876 decision mandates that each session correspond to a single user 877 regardless of how many channels are open on that session. One reason 878 why this is important is that it allows service provisioning, such 879 as quality of service (e.g., as in [35]) to be done on a per-user 880 granularity. 882 5.5 Privacy 884 We use SASL and TLS. If you successfully complete a transport 885 security negotiation using a channel, then all traffic on that 886 session is secured (i.e., confidentiality is per-session, not 887 per-channel, just like authentication). 889 We defined a BXXP profile that's used to start the TLS engine. 891 5.6 Things We Left Out 893 We purposefully excluded two things that are common to most 894 application protocols: naming and authorization. 896 Naming was excluded from the framework because, outside of URIs, 897 there isn't a commonly accepted framework for naming things. To our 898 view, this remains a domain-specific problem for each application 899 protocol. Maybe URIs are appropriate in the context of a 900 particularly problem domain, maybe not. So, when an application 901 protocol designer defines their own profile to do "the useful work", 902 they'll have to deal with naming issues themselves. BXXP provides a 903 mechanism for identifying profiles and binding them to channels. 904 It's up to you to define the profile and use the channel. 906 Similarly, authorization was explicitly excluded from the framework. 907 Every approach to authorization we've seen uses names to identify 908 principals (i.e., targets and subjects), so if a framework doesn't 909 include naming, it can't very well include authorization. 911 Of course, application protocols do have to deal with naming and 912 authorization -- those are two of the issues addressed by the 913 applications protocol designer when defining a profile for use with 914 BXXP. 916 5.7 From Framework to Protocol 918 So, how do you go about using BXXP? 920 First, get the framework specification[37] and read it. Next, define 921 your own profile. Finally, get one of the open source SDKs (in Perl 922 or Java) and start coding. 924 The BXXP specification defines several profiles itself: a channel 925 management profile, a family of profiles for SASL, and a transport 926 security profile. In addition, there's a second specification[38] 927 that explains how a BXXP session maps onto a single TCP connection. 929 For a complete example of an application protocol defined using 930 BXXP, look at IMXP[39]. This draft exemplifies the formula: 932 application protocol = BEEP + 1 or more profiles 933 + authorization policies 934 + provisioning rules (e.g., use of SRV RRs[38]) 936 6. BXXP is now BEEP 938 We started work on BXXP in the fall of 1998. Recently, the IETF[43] 939 formed a working group on BXXP. 941 Although the working group made some enhancements to BXXP, three are 942 the most notable: 944 o The payload default is "application/octet-stream". This is 945 primarily for wire-efficiency -- if you care about 946 wire-efficiency, then you probably wouldn't be using "text/xml"... 948 o One-to-many exchanges are supported (the client sends one message 949 and the server sends back many replies). 951 o BXXP is now called BEEP (more comic possibilities). 953 References 955 [1] Postel, J., "Simple Mail Transfer Protocol", RFC 821, STD 10, 956 Aug 1982. 958 [2] Rose, M.T. and C. Malamud, "Blocks: Architectural Precepts", 959 draft-mrose-blocks-architecture-01 (work in progress), March 960 2000. 962 [3] Postel, J. and J.K. Reynolds, "File Transfer Protocol", RFC 963 959, STD 9, Oct 1985. 965 [4] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext 966 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 968 [5] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet 969 Printing Protocol/1.0: Encoding and Transport", RFC 2565, 970 April 1999. 972 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 973 Extensions (MIME) Part One: Format of Internet Message 974 Bodies", RFC 2045, November 1996. 976 [7] Fielding, R. T., Gettys, J., Mogul, J. C., Nielsen, H. F., 977 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 978 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 980 [8] Postel, J., "Transmission Control Protocol", RFC 793, STD 7, 981 Sep 1981. 983 [9] Mockapetris, P.V., "Domain names - concepts and facilities", 984 RFC 1034, STD 13, Nov 1987. 986 [10] Microsystems, Sun, "NFS: Network File System Protocol 987 specification", RFC 1094, Mar 1989. 989 [11] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 990 (NAT) Terminology and Considerations", RFC 2663, August 1999. 992 [12] Crocker, D., "Standard for the format of ARPA Internet text 993 messages", RFC 822, STD 11, Aug 1982. 995 [13] Berners-Lee, T. and D. W. Connolly, "Hypertext Markup Language 996 - 2.0", RFC 1866, November 1995. 998 [14] Freed, N., "SMTP Service Extension for Returning Enhanced 999 Error Codes", RFC 2034, October 1996. 1001 [15] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, 1002 December 1994. 1004 [16] Freed, N., "SMTP Service Extension for Command Pipelining", 1005 RFC 2197, September 1997. 1007 [17] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer 1008 Protocol", RFC 2660, August 1999. 1010 [18] Myers, J.G., "Simple Authentication and Security Layer 1011 (SASL)", RFC 2222, October 1997. 1013 [19] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, 1014 October 1998. 1016 [20] Myers, J., "SMTP Service Extension for Authentication", RFC 1017 2554, March 1999. 1019 [21] Franks, J., Hallam-Baker, P. M., Hostetler, J. L., Lawrence, 1020 S. D., Leach, P. J. , Luotonen, A. and L. Stewart, "HTTP 1021 Authentication: Basic and Digest Access Authentication", RFC 1022 2617, June 1999. 1024 [22] Kent, S. and R. Atkinson, "Security Architecture for the 1025 Internet Protocol", RFC 2401, November 1998. 1027 [23] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A. 1028 O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 1029 January 1999. 1031 [24] Newman, C. and J. Myers, "ACAP -- Application Configuration 1032 Access Protocol", RFC 2244, November 1997. 1034 [25] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1035 TLS", RFC 2487, January 1999. 1037 [26] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 1038 June 1999. 1040 [27] Myers, J. and M. Rose, "Post Office Protocol - Version 3", RFC 1041 1939, STD 53, May 1996. 1043 [28] Braden, B., Clark, D.D., Crowcroft, J., Davie, B., Deering, 1044 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 1045 Partridge, C., Peterson, L., Ramakrishnan, K.K., Shenker, S., 1046 Wroclawski, J. and L. Zhang, "Recommendations on Queue 1047 Management and Congestion Avoidance in the Internet", RFC 1048 2309, April 1998. 1050 [29] Touch, J., "TCP Control Block Interdependence", RFC 2140, 1051 April 1997. 1053 [30] Postel, J. and J.K. Reynolds, "Telnet Protocol Specification", 1054 RFC 854, May 1983. 1056 [31] World Wide Web Consortium, "Extensible Markup Language (XML) 1057 1.0", W3C XML, February 1998, 1058 . 1060 [32] Case, J.D., Fedor, M., Schoffstall, M.L. and C. Davin, "Simple 1061 Network Management Protocol (SNMP)", RFC 1157, STD 15, May 1062 1990. 1064 [33] World Wide Web Consortium, "SMUX Protocol Specification", 1065 Working Draft, July 1998, 1066 . 1068 [34] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform 1069 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1070 1998. 1072 [35] Waitzman, D., "IP over Avian Carriers with Quality of 1073 Service", RFC 2549, April 1999. 1075 [36] Rose, M.T., "The Blocks Simple Exchange Profile", 1076 draft-mrose-blocks-exchange-01 (work in progress), April 2000. 1078 [37] Rose, M.T., "The Blocks Extensible Exchange Protocol 1079 Framework", draft-ietf-beep-framework-08 (work in progress), 1080 November 2000. 1082 [38] Rose, M.T., "Mapping the BEEP Framework onto TCP", 1083 draft-ietf-beep-tcpmapping-04 (work in progress), October 2000. 1085 [39] Rose, M.T., Klyne, G. and D.H. Crocker, "The IMXP", 1086 draft-mrose-imxp-core-02 (work in progress), October 2000. 1088 [40] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1089 specifying the location of services (DNS SRV)", RFC 2782, 1090 February 2000. 1092 [41] 1094 [42] 1096 [43] 1098 Author's Address 1100 Marshall T. Rose 1101 Invisible Worlds, Inc. 1102 1179 North McDowell Boulevard 1103 Petaluma, CA 94954-6559 1104 US 1106 Phone: +1 707 789 3700 1107 EMail: mrose@invisible.net 1108 URI: http://invisible.net/ 1110 Full Copyright Statement 1112 Copyright (C) The Internet Society (2000). All Rights Reserved. 1114 This document and translations of it may be copied and furnished to 1115 others, and derivative works that comment on or otherwise explain it 1116 or assist in its implementation may be prepared, copied, published 1117 and distributed, in whole or in part, without restriction of any 1118 kind, provided that the above copyright notice and this paragraph 1119 are included on all such copies and derivative works. However, this 1120 document itself may not be modified in any way, such as by removing 1121 the copyright notice or references to the Internet Society or other 1122 Internet organizations, except as needed for the purpose of 1123 developing Internet standards in which case the procedures for 1124 copyrights defined in the Internet Standards process must be 1125 followed, or as required to translate it into languages other than 1126 English. 1128 The limited permissions granted above are perpetual and will not be 1129 revoked by the Internet Society or its successors or assigns. 1131 This document and the information contained herein is provided on an 1132 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1133 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1134 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1135 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1136 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1138 Acknowledgement 1140 Funding for the RFC editor function is currently provided by the 1141 Internet Society.