File: rfc3117.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1515 lines) | stat: -rw-r--r-- 57,279 bytes parent folder | download | duplicates (5)
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]