1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515
|
Network Working Group M. Rose
Request for Comments: 3117 Dover Beach Consulting, Inc.
Category: Informational November 2001
On the Design of Application Protocols
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This memo describes the design principles for the Blocks eXtensible
eXchange Protocol (BXXP). BXXP is a generic application protocol
framework for connection-oriented, asynchronous interactions. The
framework permits simultaneous and independent exchanges within the
context of a single application user-identity, supporting both
textual and binary messages.
Rose Informational [Page 1]
RFC 3117 On the Design of Application Protocols November 2001
Table of Contents
1. A Problem 19 Years in the Making . . . . . . . . . . . . . . . 3
2. You can Solve Any Problem... . . . . . . . . . . . . . . . . . 6
3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . . . 8
3.1 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7 Let's Recap . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Protocol Properties . . . . . . . . . . . . . . . . . . . . . 14
4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. The BXXP Framework . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Framing and Encoding . . . . . . . . . . . . . . . . . . . . . 17
5.2 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 21
5.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.6 Things We Left Out . . . . . . . . . . . . . . . . . . . . . . 21
5.7 From Framework to Protocol . . . . . . . . . . . . . . . . . . 22
6. BXXP is now BEEP . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
Rose Informational [Page 2]
RFC 3117 On the Design of Application Protocols November 2001
1. A Problem 19 Years in the Making
SMTP [1] is close to being the perfect application protocol: it
solves a large, important problem in a minimalist way. It's simple
enough for an entry-level implementation to fit on one or two screens
of code, and flexible enough to form the basis of very powerful
product offerings in a robust and competitive market. Modulo a few
oddities (e.g., SAML), the design is well conceived and the resulting
specification is well-written and largely self-contained. There is
very little about good application protocol design that you can't
learn by reading the SMTP specification.
Unfortunately, there's one little problem: SMTP was originally
published in 1981 and since that time, a lot of application protocols
have been designed for the Internet, but there hasn't been a lot of
reuse going on. You might expect this if the application protocols
were all radically different, but this isn't the case: most are
surprisingly similar in their functional behavior, even though the
actual details vary considerably.
In late 1998, as Carl Malamud and I were sitting down to review the
Blocks architecture, we realized that we needed to have a protocol
for exchanging Blocks. The conventional wisdom is that when you need
an application protocol, there are four ways to proceed:
1. find an existing exchange protocol that (more or less) does what
you want;
2. define an exchange model on top of the world-wide web
infrastructure that (more or less) does what you want;
3. define an exchange model on top of the electronic mail
infrastructure that (more or less) does what you want; or,
4. define a new protocol from scratch that does exactly what you
want.
An engineer can make reasoned arguments about the merits of each of
the these approaches. Here's the process we followed...
The most appealing option is to find an existing protocol and use
that. (In other words, we'd rather "buy" than "make".) So, we did a
survey of many existing application protocols and found that none of
them were a good match for the semantics of the protocol we needed.
For example, most application protocols are oriented toward
client/server behavior, and emphasize the client pulling data from
the server; in contrast with Blocks, a client usually pulls data from
Rose Informational [Page 3]
RFC 3117 On the Design of Application Protocols November 2001
the server, but it also may request the server to asynchronously push
(new) data to it. Clearly, we could mutate a protocol such as FTP
[2] or SMTP into what we wanted, but by the time we did all that, the
base protocol and our protocol would have more differences than
similarities. In other words, the cost of modifying an off-the-shelf
implementation becomes comparable with starting from scratch.
Another approach is to use HTTP [3] as the exchange protocol and
define the rules for data exchange over that. For example, IPP [4]
(the Internet Printing Protocol) uses this approach. The basic idea
is that HTTP defines the rules for exchanging data and then you
define the data's syntax and semantics. Because you inherit the
entire HTTP infrastructure (e.g., HTTP's authentication mechanisms,
caching proxies, and so on), there's less for you to have to invent
(and code!). Or, conversely, you might view the HTTP infrastructure
as too helpful. As an added bonus, if you decide that your protocol
runs over port 80, you may be able to sneak your traffic past older
firewalls, at the cost of port 80 saturation.
HTTP has many strengths: it's ubiquitous, it's familiar, and there
are a lot of tools available for developing HTTP-based systems.
Another good thing about HTTP is that it uses MIME [5] for encoding
data.
Unfortunately for us, even with HTTP 1.1 [6], there still wasn't a
good fit. As a consequence of the highly-desirable goal of
maintaining compatibility with the original HTTP, HTTP's framing
mechanism isn't flexible enough to support server-side asynchronous
behavior and its authentication model isn't similar to other Internet
applications.
Mapping IPP onto HTTP 1.1 illustrates the former issue. For example,
the IPP server is supposed to signal its client when a job completes.
Since the HTTP client must originate all requests and since the
decision to close a persistent connection in HTTP is unilateral, the
best that the IPP specification can do is specify this functionality
in a non-deterministic fashion.
Further, the IPP mapping onto HTTP shows that even subtle shifts in
behavior have unintended consequences. For example, requests in IPP
are typically much larger than those seen by many HTTP server
implementations -- resulting in oddities in many HTTP servers (e.g.,
requests are sometimes silently truncated). The lesson is that
HTTP's framing mechanism is very rigid with respect to its view of
the request/response model.
Rose Informational [Page 4]
RFC 3117 On the Design of Application Protocols November 2001
Lastly, given our belief that the port field of the TCP header isn't
a constant 80, we were immune to the seductive allure of wanting to
sneak our traffic past unwary site administrators.
The third choice, layering the protocol on top of email, was
attractive. Unfortunately, the nature of our application includes a
lot of interactivity with relatively small response times. So, this
left us the final alternative: defining a protocol from scratch.
To begin, we figured that our requirements, while a little more
stringent than most, could fit inside a framework suitable for a
large number of future application protocols. The trick is to avoid
the kitchen-sink approach. (Dave Clark has a saying: "One of the
roles of architecture is to tell you what you can't do.")
Rose Informational [Page 5]
RFC 3117 On the Design of Application Protocols November 2001
2. You can Solve Any Problem...
...if you're willing to make the problem small enough.
Our most important step is to limit the problem to application
protocols that exhibit certain features:
o they are connection-oriented;
o they use requests and responses to exchange messages; and,
o they allow for asynchronous message exchange.
Let's look at each, in turn.
First, we're only going to consider connection-oriented application
protocols (e.g., those that work on top of TCP [7]). Another branch
in the taxonomy, connectionless, consists of those that don't want
the delay or overhead of establishing and maintaining a reliable
stream. For example, most DNS [8] traffic is characterized by a
single request and response, both of which fit within a single IP
datagram. In this case, it makes sense to implement a basic
reliability service above the transport layer in the application
protocol itself.
Second, we're only going to consider message-oriented application
protocols. A "message" -- in our lexicon -- is simply structured
data exchanged between loosely-coupled systems. Another branch in
the taxonomy, tightly-coupled systems, uses remote procedure calls as
the exchange paradigm. Unlike the connection-oriented/connectionless
dichotomy, the issue of loosely- or tightly-coupled systems is
similar to a continuous spectrum. Fortunately, the edges are fairly
sharp.
For example, NFS [9] is a tightly-coupled system using RPCs. When
running in a properly-configured LAN, a remote disk accessible via
NFS is virtually indistinguishable from a local disk. To achieve
this, tightly-coupled systems are highly concerned with issues of
latency. Hence, most (but not all) tightly-coupled systems use
connection-less RPC mechanisms; further, most tend to be implemented
as operating system functions rather than user-level programs. (In
some environments, the tightly-coupled systems are implemented as
single-purpose servers, on hardware specifically optimized for that
one function.)
Finally, we're going to consider the needs of application protocols
that exchange messages asynchronously. The classic client/server
model is that the client sends a request and the server sends a
Rose Informational [Page 6]
RFC 3117 On the Design of Application Protocols November 2001
response. If you think of requests as "questions" and responses as
"answers", then the server answers only those questions that it's
asked and it never asks any questions of its own. We'll need to
support a more general model, peer-to-peer. In this model, for a
given transaction one peer might be the "client" and the other the
"server", but for the next transaction, the two peers might switch
roles.
It turns out that the client/server model is a proper subset of the
peer-to-peer model: it's acceptable for a particular application
protocol to dictate that the peer that establishes the connection
always acts as the client (initiates requests), and that the peer
that listens for incoming connections always acts as the server
(issuing responses to requests).
There are quite a few existing application domains that don't fit our
requirements, e.g., nameservice (via the DNS), fileservice (via NFS),
multicast-enabled applications such as distributed video
conferencing, and so on. However, there are a lot of application
domains that do fit these requirements, e.g., electronic mail, file
transfer, remote shell, and the world-wide web. So, the bet we are
placing in going forward is that there will continue to be reasons
for defining protocols that fit within our framework.
Rose Informational [Page 7]
RFC 3117 On the Design of Application Protocols November 2001
3. Protocol Mechanisms
The next step is to look at the tasks that an application protocol
must perform and how it goes about performing them. Although an
exhaustive exposition might identify a dozen (or so) areas, the ones
we're interested in are:
o framing, which tells how the beginning and ending of each message
is delimited;
o encoding, which tells how a message is represented when exchanged;
o reporting, which tells how errors are described;
o asynchrony, which tells how independent exchanges are handled;
o authentication, which tells how the peers at each end of the
connection are identified and verified; and,
o privacy, which tells how the exchanges are protected against
third-party interception or modification.
A notable absence in this list is naming -- we'll explain why later
on.
3.1 Framing
There are three commonly used approaches to delimiting messages:
octet-stuffing, octet-counting, and connection-blasting.
An example of a protocol that uses octet-stuffing is SMTP. Commands
in SMTP are line-oriented (each command ends in a CR-LF pair). When
an SMTP peer sends a message, it first transmits the "DATA" command,
then it transmits the message, then it transmits a "." (dot) followed
by a CR-LF. If the message contains any lines that begin with a dot,
the sending SMTP peer sends two dots; similarly, when the other SMTP
peer receives a line that begins with a dot, it discards the dot,
and, if the line is empty, then it knows it's received the entire
message. Octet-stuffing has the property that you don't need the
entire message in front of you before you start sending it.
Unfortunately, it's slow because both the sender and receiver must
scan each line of the message to see if they need to transform it.
An example of a protocol that uses octet-counting is HTTP. Commands
in HTTP consist of a request line followed by headers and a body. The
headers contain an octet count indicating how large the body is. The
properties of octet-counting are the inverse of octet-stuffing:
Rose Informational [Page 8]
RFC 3117 On the Design of Application Protocols November 2001
before you can start sending a message you need to know the length of
the whole message, but you don't need to look at the content of the
message once you start sending or receiving.
An example of a protocol that uses connection-blasting is FTP.
Commands in FTP are line-oriented, and when it's time to exchange a
message, a new TCP connection is established to transmit the message.
Both octet-counting and connection-blasting have the property that
the messages can be arbitrary binary data; however, the drawback of
the connection-blasting approach is that the peers need to
communicate IP addresses and TCP port numbers, which may be
"transparently" altered by NATS [10] and network bugs. In addition,
if the messages being exchanged are small (say less than 32k), then
the overhead of establishing a connection for each message
contributes significant latency during data exchange.
3.2 Encoding
There are many schemes used for encoding data (and many more encoding
schemes have been proposed than are actually in use). Fortunately,
only a few are burning brightly on the radar.
The messages exchanged using SMTP are encoded using the 822-style
[11]. The 822-style divides a message into textual headers and an
unstructured body. Each header consists of a name and a value and is
terminated with a CR-LF pair. An additional CR-LF separates the
headers from the body.
It is this structure that HTTP uses to indicate the length of the
body for framing purposes. More formally, HTTP uses MIME, an
application of the 822-style to encode both the data itself (the
body) and information about the data (the headers). That is,
although HTTP is commonly viewed as a retrieval mechanism for HTML
[12], it is really a retrieval mechanism for objects encoded using
MIME, most of which are either HTML pages or referenced objects such
as GIFs.
3.3 Reporting
An application protocol needs a mechanism for conveying error
information between peers. The first formal method for doing this
was defined by SMTP's "theory of reply codes". The basic idea is
that an error is identified by a three-digit string, with each
position having a different significance:
the first digit: indicating success or failure, either permanent or
transient;
Rose Informational [Page 9]
RFC 3117 On the Design of Application Protocols November 2001
the second digit: indicating the part of the system reporting the
situation (e.g., the syntax analyzer); and,
the third digit: identifying the actual situation.
Operational experience with SMTP suggests that the range of error
conditions is larger than can be comfortably encoded using a three-
digit string (i.e., you can report on only 10 different things going
wrong for any given part of the system). So, [13] provides a
convenient mechanism for extending the number of values that can
occur in the second and third positions.
Virtually all of the application protocols we've discussed thus far
use the three-digit reply codes, although there is less coordination
between the designers of different application protocols than most
would care to admit. (A variation on the theory of reply codes is
employed by IMAP [14] which provides the same information using a
different syntax.)
In addition to conveying a reply code, most application protocols
also send a textual diagnostic suitable for human, not machine,
consumption. (More accurately, the textual diagnostic is suitable
for people who can read a widely used variant of the English
language.) Since reply codes reflect both positive and negative
outcomes, there have been some innovative uses made for the text
accompanying positive responses, e.g., prayer wheels [39].
Regardless, some of the more modern application protocols include a
language localization parameter for the diagnostic text.
Finally, since the introduction of reply codes in 1981, two
unresolved criticisms have been raised:
o a reply code is used both to signal the outcome of an operation
and a change in the application protocol's state; and,
o a reply code doesn't specify whether the associated textual
diagnostic is destined for the end-user, administrator, or
programmer.
3.4 Asynchrony
Few application protocols today allow independent exchanges over the
same connection. In fact, the more widely implemented approach is to
allow pipelining, e.g., command pipelining [15] in SMTP or persistent
connections in HTTP 1.1. Pipelining allows a client to make multiple
requests of a server, but requires the requests to be processed
serially. (Note that a protocol needs to explicitly provide support
for pipelining, since, without explicit guidance, many implementors
Rose Informational [Page 10]
RFC 3117 On the Design of Application Protocols November 2001
produce systems that don't handle pipelining properly; typically, an
error in a request causes subsequent requests in the pipeline to be
discarded).
Pipelining is a powerful method for reducing network latency. For
example, without persistent connections, HTTP's framing mechanism is
really closer to connection-blasting than octet-counting, and it
enjoys the same latency and efficiency problems.
In addition to reducing network latency (the pipelining effect),
asynchrony also reduces server latency by allowing multiple requests
to be processed by multi-threaded implementations. Note that if you
allow any form of asynchronous exchange, then support for parallelism
is also required, because exchanges aren't necessarily occurring
under the synchronous direction of a single peer.
Unfortunately, when you allow parallelism, you also need a flow
control mechanism to avoid starvation and deadlock. Otherwise, a
single set of exchanges can monopolize the bandwidth provided by the
transport layer. Further, if a peer is resource-starved, then it may
not have enough buffers to receive a message and deadlock results.
Flow control is typically implemented at the transport layer. For
example, TCP uses sequence numbers and a sliding window: each
receiver manages a sliding window that indicates the number of data
octets that may be transmitted before receiving further permission.
However, it's now time for the second shoe to drop: segmentation. If
you do flow control then you also need a segmentation mechanism to
fragment messages into smaller pieces before sending and then re-
assemble them as they're received.
Both flow control and segmentation have an impact on how the protocol
does framing. Before we defined framing as "how to tell the
beginning and end of each message" -- in addition, we need to be able
to identify independent messages, send messages only when flow
control allows us to, and segment them if they're larger than the
available window (or too large for comfort).
Segmentation impacts framing in another way -- it relaxes the octet-
counting requirement that you need to know the length of the whole
message before sending it. With segmentation, you can start sending
segments before the whole message is available. In HTTP 1.1 you can
"chunk" (segment) data to get this advantage.
Rose Informational [Page 11]
RFC 3117 On the Design of Application Protocols November 2001
3.5 Authentication
Perhaps for historical (or hysterical) reasons, most application
protocols don't do authentication. That is, they don't authenticate
the identity of the peers on the connection or the authenticity of
the messages being exchanged. Or, if authentication is done, it is
domain-specific for each protocol. For example, FTP and HTTP use
entirely different models and mechanisms for authenticating the
initiator of a connection. (Independent of mainstream HTTP, there is
a little-used variant [16] that authenticates the messages it
exchanges.)
A large part of the problem is that different security mechanisms
optimize for strength, scalability, or ease of deployment. So, a few
years ago, SASL [17] (the Simple Authentication and Security Layer)
was developed to provide a framework for authenticating protocol
peers. SASL let's you describe how an authentication mechanism
works, e.g., an OTP [18] (One-Time Password) exchange. It's then up
to each protocol designer to specify how SASL exchanges are
generically conveyed by the protocol. For example, [19] explains how
SASL works with SMTP.
A notable exception to the SASL bandwagon is HTTP, which defines its
own authentication mechanisms [20]. There is little reason why SASL
couldn't be introduced to HTTP, although to avoid certain race-
conditions, the persistent connection mechanism of HTTP 1.1 must be
used.
SASL has an interesting feature in that in addition to explicit
protocol exchanges to authenticate identity, it can also use implicit
information provided from the layer below. For example, if the
connection is running over IPsec [21], then the credentials of each
peer are known and verified when the TCP connection is established.
Finally, as its name implies, SASL can do more than authentication --
depending on which SASL mechanism is in use, message integrity or
privacy services may also be provided.
3.6 Privacy
HTTP is the first widely used protocol to make use of a transport
security protocol to encrypt the data sent on the connection. The
current version of this mechanism, TLS [22], is available to all
application protocols, e.g., SMTP and ACAP [23] (the Application
Configuration Access Protocol).
Rose Informational [Page 12]
RFC 3117 On the Design of Application Protocols November 2001
The key difference between the original mechanism and TLS, is one of
provisioning not technology. In the original approach to
provisioning, a world-wide web server listens on two ports (one for
plaintext traffic and the other for secured traffic); in contrast, by
today's conventions, a server implementing an application protocol
that is specified as TLS-enabled (e.g., [24] and [25]) listens on a
single port for plaintext traffic, and, once a connection is
established, the use of TLS on that connection is negotiable.
Finally, note that both SASL and TLS are about "transport security"
not "object security". What this means is that they focus on
providing security properties for the actual communication, they
don't provide any security properties for the data exchanged
independent of the communication.
3.7 Let's Recap
Let's briefly compare the properties of the three main connection-
oriented application protocols in use today:
Mechanism ESMTP FTP HTTP1.1
-------------- ----------- --------- -------------
Framing stuffing blasting counting
Encoding 822-style binary MIME
Reporting 3-digit 3-digit 3-digit
Asynchrony pipelining none pipelining
and chunking
Authentication SASL user/pass user/pass
Privacy SASL or TLS none TLS (nee SSL)
Note that the username/password mechanisms used by FTP and HTTP are
entirely different with one exception: both can be termed a
"username/password" mechanism.
These three choices are broadly representative: as more protocols are
considered, the patterns are reinforced. For example, POP [26] uses
octet-stuffing, but IMAP uses octet-counting, and so on.
Rose Informational [Page 13]
RFC 3117 On the Design of Application Protocols November 2001
4. Protocol Properties
When we design an application protocol, there are a few properties
that we should keep an eye on.
4.1 Scalability
A well-designed protocol is scalable.
Because few application protocols support asynchrony, a common trick
is for a program to open multiple simultaneous connections to a
single destination. The theory is that this reduces latency and
increases throughput. The reality is that both the transport layer
and the server view each connection as an independent instance of the
application protocol, and this causes problems.
In terms of the transport layer, TCP uses adaptive algorithms to
efficiently transmit data as networks conditions change. But what
TCP learns is limited to each connection. So, if you have multiple
TCP connections, you have to go through the same learning process
multiple times -- even if you're going to the same host. Not only
does this introduce unnecessary traffic spikes into the network,
because TCP uses a slow-start algorithm when establishing a
connection, the program still sees additional latency. To deal with
the fact that a lack of asynchrony in application protocols causes
implementors to make sloppy use of the transport layer, network
protocols are now provisioned with increasing sophistication, e.g.,
RED [27]. Further, suggestions are also being considered for
modification of TCP implementations to reduce concurrent learning,
e.g., [28].
In terms of the server, each incoming connection must be dispatched
and (probably) authenticated against the same resources.
Consequently, server overhead increases based on the number of
connections established, rather than the number of remote users. The
same issues of fairness arise: it's much harder for servers to
allocate resources on a per-user basis, when a user can cause an
arbitrary number of connections to pound on the server.
Another important aspect of scalability to consider is the relative
numbers of clients and servers. (This is true even in the peer-to-
peer model, where a peer can act both in the client and server role.)
Typically, there are many more client peers than server peers. In
this case, functional requirements should be shifted from the servers
onto the clients. The reason is that a server is likely to be
interacting with multiple clients and this functional shift makes it
easier to scale.
Rose Informational [Page 14]
RFC 3117 On the Design of Application Protocols November 2001
4.2 Efficiency
A well-designed protocol is efficient.
For example, although a compelling argument can be made than octet-
stuffing leads to more elegant implementations than octet-counting,
experience shows that octet-counting consumes far fewer cycles.
Regrettably, we sometimes have to compromise efficiency in order to
satisfy other properties. For example, 822 (and MIME) use textual
headers. We could certainly define a more efficient representation
for the headers if we were willing to limit the header names and
values that could be used. In this case, extensibility is viewed as
more important than efficiency. Of course, if we were designing a
network protocol instead of an application protocol, then we'd make
the trade-offs using a razor with a different edge.
4.3 Simplicity
A well-designed protocol is simple.
Here's a good rule of thumb: a poorly-designed application protocol
is one in which it is equally as "challenging" to do something basic
as it is to do something complex. Easy things should be easy to do
and hard things should be harder to do. The reason is simple: the
pain should be proportional to the gain.
Another rule of thumb is that if an application protocol has two ways
of doing the exact same thing, then there's a problem somewhere in
the architecture underlying the design of the application protocol.
Hopefully, simple doesn't mean simple-minded: something that's well-
designed accommodates everything in the problem domain, even the
troublesome things at the edges. What makes the design simple is
that it does this in a consistent fashion. Typically, this leads to
an elegant design.
4.4 Extensibility
A well-designed protocol is extensible.
As clever as application protocol designers are, there are likely to
be unforeseen problems that the application protocol will be asked to
solve. So, it's important to provide the hooks that can be used to
add functionality or customize behavior. This means that the
protocol is evolutionary, and there must be a way for implementations
reflecting different steps in the evolutionary path to negotiate
which extensions will be used.
Rose Informational [Page 15]
RFC 3117 On the Design of Application Protocols November 2001
But, it's important to avoid falling into the extensibility trap: the
hooks provided should not be targeted at half-baked future
requirements. Above all, the hooks should be simple.
Of course good design goes a long way towards minimizing the need for
extensibility. For example, although SMTP initially didn't have an
extension framework, it was only after ten years of experience that
its excellent design was altered. In contrast, a poorly-designed
protocol such as Telnet [29] can't function without being built
around the notion of extensions.
4.5 Robustness
A well-designed protocol is robust.
Robustness and efficiency are often at odds. For example, although
defaults are useful to reduce packet sizes and processing time, they
tend to encourage implementation errors.
Counter-intuitively, Postel's robustness principle ("be conservative
in what you send, liberal in what you accept") often leads to
deployment problems. Why? When a new implementation is initially
fielded, it is likely that it will encounter only a subset of
existing implementations. If those implementations follow the
robustness principle, then errors in the new implementation will
likely go undetected. The new implementation then sees some, but not
widespread deployment. This process repeats for several new
implementations. Eventually, the not-quite-correct implementations
run into other implementations that are less liberal than the initial
set of implementations. The reader should be able to figure out what
happens next.
Accordingly, explicit consistency checks in a protocol are very
useful, even if they impose implementation overhead.
Rose Informational [Page 16]
RFC 3117 On the Design of Application Protocols November 2001
5. The BXXP Framework
Finally, we get to the money shot: here's what we did.
We defined an application protocol framework called BXXP (the Blocks
eXtensible eXchange Protocol). The reason it's a "framework" instead
of an application protocol is that we provide all the mechanisms
discussed earlier without actually specifying the kind of messages
that get exchanged. So, when someone else needs an application
protocol that requires connection-oriented, asynchronous
interactions, they can start with BXXP. It's then their
responsibility to define the last 10% of the application protocol,
the part that does, as we say, "the useful work".
So, what does BXXP look like?
Mechanism BXXP
-------------- ----------------------------------------
Framing counting, with a trailer
Encoding MIME, defaulting to text/xml
Reporting 3-digit and localized textual diagnostic
Asynchrony channels
Authentication SASL
Privacy SASL or TLS
5.1 Framing and Encoding
Framing in BXXP looks a lot like SMTP or HTTP: there's a command line
that identifies the beginning of the frame, then there's a MIME
object (headers and body). Unlike SMTP, BXXP uses octet-counting,
but unlike HTTP, the command line is where you find the size of the
payload. Finally, there's a trailer after the MIME object to aid in
detecting framing errors.
Actually, the command line for BXXP has a lot of information, it
tells you:
o what kind of message is in this frame;
o whether there's more to the message than just what's in this frame
(a continuation flag);
Rose Informational [Page 17]
RFC 3117 On the Design of Application Protocols November 2001
o how to distinguish the message contained in this frame from other
messages (a message number);
o where the payload occurs in the sliding window (a sequence number)
along with how many octets are in the payload of this frame; and,
o which part of the application should get the message (a channel
number).
(The command line is textual and ends in a CR-LF pair, and the
arguments are separated by a space.)
Since you need to know all this stuff to process a frame, we put it
all in one easy to parse location. You could probably devise a more
efficient encoding, but the command line is a very small part of the
frame, so you wouldn't get much bounce from optimizing it. Further,
because framing is at the heart of BXXP, the frame format has several
consistency checks that catch the majority of programming errors.
(The combination of a sequence number, an octet count, and a trailer
allows for very robust error detection.)
Another trick is in the headers: because the command line contains
all the framing information, the headers may contain minimal MIME
information (such as Content-Type). Usually, however, the headers
are empty. That's because the BXXP default payload is XML [30].
(Actually, a "Content-Type: text/xml" with binary transfer encoding).
We chose XML as the default because it provides a simple mechanism
for nested, textual representations. (Alas, the 822-style encoding
doesn't easily support nesting.) By design, XML's nature isn't
optimized for compact representations. That's okay because we're
focusing on loosely-coupled systems and besides there are efficient
XML parsers available. Further, there's a fair amount of anecdotal
experience -- and we'll stress the word "anecdotal" -- that if you
have any kind of compression (either at the link-layer or during
encryption), then XML encodings squeeze down nicely.
Even so, use of XML is probably the most controversial part of BXXP.
After all, there are more efficient representations around. We
agree, but the real issue isn't efficiency, it's ease of use: there
are a lot of people who grok the XML thing and there are a lot of XML
tools out there. The pain of recreating this social infrastructure
far outweighs any benefits of devising a new representation. So, if
the "make" option is too expensive, is there something else we can
"buy" besides XML? Well, there's ASN.1/BER (just kidding).
Rose Informational [Page 18]
RFC 3117 On the Design of Application Protocols November 2001
In the early days of the SNMP [31], which does use ASN.1, the same
issues arose. In the end, the working group agreed that the use of
ASN.1 for SNMP was axiomatic, but not because anyone thought that
ASN.1 was the most efficient, or the easiest to explain, or even well
liked. ASN.1 was given axiomatic status because the working group
decided it was not going to spend the next three years explaining an
alternative encoding scheme to the developer community.
So -- and we apologize for appealing to dogma -- use of XML as the
favored encoding scheme in BXXP is axiomatic.
5.2 Reporting
We use 3-digit error codes, with a localized textual diagnostic.
(Each peer specifies a preferred ordering of languages.)
In addition, the reply to a message is flagged as either positive or
negative. This makes it easy to signal success or failure and allow
the receiving peer some freedom in the amount of parsing it wants to
do on failure.
5.3 Asynchrony
Despite the lessons of SMTP and HTTP, there isn't a lot of field
experience to rely on when designing the asynchrony features of BXXP.
(Actually, there were several efforts in 1998 related to application
layer framing, e.g., [32], but none appear to have achieved orbit.)
So, here's what we did: frames are exchanged in the context of a
"channel". Each channel has an associated "profile" that defines the
syntax and semantics of the messages exchanged over a channel.
Channels provide both an extensibility mechanism for BXXP and the
basis for parallelism. Remember the last parameter in the command
line of a BXXP frame? The "part of the application" that gets the
message is identified by a channel number.
A profile is defined according to a "Profile Registration" template.
The template defines how the profile is identified (using a URI
[33]), what kind of messages get exchanged, along with the syntax and
semantics of those messages. When you create a channel, you identify
a profile and maybe piggyback your first message. If the channel is
successfully created, you get back a positive response; otherwise,
you get back a negative response explaining why.
Perhaps the easiest way to see how channels provide an extensibility
mechanism is to consider what happens when a session is established.
Each BXXP peer immediately sends a greeting on channel zero
Rose Informational [Page 19]
RFC 3117 On the Design of Application Protocols November 2001
identifying the profiles that each support. (Channel 0 is used for
channel management -- it's automatically created when a session is
opened.) If you want transport security, the very first thing you do
is to create a channel that negotiates transport security, and, once
the channel is created, you tell it to do its thing. Next, if you
want to authenticate, you create a channel that performs user
authentication, and, once the channel is created, you tell it to get
busy. At this point, you create one or more channels for data
exchange. This process is called "tuning"; once you've tuned the
session, you start using the data exchange channels to do "the useful
work".
The first channel that's successfully started has a trick associated
with it: when you ask to start the channel, you're allowed to specify
a "service name" that goes with it. This allows a server with
multiple configurations to select one based on the client's
suggestion. (A useful analogy is HTTP 1.1's "Host:" header.) If the
server accepts the "service name", then this configuration is used
for the rest of the session.
To allow parallelism, BXXP allows you to use multiple channels
simultaneously. Each channel processes messages serially, but there
are no constraints on the processing order for different channels.
So, in a multi-threaded implementation, each channel maps to its own
thread.
This is the most general case, of course. For one reason or another,
an implementor may not be able to support this. So, BXXP allows for
both positive and negative replies when a message is sent. So, if
you want the classic client/server model, the client program should
simply reject any new message sent by the server. This effectively
throttles any asynchronous messages from the server.
Of course, we now need to provide mechanisms for segmentation and
flow control. For the former, we just put a "continuation" or "more
to come" flag in the command line for the frame. For the latter, we
introduced the notion of a "transport mapping".
What this means is that BXXP doesn't directly define how it sits of
top of TCP. Instead, it lists a bunch of requirements for how a
transport service needs to support a BXXP session. Then, in a
separate document, we defined how you can use TCP to meet these
requirements.
This second document pretty much says "use TCP directly", except that
it introduces a flow control mechanism for multiplexing channels over
a single TCP connection. The mechanism we use is the same one used
Rose Informational [Page 20]
RFC 3117 On the Design of Application Protocols November 2001
by TCP (sequence numbers and a sliding window). It's proven, and can
be trivially implemented by a minimal implementation of BXXP.
The introduction of flow control is a burden from an implementation
perspective -- although TCP's mechanism is conceptually simple, an
implementor must take great care. For example, issues such as
priorities, queue management, and the like should be addressed.
Regardless, we feel that the benefits of allowing parallelism for
intra-application streams is worth it. (Besides, our belief is that
few application implementors will actually code the BXXP framework
directly -- rather, we expect them to use third-party packages that
implement BXXP.)
5.4 Authentication
We use SASL. If you successfully authenticate using a channel, then
there is a single user identity for each peer on that session (i.e.,
authentication is per-session, not per-channel). This design
decision mandates that each session correspond to a single user
regardless of how many channels are open on that session. One reason
why this is important is that it allows service provisioning, such as
quality of service (e.g., as in [34]) to be done on a per-user
granularity.
5.5 Privacy
We use SASL and TLS. If you successfully complete a transport
security negotiation using a channel, then all traffic on that
session is secured (i.e., confidentiality is per-session, not per-
channel, just like authentication).
We defined a BXXP profile that's used to start the TLS engine.
5.6 Things We Left Out
We purposefully excluded two things that are common to most
application protocols: naming and authorization.
Naming was excluded from the framework because, outside of URIs,
there isn't a commonly accepted framework for naming things. To our
view, this remains a domain-specific problem for each application
protocol. Maybe URIs are appropriate in the context of a
particularly problem domain, maybe not. So, when an application
protocol designer defines their own profile to do "the useful work",
they'll have to deal with naming issues themselves. BXXP provides a
mechanism for identifying profiles and binding them to channels. It's
up to you to define the profile and use the channel.
Rose Informational [Page 21]
RFC 3117 On the Design of Application Protocols November 2001
Similarly, authorization was explicitly excluded from the framework.
Every approach to authorization we've seen uses names to identify
principals (i.e., targets and subjects), so if a framework doesn't
include naming, it can't very well include authorization.
Of course, application protocols do have to deal with naming and
authorization -- those are two of the issues addressed by the
applications protocol designer when defining a profile for use with
BXXP.
5.7 From Framework to Protocol
So, how do you go about using BXXP? To begin, call it "BEEP", not
"BXXP" (we'll explain why momentarily).
First, get the BEEP core specification [35] and read it. Next,
define your own profile. Finally, get one of the open source SDKs
(in C, Java, or Tcl) and start coding.
The BEEP specification defines several profiles itself: a channel
management profile, a family of profiles for SASL, and a transport
security profile. In addition, there's a second specification [36]
that explains how a BEEP session maps onto a single TCP connection.
For a complete example of an application protocol defined using BEEP,
look at reliable syslog [37]. This document exemplifies the formula:
application protocol = BEEP + 1 or more profiles
+ authorization policies
+ provisioning rules (e.g., use of SRV RRs [38])
Rose Informational [Page 22]
RFC 3117 On the Design of Application Protocols November 2001
6. BXXP is now BEEP
We started work on BXXP in the fall of 1998. The IETF formed a
working group on BXXP in the summer of 2000. Although the working
group made some enhancements to BXXP, three are the most notable:
o The payload default is "application/octet-stream". This is
primarily for wire-efficiency -- if you care about wire-
efficiency, then you probably wouldn't be using "text/xml"...
o One-to-many exchanges are supported (the client sends one message
and the server sends back many replies).
o BXXP is now called BEEP (more comic possibilities).
7. Security Considerations
Consult Section [35]'s Section 8 for a discussion of BEEP-related
security issues.
Rose Informational [Page 23]
RFC 3117 On the Design of Application Protocols November 2001
References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[2] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.
[3] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[4] Herriot, R., "Internet Printing Protocol/1.0: Encoding and
Transport", RFC 2565, April 1999.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[6] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[8] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[9] Microsystems, Sun., "NFS: Network File System Protocol
specification", RFC 1094, March 1989.
[10] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[11] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[12] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, November 1995.
[13] Freed, N., "SMTP Service Extension for Returning Enhanced Error
Codes", RFC 2034, October 1996.
[14] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
December 1994.
[15] Freed, N., "SMTP Service Extension for Command Pipelining", RFC
2197, September 1997.
Rose Informational [Page 24]
RFC 3117 On the Design of Application Protocols November 2001
[16] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer
Protocol", RFC 2660, August 1999.
[17] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[18] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
October 1998.
[19] Myers, J., "SMTP Service Extension for Authentication", RFC
2554, March 1999.
[20] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[21] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[22] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[23] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997.
[24] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS",
RFC 2487, January 1999.
[25] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999.
[26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
53, RFC 1939, May 1996.
[27] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J.
and L. Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[28] Touch, J., "TCP Control Block Interdependence", RFC 2140, April
1997.
[29] Postel, J. and J. Reynolds, "Telnet Protocol Specification",
STD 8, RFC 854, May 1983.
Rose Informational [Page 25]
RFC 3117 On the Design of Application Protocols November 2001
[30] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-
xml-19980210>.
[31] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May
1990.
[32] World Wide Web Consortium, "SMUX Protocol Specification",
Working Draft, July 1998, <http://www.w3.org/TR/1998/WD-mux-
19980710>.
[33] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[34] Waitzman, D., "IP over Avian Carriers with Quality of Service",
RFC 2549, April 1999.
[35] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[36] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
2001.
[37] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195,
November 2001.
[38] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[39] <http://mappa.mundi.net/cartography/Wheel/>
Author's Address
Marshall T. Rose
Dover Beach Consulting, Inc.
POB 255268
Sacramento, CA 95865-5268
US
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Rose Informational [Page 26]
RFC 3117 On the Design of Application Protocols November 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rose Informational [Page 27]
|