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