File: rfc2371.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 (1739 lines) | stat: -rw-r--r-- 71,399 bytes parent folder | download | duplicates (7)
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
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739






Network Working Group                                           J. Lyon
Request for Comments: 2371                                    Microsoft
Category: Standards Track                                      K. Evans
                                                               J. Klein
                                                       Tandem Computers
                                                              July 1998


                     Transaction Internet Protocol
                              Version 3.0

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   In many applications where different nodes cooperate on some work,
   there is a need to guarantee that the work happens atomically. That
   is, each node must reach the same conclusion as to whether the work
   is to be completed, even in the face of failures.  This document
   proposes a simple, easily-implemented protocol for achieving this
   end.

Table of Contents

 1. Introduction                                                       2
 2. Example Usage                                                      3
 3. Transactions                                                       4
 4. Connections                                                        4
 5. Transaction Identifiers                                            5
 6. Pushing vs. Pulling Transactions                                   5
 7. TIP Transaction Manager Identification & Connection Establishment  6
 8. TIP Uniform Resource Locators                                      8
 9. States of a Connection                                            10
 10. Protocol Versioning                                              12
 11. Commands and Responses                                           12
 12. Command Pipelining                                               13
 13. TIP Commands                                                     13
 14. Error Handling                                                   20



Lyon, et. al.               Standards Track                     [Page 1]

RFC 2371                    TIP Version 3.0                    July 1998


 15. Connection Failure and Recovery                                  20
 16. Security Considerations                                          22
 17. References                                                       25
 18. Authors' Addresses                                               26
 19. Comments                                                         26
 Appendix A. The TIP Multiplexing Protocol Version 2.0.               27
 Fully Copyright Statement                                            31

1. Introduction

   The standard method for achieving atomic commitment is the two-phase
   commit protocol; see [1] for an introduction to atomic commitment and
   two-phase commit protocols.

   Numerous two-phase commit protocols have been implemented over the
   years.  However, none of them has become widely used in the Internet,
   due mainly to their complexity.  Most of that complexity comes from
   the fact that the two-phase commit protocol is bundled together with
   a specific program-to-program communication protocol, and that
   protocol lives on top of a very large infrastructure.

   This memo proposes a very simple two-phase commit protocol.  It
   achieves its simplicity by specifying only how different nodes agree
   on the outcome of a transaction; it allows (even requires) that the
   subject matter on which the nodes are agreeing be communicated via
   other protocols. By doing so, we avoid all of the issues related to
   application communication semantics and data representation (to name
   just a few). Independent of the application communication protocol a
   transaction manager may use the Transport Layer Security protocol [3]
   to authenticate other transaction managers and encrypt messages.

   It is envisioned that this protocol will be used mainly for a
   transaction manager on one Internet node to communicate with a
   transaction manager on another node. While it is possible to use this
   protocol for application programs and/or resource managers to speak
   to transaction managers, this communication is usually intra-node,
   and most transaction managers already have more-than-adequate
   interfaces for the task.

   While we do not expect this protocol to replace existing ones, we do
   expect that it will be relatively easy for many existing
   heterogeneous transaction managers to implement this protocol for
   communication with each other.

   Further supplemental information regarding the TIP protocol can be
   found in [5].





Lyon, et. al.               Standards Track                     [Page 2]

RFC 2371                    TIP Version 3.0                    July 1998


2. Example Usage

   Today the electronic shopping basket is a common metaphor at many
   electronic store-fronts. Customers browse through an electronic
   catalog, select goods and place them into an electronic shopping
   basket. HTTP servers [2] provide various means ranging from URL
   encoding to context cookies to keep track of client context (e.g.
   the shopping basket of a customer) and resume it on subsequent
   customer requests.

   Once a customer has finished shopping they may decide to commit their
   selection and place the associated orders. Most orders may have no
   relationship with each other except being executed as part of the
   same shopping transaction; others may be dependent on each other (for
   example, if made as part of a special offering).  Irrespective of
   these details a customer will expect that all orders have been
   successfully placed upon receipt of a positive acknowledgment.
   Today's electronic store-fronts must implement their own special
   protocols to coordinate such placement of all orders. This
   programming is especially complex when orders are placed through
   multiple electronic store-fronts. This complexity limits the
   potential utility of internet applications, and constrains growth.
   The protocol described in this document intends to provide a standard
   for Internet servers to achieve agreement on a unit of shared work
   (e.g. placement of orders in an electronic shopping basket).  The
   server (e.g. a CGI program) placing the orders may want to start a
   transaction calling its local transaction manager, and ask other
   servers participating in the work to join the transaction.  The
   server placing the orders passes a reference to the transaction as
   user data on HTTP requests to the other servers.  The other servers
   call their transaction managers to start a local transaction and ask
   them to join the remote transaction using the protocol defined in
   this document. Once all orders have been placed, execution of the
   two-phase-commit protocol is delegated to the involved transaction
   managers. If the transaction commits, all orders have been
   successfully placed and the customer gets a positive acknowledgment.
   If the transaction aborts no orders will be placed and the customer
   will be informed of the problem.

   Transaction support greatly simplifies programming of these
   applications as exception handling and failure recovery are delegated
   to a special component. End users are also not left having to deal
   with the consequences of only partial success.  While this example
   shows how the protocol can be used by HTTP servers, applications may
   use the protocol when accessing a remote database (e.g. via ODBC), or
   invoking remote services using other already existing protocols (e.g.





Lyon, et. al.               Standards Track                     [Page 3]

RFC 2371                    TIP Version 3.0                    July 1998


   RPC). The protocol makes it easy for applications in a heterogeneous
   network to participate in the same transaction, even if using
   different communication protocols.

3. Transactions

   "Transaction" is the term given to the programming model whereby
   computational work performed has atomic semantics. That is, either
   all work completes successfully and changes are made permanent (the
   transaction commits), or if any work is unsuccessful, changes are
   undone (the transaction aborts). The work comprising a transaction
   (unit of work), is defined by the application.

4. Connections

   The Transaction Internet Protocol (TIP) requires a reliable ordered
   stream transport with low connection setup costs. In an Internet (IP)
   environment, TIP operates over TCP, optionally using TLS to provide a
   secured and authenticated connection, and optionally using a protocol
   to multiplex light-weight connections over the same TCP or TLS
   connection.

   Transaction managers that share transactions establish a TCP (and
   optionally a TLS) connection. The protocol uses a different
   connection for each simultaneous transaction shared betwween two
   transaction managers. After a transaction has ended, the connection
   can be reused for a different transaction.

   Optionally, instead of associating a TCP or TLS connection with only
   a single transaction, two transaction managers may agree on a
   protocol to multiplex light-weight connections over the same TCP or
   TLS connection, and associate each simultaneous transaction with a
   separate light-weight connection. Using light-weight connections
   reduces latency and resource consumption associated with executing
   simultaneous transactions. Similar techniques as described here are
   widely used by existing transaction processing systems.  See Appendix
   A for an example of one such protocol.

   Note that although the TIP protocol itself is described only in terms
   of TCP and TLS, there is nothing to preclude the use of TIP with
   other transport protocols. However, it is up to the implementor to
   ensure the chosen transport provides equivalent semantics to TCP, and
   to map the TIP protocol appropriately.








Lyon, et. al.               Standards Track                     [Page 4]

RFC 2371                    TIP Version 3.0                    July 1998


   In this document the terms "connection" or "TCP connection" can refer
   to a TIP TCP connection, a TIP TLS connection, or a TIP multiplexing
   connection (over either TCP or TLS). It makes no difference which,
   the behavior is the same in each case. Where there are differences in
   behavior between the connection types, these are stated explicitly.

5. Transaction Identifiers

   Unfortunately, there is no single globally-accepted standard for the
   format of a transaction identifier; there are various standard and
   proprietary formats.  Allowed formats for a TIP transaction
   identifier are described below in the section "TIP Uniform Resource
   Locators". A transaction manager may map its internal transaction
   identifiers into this TIP format in any manner it sees fit.
   Furthermore, each party in a superior/subordinate relationship gets
   to assign its own identifier to the transaction; these identifiers
   are exchanged when the relationship is first established.  Thus, a
   transaction manager gets to use its own format of transaction
   identifier internally, but it must remember a foreign transaction
   identifier for each superior/subordinate relationship in which it is
   involved.

6. Pushing vs. Pulling Transactions

   Suppose that some program on node "A" has created a transaction, and
   wants some program on node "B" to do some work as part of the
   transaction.  There are two classical ways that he does this,
   referred to as the "push" model and the "pull" model.

   In the "push" model, the program on A first asks his transaction
   manager to export the transaction to node B.  A's transaction manager
   sends a message to B's TM asking it to instantiate the transaction as
   a subordinate of A, and return its name for the transaction.  The
   program on A then sends a message to its counterpart on B on the
   order of "Do some work, and make it part of the transaction that your
   transaction manager already knows of by the name ...".  Because A's
   TM knows that it sent the transaction to B's TM, A's TM knows to
   involve B's TM in the two-phase commit process.

   In the "pull" model, the program on A merely sends a message to B on
   the order of "Do some work, and make it part of the transaction that
   my TM knows by the name ...".  The program on B asks its TM to enlist
   in the transaction.  At that time, B's TM will "pull" the transaction
   over from A.  As a result of this pull, A's TM knows to involve B's
   TM in the two-phase commit process.

   The protocol described here supports both the "push" and "pull"
   models.



Lyon, et. al.               Standards Track                     [Page 5]

RFC 2371                    TIP Version 3.0                    July 1998


7. TIP Transaction Manager Identification and Connection Establishment

   In order for TIP transaction managers to connect they must be able to
   identify and locate each other. The information necessary to do this
   is described by the TIP transaction manager address.

   [This specification does not prescribe how TIP transaction managers
   initially obtain the transaction manager address (which will probably
   be via some implementation-specific configuration mechanism).]

   TIP transaction manager addresses take the form:

     <hostport><path>

   The <hostport> component comprises:

     <host>[:<port>]

   where <host> is either a <dns name> or an <ip address>; and <port> is
   a decimal number specifying the port at which the transaction manager
   (or proxy) is listening for requests to establish TIP connections. If
   the port number is omitted, the standard TIP port number (3372) is
   used.

   A <dns name> is a standard name, acceptable to the domain name
   service. It must be sufficiently qualified to be useful to the
   receiver of the command.

   An <ip address> is an IP address, in the usual form: four decimal
   numbers separated by period characters.

   The <hostport> component defines the scope (locale) of the <path>
   component.

   The <path> component of the transaction manager address contains data
   identifying the specific TIP transaction manager, at the location
   defined by <hostport>.

   The <path> component takes the form:

     "/" [path_segments]

     path_segments = segment *( "/" segment )
     segment = *pchar *( ";" param )
     param = *pchar

     pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
     unreserved = ASCII character octets with values in the range



Lyon, et. al.               Standards Track                     [Page 6]

RFC 2371                    TIP Version 3.0                    July 1998


                  (inclusive): 48-57, 65-90, 97-122 | "$" | "-" | "_" |
                  "." | "!" | "~" | "*" | "'" | "(" | ")" | ","
     escaped = "%" hex hex
     hex = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" |
           "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" |
           "e" | "f"

   The <path> component may consist of a sequence of path segments
   separated by a single slash "/" character. Within a path segment, the
   characters "/", ";", "=", and "?" are reserved. Each path segment may
   include a sequence of parameters, indicated by the semicolon ";"
   character. The parameters are not significant to the parsing of
   relative references.

   [It is intended that the form of the transaction manager address
   follow the proposed scheme for Uniform Resource Identifiers (URI)
   [8].]

   The TIP transaction manager address therefore provides to the
   connection initiator (the primary) the endpoint identifier to be used
   for the TCP connection (<hostport>), and to the connection receiver
   (the secondary) the path to be used to locate the specific TIP
   transaction manager (<path>). This is all the information required
   for the connection between the primary and secondary TIP transaction
   managers to be established.

   After a connection has been established, the primary party issues an
   IDENTIFY command. This command includes as parameters two transaction
   manager addresses: the primary transaction manager address, and the
   secondary transaction manager address.

   The primary transaction manager address identifies the TIP
   transaction manager that initiated the connection. This information
   is required in certain cases after connection failures, when one of
   the parties of the connection must re-establish a new connection to
   the other party in order to complete the two-phase-commit protocol.
   If the primary party needs to re-establish the connection, the job is
   easy: a connection is established in the same way as was the original
   connection. However, if the secondary party needs to re-establish the
   connection, it must be known how to contact the initiator of the
   original connection. This information is supplied to the secondary
   via the primary transaction manager address on the IDENTIFY command.
   If a primary transaction manager address is not supplied, the primary
   party must not perform any action which would require a connection to
   be re-established (e.g. to perform recovery actions).






Lyon, et. al.               Standards Track                     [Page 7]

RFC 2371                    TIP Version 3.0                    July 1998


   The secondary transaction manager address identifies the receiving
   TIP transaction manager. In the case of TIP communication via
   intermediate proxy servers, this URL may be used by the proxy servers
   to correctly identify and connect to the required TIP transaction
   manager.

8. TIP Uniform Resource Locators

   Transactions and transaction managers are resources associated with
   the TIP protocol. Transaction managers and transactions are located
   using the transaction manager address scheme. Once a connection has
   been established, TIP commands may be sent to operate on transactions
   associated with the respective transaction managers.

   Applications which want to pull a transaction from a remote node must
   supply a reference to the remote transaction which allows the local
   transaction manager (i.e. the transaction manager pulling the
   transaction) to connect to the remote transaction manager and
   identify the particular transaction. Applications which want to push
   a transaction to a remote node must supply a reference to the remote
   transaction manager (i.e. the transaction manager to which the
   transaction is to be pushed), which allows the local transaction
   manager to locate the remote transaction manager. The TIP protocol
   defines a URL scheme [4] which allows applications and transaction
   managers to exchange references to transaction managers and
   transactions.

   A TIP URL takes the form:

     tip://<transaction manager address>?<transaction string>

   where <transaction manager address> identifies the TIP transaction
   manager (as defined in Section 7 above); and <transaction string>
   specifies a transaction identifier, which may take one of two forms
   (standard or non-standard):

   i. "urn:" <NID> ":" <NSS>

     A standard transaction identifier, conforming to the proposed
     Internet Standard for Uniform Resource Names (URNs), as specified
     by RFC2141; where <NID> is the Namespace Identifier, and <NSS> is
     the Namespace Specific String. The Namespace ID determines the
     syntactic interpretation of the Namespace Specific String. The
     Namespace Specific String is a sequence of characters representing
     a transaction identifier (as defined by <NID>). The rules for the
     contents of these fields are specified by [6] (valid characters,
     encoding, etc.).




Lyon, et. al.               Standards Track                     [Page 8]

RFC 2371                    TIP Version 3.0                    July 1998


     This format of <transaction string> may be used to express global
     transaction identifiers in terms of standard representations.
     Examples for <NID> might be <iso> or <xopen>. e.g.

       tip://123.123.123.123/?urn:xopen:xid

     Note that Namespace Ids require registration. See [7] for details
     on how to do this.

   ii. <transaction identifier>

     A sequence of printable ASCII characters (octets with values in the
     range 32 through 126 inclusive (excluding ":") representing a
     transaction identifier. In this non-standard case, it is the
     combination of <transaction manager address> and <transaction
     identifier> which ensures global uniqueness. e.g.

       tip://123.123.123.123/?transid1

     To create a non-standard TIP URL from a transaction identifier,
     first replace any reserved characters in the transaction identifier
     with their equivalent escape sequences, then insert the appropriate
     transaction manager address. If the transaction identifier is one
     that you created, insert your own transaction manager address. If
     the transaction identifier is one that you received on a TIP
     connection that you initiated, use the secondary transaction
     manager address that was sent in the IDENTIFY command. If the
     transaction identifier is one that you received on a TIP connection
     that you did not initiate, use the primary transaction manager
     address that was received in the IDENTIFY command.

   TIP URLs must be guaranteed globally unique for all time. This
   uniqueness constraint ensures TIP URLs are never duplicated, thereby
   preventing possible non-deterministic behaviour. How uniqueness is
   achieved is implementation specific. For example, the Universally
   Unique Identifier (UUID, also known as a Globally Unique Identifier,
   or GUID (see [9])) could be used as part of the <transaction string>.
   Note also that some standard transaction identifiers may define their
   own rules for ensuring global uniqueness (e.g. OSI CCR atomic action
   identifiers).

   Except as otherwise described above, the TIP URL scheme follows the
   rules for reserved characters as defined in [4], and uses escape
   sequences as defined in [4] Section 5.

   Note that the TIP protocol itself does not use the TIP URL scheme (it
   does use the transaction manager address scheme). The TIP URL scheme
   is proposed as a standard way to pass transaction identification



Lyon, et. al.               Standards Track                     [Page 9]

RFC 2371                    TIP Version 3.0                    July 1998


   information through other protocols. e.g. between cooperating
   application processes. The TIP URL may then be used to communicate to
   the local transaction manager the information necessary to associate
   the application with a particular TIP transaction. e.g. to PULL the
   transaction from a remote transaction manager. It is anticipated that
   each TIP implementation will provide some set of APIs for this
   purpose ([5] includes examples of such APIs).

9. States of a Connection

   At any instant, only one party on a connection is allowed to send
   commands, while the other party is only allowed to respond to
   commands that he receives. Throughout this document, the party that
   is allowed to send commands is called "primary"; the other party is
   called "secondary". Initially, the party that initiated the
   connection is primary; however, a few commands cause the roles to
   switch. A connection returns to its original polarity whenever the
   Idle state is reached.

   When multiplexing is being used, these rules apply independently to
   each "virtual" connection, regardless of the polarity of the
   underlying connection (which will be in the Multiplexing state).

   Note that commands may be sent "out of band" by the secondary via the
   use of pipelining. This does not affect the polarity of the
   connection (i.e. the roles of primary and secondary do not switch).
   See section 12 for details.

   In the normal case, TIP connections should only be closed by the
   primary, when in Initial state. It is generally undesirable for a
   connection to be closed by the secondary, although this may be
   necessary in certain error cases.

   At any instant, a connection is in one of the following states. From
   the point of view of the secondary party, the state changes when he
   sends a reply; from the point of view of the primary party, the state
   changes when he receives a reply.

   Initial: The initial connection starts out in the Initial state.
     Upon entry into this state, the party that initiated the connection
     becomes primary, and the other party becomes secondary. There is no
     transaction associated with the connection in this state. From this
     state, the primary can send an IDENTIFY or a TLS command.

   Idle: In this state, the primary and the secondary have agreed on a
     protocol version, and the primary supplied an identifier to the
     secondary party to reconnect after a failure. There is no
     transaction associated with the connection in this state.  Upon



Lyon, et. al.               Standards Track                    [Page 10]

RFC 2371                    TIP Version 3.0                    July 1998


     entry to this state, the party that initiated the connection
     becomes primary, and the other party becomes secondary. From this
     state, the primary can send any of the following commands: BEGIN,
     MULTIPLEX, PUSH, PULL, QUERY and RECONNECT.

   Begun: In this state, a connection is associated with an active
     transaction, which can only be completed by a one-phase protocol.
     A BEGUN response to a BEGIN command places a connection into this
     state. Failure of a connection in Begun state implies that the
     transaction will be aborted. From this state, the primary can send
     an ABORT, or COMMIT command.

   Enlisted: In this state, the connection is associated with an active
     transaction, which can be completed by a one-phase or, two-phase
     protocol. A PUSHED response to a PUSH command, or a PULLED response
     to a PULL command, places the connection into this state. Failure
     of the connection in Enlisted state implies that the transaction
     will be aborted. From this state, the primary can send an ABORT,
     COMMIT, or PREPARE command.

   Prepared: In this state, a connection is associated with a
     transaction that has been prepared. A PREPARED response to a
     PREPARE command, or a RECONNECTED response to a RECONNECT command
     places a connection into this state.  Unlike other states, failure
     of a connection in this state does not cause the transaction to
     automatically abort. From this state, the primary can send an
     ABORT, or COMMIT command.

   Multiplexing: In this state, the connection is being used by a
     multiplexing protocol, which provides its own set of connections.
     In this state, no TIP commands are possible on the connection.  (Of
     course, TIP commands are possible on the connections supplied by
     the multiplexing protocol.) The connection can never leave this
     state.

   Tls: In this state, the connection is being used by the TLS
     protocol, which provides its own secured connection. In this state,
     no TIP commands are possible on the connection. (Of course, TIP
     commands are possible on the connection supplied by the TLS
     protocol.) The connection can never leave this state.

   Error: In this state, a protocol error has occurred, and the
     connection is no longer useful. The connection can never leave this
     state.







Lyon, et. al.               Standards Track                    [Page 11]

RFC 2371                    TIP Version 3.0                    July 1998


10. Protocol Versioning

   This document describes version 3 of the protocol. In order to
   accommodate future versions, the primary party sends a message
   indicating the lowest and the highest version number it understands.
   The secondary responds with the highest version number it
   understands.

   After such an exchange, communication can occur using the smaller of
   the highest version numbers (i.e., the highest version number that
   both understand). This exchange is mandatory and occurs using the
   IDENTIFY command (and IDENTIFIED response).

   If the highest version supported by one party is considered obsolete
   and no longer supported by the other party, no useful communication
   can occur.  In this case, the newer party should merely drop the
   connection.

11. Commands and Responses

   All commands and responses consist of one line of ASCII text, using
   only octets with values in the range 32 through 126 inclusive,
   followed by either a CR (an octet with value 13) or an LR (an octet
   with value 10).  Each line can be split up into one or more "words",
   where successive words are separated by one or more space octets
   (value 32).

   Arbitrary numbers of spaces at the beginning and/or end of each line
   are allowed, and ignored.

   Lines that are empty, or consist entirely of spaces are ignored.
   (One implication of this is that you can terminate lines with both a
   CR and an LF if desired; the LF will be treated as terminating an
   empty line, and ignored.)

   In all cases, the first word of each line indicates the type of
   command or response; all defined commands and responses consist of
   upper-case letters only.

   For some commands and responses, subsequent words convey parameters
   for the command or response; each command and response takes a fixed
   number of parameters.

   All words on a command or response line after (and including) the
   first undefined word are totally ignored. These can be used to pass
   human-readable information for debugging or other purposes.





Lyon, et. al.               Standards Track                    [Page 12]

RFC 2371                    TIP Version 3.0                    July 1998


12. Command Pipelining

   In order to reduce communication latency and improve efficiency, it
   is possible for multiple TIP "lines" (commands or responses) to be
   pipelined (concatenated) together and sent as a single message.
   Lines may also be sent "ahead" (by the secondary, for later procesing
   by the primary). Examples are an ABORT command immediately followed
   by a BEGIN command, or a COMMITTED response immediately followed by a
   PULL command.

   The sending of pipelined lines is an implementation option. Likewise
   which lines are pipelined together. Generally, it must be certain
   that the pipelined line will be valid for the state of the connection
   at the time it is processed by the receiver. It is the responsibility
   of the sender to determine this.

   All implementations must support the receipt of pipelined lines - the
   rules for processing of which are described by the following
   paragraph:

     When the connection state is such that a line should be read
     (either command or response), then that line (when received) is
     processed. No more lines are read from the connection until
     processing again reaches such a state. If a line is received on a
     connection when it is not the turn of the other party to send, that
     line is _not_ rejected. Instead, the line is held and processed
     when the connection state again requires it. The receiving party
     must process lines and issue responses in the order of lines
     received. If a line causes an error the connection enters the Error
     state, and all subsequent lines on the connection are discarded.

13. TIP Commands

   Commands pertain either to connections or transactions. Commands
   which pertain to connections are: IDENTIFY, MULTIPLEX and TLS.
   Commands which pertain to transactions are: ABORT, BEGIN, COMMIT,
   PREPARE, PULL, PUSH, QUERY, and RECONNECT.

   Following is a list of all valid commands, and all possible responses
   to each:

   ABORT

     This command is valid in the Begun, Enlisted, and Prepared states.
     It informs the secondary that the current transaction of the
     connection will abort. Possible responses are:





Lyon, et. al.               Standards Track                    [Page 13]

RFC 2371                    TIP Version 3.0                    July 1998


     ABORTED
       The transaction has aborted; the connection enters Idle state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters the Error state.

   BEGIN

     This command is valid only in the Idle state. It asks the secondary
     to create a new transaction and associate it with the connection.
     The newly created transaction will be completed with a one-phase
     protocol. Possible responses are:

     BEGUN <transaction identifier>
       A new transaction has been successfully begun, and that
       transaction is now the current transaction of the connection.
       The connection enters Begun state.

     NOTBEGUN
       A new transaction could not be begun; the connection remains in
       Idle state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters the Error state.

   COMMIT

     This command is valid in the Begun, Enlisted or Prepared states.
     In the Begun or Enlisted state, it asks the secondary to attempt to
     commit the transaction; in the Prepared state, it informs the
     secondary that the transaction has committed. Note that in the
     Enlisted state this command represents a one-phase protocol, and
     should only be done when the sender has 1) no local recoverable
     resources involved in the transaction, and 2) only one subordinate
     (the sender will not be involved in any transaction recovery
     process). Possible responses are:

     ABORTED
       This response is possible only from the Begun and Enlisted
       states. It indicates that some party has vetoed the commitment of
       the transaction, so it has been aborted instead of committing.
       The connection enters the Idle state.







Lyon, et. al.               Standards Track                    [Page 14]

RFC 2371                    TIP Version 3.0                    July 1998


     COMMITTED
       This response indicates that the transaction has been committed,
       and that the primary no longer has any responsibilities to the
       secondary with respect to the transaction. The connection enters
       the Idle state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters the Error state.

   ERROR

     This command is valid in any state; it informs the secondary that a
     previous response was not recognized or was badly formed.  A
     secondary should not respond to this command. The connection enters
     Error state.

   IDENTIFY  <lowest protocol version>
             <highest protocol version>
             <primary transaction manager address> | "-"
             <secondary transaction manager address>

     This command is valid only in the Initial state. The primary party
     informs the secondary party of: 1) the lowest and highest protocol
     version supported (all versions between the lowest and highest must
     be supported; 2) optionally, an identifier for the primary party at
     which the secondary party can re-establish a connection if ever
     needed (the primary transaction manager address); and 3) an
     identifier which may be used by intermediate proxy servers to
     connect to the required TIP transaction manager (the secondary
     transaction manager address). If a primary transaction manager
     address is not supplied, the secondary party will respond with
     ABORTED or READONLY to any PREPARE commands.  Possible responses
     are:

     IDENTIFIED <protocol version>
       The secondary party has been successfully contacted and has saved
       the primary transaction manager address. The response contains
       the highest protocol version supported by the secondary party.
       All future communication is assumed to take place using the
       smaller of the protocol versions in the IDENTIFY command and the
       IDENTIFIED response. The connection enters the Idle state.

     NEEDTLS
       The secondary party is only willing to communicate over TLS
       secured connections. The connection enters the Tls state, and all
       subsequent communication is as defined by the TLS protocol. This
       protocol will begin with the first octet after the line



Lyon, et. al.               Standards Track                    [Page 15]

RFC 2371                    TIP Version 3.0                    July 1998


       terminator of the IDENTIFY command (for data sent by the primary
       party), and the first byte after the line terminator of the
       NEEDTLS response (for data sent by the secondary party). This
       implies that an implementation must not send both a CR and a LF
       octet after either the IDENTIFY command or the NEEDTLS response,
       lest the LF octet be mistaken for the first byte of the TLS
       protocol. The connection provided by the TLS protocol starts out
       in the Initial state.  After TLS has been negotiated, the primary
       party must resend the IDENTIFY command. If the primary party
       cannot support (or refuses to use) the TLS protocol, it closes
       the connection.

     ERROR
       The command was issued in the wrong state, or was malformed.
       This response also occurs if the secondary party does not support
       any version of the protocol in the range supported by the primary
       party. The connection enters the Error state. The primary party
       should close the connection.

   MULTIPLEX  <protocol-identifier>

     This command is only valid in the Idle state. The command seeks
     agreement to use the connection for a multiplexing protocol that
     will supply a large number of connections on the existing
     connection. The primary suggests a particular multiplexing
     protocol. The secondary party can either accept or reject use of
     this protocol.

     At the present, the only defined protocol identifier is "TMP2.0",
     which refers to the TIP Multiplexing Protocol, version 2.0. See
     Appendix A for details of this protocol. Other protocol identifiers
     may be defined in the future.

     If the MULTIPLEX command is accepted, the specified multiplexing
     protocol will totally control the underlying connection. This
     protocol will begin with the first octet after the line terminator
     of the MULTIPLEX command (for data sent by the initiator), and the
     first byte after the line terminator of the MULTIPLEXING response
     (for data received by the initiator). This implies that an
     implementation must not send both a CR and a LF octet after either
     the MULTIPLEX command or the MULTIPLEXING response, lest the LF
     octet be mistaken for the first byte of the multiplexing protocol.

     Note that when using TMP V2.0, a single TIP command (TMP
     application message) must be wholly contained within a single TMP
     packet (the TMP PUSH flag is not used by TIP). Possible responses
     to the MULTIPLEX command are:




Lyon, et. al.               Standards Track                    [Page 16]

RFC 2371                    TIP Version 3.0                    July 1998


     MULTIPLEXING
       The secondary party agrees to use the specified multiplexing
       protocol. The connection enters the Multiplexing state, and all
       subsequent communication is as defined by that protocol.  All
       connections created by the multiplexing protocol start out in the
       Idle state.

     CANTMULTIPLEX
       The secondary party cannot support (or refuses to use) the
       specified multiplexing protocol. The connection remains in the
       Idle state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters the Error state.

   PREPARE

     This command is valid only in the Enlisted state; it requests the
     secondary to prepare the transaction for commitment (phase one of
     two-phase commit). Possible responses are:

     PREPARED
       The subordinate has prepared the transaction; the connection
       enters PREPARED state.

     ABORTED
       The subordinate has vetoed committing the transaction. The
       connection enters the Idle state.  After this response, the
       superior has no responsibilities to the subordinate with respect
       to the transaction.

     READONLY
       The subordinate no longer cares whether the transaction commits
       or aborts. The connection enters the Idle state. After this
       response, the superior has no responsibilities to the subordinate
       with respect to the transaction.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters the Error state.

   PULL  <superior's transaction identifier>
         <subordinate's transaction identifier>

     This command is only valid in Idle state. This command seeks to
     establish a superior/subordinate relationship in a transaction,
     with the primary party of the connection as the subordinate (i.e.,



Lyon, et. al.               Standards Track                    [Page 17]

RFC 2371                    TIP Version 3.0                    July 1998


     he is pulling a transaction from the secondary party).  Note that
     the entire value of <transaction string> (as defined in the section
     "TIP Uniform Resource Locators") must be specified as the
     transaction identifier. Possible responses are:

     PULLED
       The relationship has been established.  Upon receipt of this
       response, the specified transaction becomes the current
       transaction of the connection, and the connection enters Enlisted
       state. Additionally, the roles of primary and secondary become
       reversed.  (That is, the superior becomes the primary for the
       connection.)

     NOTPULLED
       The relationship has not been established (possibly, because the
       secondary party no longer has the requested transaction).  The
       connection remains in Idle state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters the Error state.

   PUSH <superior's transaction identifier>

     This command is valid only in the Idle state. It seeks to establish
     a superior/subordinate relationship in a transaction with the
     primary as the superior. Note that the entire value of <transaction
     string> (as defined in the section "TIP Uniform Resource Locators")
     must be specified as the transaction identifier. Possible responses
     are:

     PUSHED <subordinate's transaction identifier>
       The relationship has been established, and the identifier by
       which the subordinate knows the transaction is returned. The
       transaction becomes the current transaction for the connection,
       and the connection enters Enlisted state.

     ALREADYPUSHED <subordinate's transaction identifier>
       The relationship has been established, and the identifier by
       which the subordinate knows the transaction is returned.
       However, the subordinate already knows about the transaction, and
       is expecting the two-phase commit protocol to arrive via a
       different connection. In this case, the connection remains in the
       Idle state.

     NOTPUSHED
       The relationship could not be established. The connection remains
       in the Idle state.



Lyon, et. al.               Standards Track                    [Page 18]

RFC 2371                    TIP Version 3.0                    July 1998


     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters Error state.

   QUERY <superior's transaction identifier>

     This command is valid only in the Idle state. A subordinate uses
     this command to determine whether a specific transaction still
     exists at the superior. Possible responses are:

     QUERIEDEXISTS
       The transaction still exists.  The connection remains in the Idle
       state.

     QUERIEDNOTFOUND
       The transaction no longer exists.  The connection remains in the
       Idle state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters Error state.

   RECONNECT <subordinate's transaction identifier>

     This command is valid only in the Idle state. A superior uses the
     command to re-establish a connection for a transaction, when the
     previous connection was lost during Prepared state. Possible
     responses are:

     RECONNECTED
       The subordinate accepts the reconnection. The connection enters
       Prepared state.

     NOTRECONNECTED
       The subordinate no longer knows about the transaction. The
       connection remains in Idle state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters Error state.

   TLS

     This command is valid only in the Initial state. A primary uses
     this command to attempt to establish a secured connection using
     TLS.





Lyon, et. al.               Standards Track                    [Page 19]

RFC 2371                    TIP Version 3.0                    July 1998


     If the TLS command is accepted, the TLS protocol will totally
     control the underlying connection. This protocol will begin with
     the first octet after the line terminator of the TLS command (for
     data sent by the primary), and the first byte after the line
     terminator of the TLSING response (for data received by the
     primary). This implies that an implementation must not send both a
     CR and a LF octet after either the TLS command or the TLSING
     response, lest the LF octet be mistaken for the first byte of the
     TLS protocol.

     Possible responses to the TLS command are:

     TLSING
       The secondary party agrees to use the TLS protocol [3]. The
       connection enters the Tls state, and all subsequent communication
       is as defined by the TLS protocol. The connection provided by the
       TLS protocol starts out in the Initial state.

     CANTTLS
       The secondary party cannot support (or refuses to use) the TLS
       protocol. The connection remains in the Initial state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters the Error state.

14. Error Handling

   If either party receives a line that it cannot understand it closes
   the connection. If either party (either a command or a response),
   receives an ERROR indication or an ERROR response on a connection the
   connection enters the Error state and no further communication is
   possible on that connection. An implementation may decide to close
   the connection. Closing of the connection is treated by the other
   party as a communication failure.

   Receipt of an ERROR indication or an ERROR response indicates that
   the other party believes that you have not properly implemented the
   protocol.

15. Connection Failure and Recovery

   A connection failure may be caused by a communication failure, or by
   any party closing the connection. It is assumed TIP implementations
   will use some private mechanism to detect TIP connection failure
   (e.g. socket keepalive, or a timeout scheme).





Lyon, et. al.               Standards Track                    [Page 20]

RFC 2371                    TIP Version 3.0                    July 1998


   Depending on the state of a connection, transaction managers will
   need to take various actions when a connection fails.

   If the connection fails in Initial or Idle state, the connection does
   not refer to a transaction. No action is necessary.

   If the connection fails in the Multiplexing state, all connections
   provided by the multiplexing protocol are assumed to have failed.
   Each of them will be treated independently.

   If the connection fails in Begun or Enlisted state and COMMIT has
   been sent, then transaction completion has been delegated to the
   subordinate (the superior is not involved); the outcome of the
   transaction is unknown by the superior (it is known at the
   subordinate). The superior uses application-specific means to
   determine the outcome of the transaction (note that transaction
   integrity is not compromised in this case since the superior has no
   recoverable resources involved in the transaction). If the connection
   fails in Begun or Enlisted state and COMMIT has not been sent, the
   transaction will be aborted.

   If the connection fails in Prepared state, then the appropriate
   action is different for the superior and subordinate in the
   transaction.

   If the superior determines that the transaction commits, then it must
   eventually establish a new connection to the subordinate, and send a
   RECONNECT command for the transaction. If it receives a
   NOTRECONNECTED response, it need do nothing else. However, if it
   receives a RECONNECTED response, it must send a COMMIT request and
   receive a COMMITTED response.

   If the superior determines that the transaction aborts, it is allowed
   to (but not required to) establish a new connection and send a
   RECONNECT command for the transaction. If it receives a RECONNECTED
   response, it should send an ABORT command.

   The above definition allows the superior to reestablish the
   connection before it knows the outcome of the transaction, if it
   finds that  convenient. Having succeeded in a RECONNECT command, the
   connection is back in Prepared state, and the superior can send a
   COMMIT or ABORT command as appropriate when it knows the transaction
   outcome.

   Note that it is possible for a RECONNECT command to be received by
   the subordinate before it is aware that the previous connection has
   failed. In this case the subordinate treats the RECONNECT command as




Lyon, et. al.               Standards Track                    [Page 21]

RFC 2371                    TIP Version 3.0                    July 1998


   a failure indication and cleans-up any resources associated with the
   connection, and associates the transaction state with the new
   connection.

   If a subordinate notices a connection failure in Prepared state, then
   it should periodically attempt to create a new connection to the
   superior and send a QUERY command for the transaction. It should
   continue doing this until one of the following two events occurs:

   1. It receives a QUERIEDNOTFOUND response from the superior. In this
      case, the subordinate should abort the transaction.

   2. The superior, on some connection that it initiated, sends a
      RECONNECT command for the transaction to the subordinate. In this
      case, the subordinate can expect to learn the outcome of the
      transaction on this new connection. If this new connection should
      fail before the subordinate learns the outcome of the transaction,
      it should again start sending QUERY commands.

   Note that if a TIP system receives either a QUERY or a RECONNECT
   command, and for some reason is unable to satisfy the request (e.g.
   the necessary recovery information is not currently available), then
   the connection should be dropped.

16. Security Considerations

   This section is meant to inform application developers, transaction
   manager developers, and users of the security implications of TIP as
   described by this document. The discussion does not include
   definitive solutions to the issues described, though it does make
   some suggestions for reducing security risks.

   As with all two phase-commit protocols, any security mechanisms
   applied to the application communication protocol are liable to be
   subverted unless corresponding mechanisms are applied to the
   commitment protocol. For example, any authentication between the
   parties using the application protocol must be supported by security
   of the TIP exchanges to at least the same level of certainty.

16.1. TLS, Mutual Authentication and Authorization

   TLS provides optional client-side authentication, optional server-
   side authentication, and optional packet encryption.

   A TIP implementation may refuse to provide service unless TLS is
   being used. It may refuse to provide service if packet encryption is
   not being used. It may refuse to provide service unless the remote
   party has been authenticated (via TLS).



Lyon, et. al.               Standards Track                    [Page 22]

RFC 2371                    TIP Version 3.0                    July 1998


   A TIP implementation should be willing to be authenticated itself
   (via TLS). This is true regardless of whether the implementation is
   acting as a client or a server.

   Once a remote party has been authenticated, a TIP transaction manager
   may use that remote party's identity to decide what operations to
   allow.

   Whether TLS is to be used on a connection, and if so, how TLS is to
   be used, and what operations are to subsequently be allowed, is
   determined by the security policies of the connecting TIP transaction
   managers towards each other. How these security policies are defined,
   and how a TIP transaction manager learns of them is totally private
   to the implementation and beyond the scope of this document.

16.2. PULL-Based Denial-of-Service Attack

   Assume that a malicious user knows the identity of a transaction that
   is currently active in some transaction manager. If the malefactor
   opens a TIP connection to the transaction manager, sends a PULL
   command, then closes the connection, he can cause that transaction to
   be aborted. This results in a denial of service to the legitimate
   owner of the transaction.

   An implementation may avoid this attack by refusing PULL commands
   unless TLS is being used, the remote party has been authenticated,
   and the remote party is trusted.

16.3. PUSH-Based Denial-of-Service Attack

   When the connection between two transaction managers is closed while
   a transaction is in the Prepared state, each transaction manager
   needs to remember information about the transaction until a
   connection can be re-established.

   If a malicious user exploits this fact to repeatedly create
   transactions, get them into Prepared state and drop the connection,
   he may cause a transaction manager to suffer resource exhaustion,
   thus denying service to all legitimate users of that transaction
   manager.

   An implementation may avoid this attack by refusing PUSH commands
   unless TLS is being used, the remote party has been authenticated,
   and the remote party is trusted.







Lyon, et. al.               Standards Track                    [Page 23]

RFC 2371                    TIP Version 3.0                    July 1998


16.4. Transaction Corruption Attack

   If a subordinate transaction manager has lost its connection for a
   particular prepared transaction, a malicious user can initiate a TIP
   connection to the transaction manager, and send it a RECONNECT
   command followed by either a COMMIT or an ABORT command for the
   transaction. The malicious user could thus cause part of a
   transaction to be committed when it should have been aborted, or vice
   versa.

   An implementation may avoid this attack by recording the
   authenticated identity of its superior in a transaction, and by
   refusing RECONNECT commands unless TLS is being used and the
   authenticated identity of the remote party is the same as the
   identity of the original superior.

16.5. Packet-Sniffing Attacks

   If a malicious user can intercept traffic on a TIP connection, he may
   be able to deduce information useful in planning other attacks.  For
   example, if comment fields include the product name and version
   number of a transaction manager, a malicious user might be able to
   use this information to determine what security bugs exist in the
   implementation.

   An implementation may avoid this attack by always using TLS to
   provide session encryption, and by not putting any personalizing
   information on the TLS/TLSING command/response pair.

16.6. Man-in-the-Middle Attack

   If a malicious user can intercept and alter traffic on a TIP
   connection, he can wreak havoc in a number of ways. For example, he
   could replace a COMMIT command with an ABORT command.

   An implementation may avoid this attack by always using TLS to
   provide session encryption and authentication of the remote party.














Lyon, et. al.               Standards Track                    [Page 24]

RFC 2371                    TIP Version 3.0                    July 1998


17. References

   [1]  Gray, J. and A. Reuter (1993), Transaction Processing: Concepts
        and Techniques.  San Francisco, CA: Morgan Kaufmann Publishers.
        (ISBN 1-55860-190-2).

   [2]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
        2068, January 1997.

   [3]  Dierks, T., et. al., "The TLS Protocol Version 1.0", Work in
        Progress.

   [4]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
        Resource Locators (URL)", RFC 1738, December 1994.

   [5]  Evans, K., Klein, J., and J. Lyon, "Transaction Internet
        Protocol - Requirements and Supplemental Information", RFC 2372,
        July 1998.

   [6]  Moats, R., "URN Syntax", RFC 2141, May 1997.

   [7]  Faltstrom, P., et. al., "Namespace Identifier Requirements for
        URN Services", Work in Progress.

   [8]  Berners-Lee, T., et. at., "Uniform Resource Identifiers (URI):
        Generic Syntax and Semantics", Work in Progress.

   [9]  Leach, P., and R. Salz, "UUIDs and GUIDs", Work in Progress.






















Lyon, et. al.               Standards Track                    [Page 25]

RFC 2371                    TIP Version 3.0                    July 1998


18. Authors' Addresses

   Jim Lyon
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399, USA

   Phone: +1 (206) 936 0867
   Fax:   +1 (206) 936 7329
   EMail: JimLyon@Microsoft.Com


   Keith Evans
   Tandem Computers, Inc.
   5425 Stevens Creek Blvd
   Santa Clara, CA 95051-7200, USA

   Phone: +1 (408) 285 5314
   Fax:   +1 (408) 285 5245
   EMail: Keith.Evans@Tandem.Com


   Johannes Klein
   Tandem Computers Inc.
   10555 Ridgeview Court
   Cupertino, CA 95014-0789, USA

   Phone: +1 (408) 285 0453
   Fax:   +1 (408) 285 9818
   EMail: Johannes.Klein@Tandem.Com

19. Comments

   Please send comments on this document to the authors at
   <JimLyon@Microsoft.Com>, <Keith.Evans@Tandem.Com>,
   <Johannes.Klein@Tandem.Com>, or to the TIP mailing list at
   <Tip@Lists.Tandem.Com>. You can subscribe to the TIP mailing list by
   sending  mail to <Listserv@Lists.Tandem.Com> with the line "subscribe
   tip <full name>" somewhere in the body of the message.












Lyon, et. al.               Standards Track                    [Page 26]

RFC 2371                    TIP Version 3.0                    July 1998


Appendix A. The TIP Multiplexing Protocol Version 2.0.

   This appendix describes version 2.0 of the TIP Multiplexing Protocol
   (TMP). TMP is intended solely for use with the TIP protocol, and
   forms part of the TIP protocol specification (although its
   implementation is optional). TMP V2.0 is the only multiplexing
   protocol supported by TIP V3.0.

Abstract

   TMP provides a simple mechanism for creating multiple lightweight
   connections over a single TCP connection. Several such lightweight
   connections can be active simultaneously. TMP provides a byte
   oriented service, but allows message boundaries to be marked.

A.1. Introduction

   There are several protocols in widespread use on the Internet which
   create a single TCP connection for each transaction. Unfortunately,
   because these transactions are short lived, the cost of setting up
   and tearing down these TCP connections becomes significant, both in
   terms of resources used and in the delays associated with TCP's
   congestion control mechanisms.

   The TIP Multiplexing Protocol (TMP) is a simple protocol running on
   top of TCP that can be used to create multiple lightweight
   connections over a single transport connection. TMP therefore
   provides for more efficient use of TCP connections. Data from several
   different TMP connections can be interleaved, and both message
   boundaries and end of stream markers can be provided.

   Because TMP runs on top of a reliable byte ordered transport service
   it can avoid most of the extra work TCP must go through in order to
   ensure reliability. For example, TMP connections do not need to be
   confirmed, so there is no need to wait for handshaking to complete
   before data can be sent.

   Note: TMP is not intended as a generalized multiplexing protocol. If
   you are designing a different protocol that needs multiplexing, TMP
   may or may not be appropriate. Protocols with large messages can
   exceed the buffering capabilities of the receiver, and under certain
   conditions this can cause deadlock. TMP when used with TIP does not
   suffer from this problem since TIP is a request-response protocol,
   and all messages are short.







Lyon, et. al.               Standards Track                    [Page 27]

RFC 2371                    TIP Version 3.0                    July 1998


A.2. Protocol Model

   The basic protocol model is that of multiple lightweight connections
   operating over a reliable stream of bytes. The party which initiated
   the connection is referred to as the primary, and the party which
   accepted the connection is referred to as the secondary.

   Connections may be unidirectional or bi-directional; each end of a
   bi-directional connection may be closed separately. Connections may
   be closed normally, or reset to indicate an abortive release.
   Aborting a connection closes both data streams.

   Once a connection has been opened, applications can send messages
   over it, and signal the end of application level messages.
   Application messages are encapsulated in TMP packets and transferred
   over the byte stream. A single TIP command (TMP application message)
   must be wholly contained within a single TMP packet.

A.3. TMP Packet Format

   A TMP packet consists of a 64 bit header followed by zero or more
   octets of data. The header contains three fields; a flag byte, the
   connection identifier, and the packet length. Both integers, the
   connection identifier and the packet length must be sent in network
   byte order.

    FLAGS
   +--------+--------+--------+--------+
   |SFPR0000| Connection ID            |
   +--------+--------+--------+--------+
   |        | Length                   |
   +--------+--------+--------+--------+

A.3.1. Flag Details

   +-------+-----------+-----------------------------------------+
   | Name  | Mask      | Description                             |
   +-------+-----------+ ----------------------------------------+
   | SYN   | 1xxx|0000 | Open a new connection                   |
   | FIN   | x1xx|0000 | Close an existing connection            |
   | PUSH  | xx1x|0000 | Mark application level message boundary |
   | RESET | xxx1|0000 | Abort the connection                    |
   +-------+-----------+-----------------------------------------+








Lyon, et. al.               Standards Track                    [Page 28]

RFC 2371                    TIP Version 3.0                    July 1998


A.4. Connection Identifiers

   Each TMP connection is identified by a 24 bit integer. TMP
   connections created by the party which initiated the underlying TCP
   connection must have even identifiers; those created by the other
   party must have odd identifiers.

A.5. TMP Connection States

   TMP connections can exist in several different states; Closed,
   OpenWrite, OpenSynRead, OpenSynReset, OpenReadWrite, CloseWrite, and
   CloseRead. A connection can change its state in response to receiving
   a packet with the SYN, FIN, or RESET bits set, or in response to an
   API call by the application. The available API calls are open, close,
   and abort.

   The meaning of most states is obvious (e.g. OpenWrite means that a
   connection has been opened for writing). The meaning of the states
   OpenSynRead and OpenResetRead need more explanation.

   In the OpenSynRead state a primary opened and immediately closed the
   output data stream of a connection, and is now waiting for a SYN
   response from the secondary to open the input data stream for
   reading.

   In the OpenResetRead state a primary opened and immediately aborted a
   connection, and is now waiting for a SYN response from the secondary
   to finally close the connection.

A.6. Event Priorities and State Transitions

   The state table shown below describes the actions and state
   transitions that occur in response to a given event. The events
   accepted by each state are listed in priority order with highest
   priority first. If multiple events are present in a message, those
   events matching the list are processed. If multiple events match, the
   event with the highest priority is accepted and processed first.  Any
   remaining events are processed in the resultant successor state.

   For example, if a TMP connection at the secondary is in the Closed
   state, and the secondary receives a packet containing a SYN event, a
   FIN event and an input data event (i.e. DATA-IN), the secondary first
   accepts the SYN event (because it is the only match in Closed state).
   The secondary accepts the connection, sends a SYN event and enters
   the ReadWrite state. The SYN event is removed from the list of
   pending events. The remaining events are FIN and DATA-IN. In the
   ReadWrite state the secondary reads the input data (i.e. the DATA-IN
   event is processed first because it has higher priority than the FIN



Lyon, et. al.               Standards Track                    [Page 29]

RFC 2371                    TIP Version 3.0                    July 1998


   event). Once the data has been read and the DATA-IN event has been
   removed from the list of pending events, the FIN event is processed
   and the secondary enters the CloseWrite state.

   If the secondary receives a packet containing a SYN event, and is for
   some reason unable to accept the connection (e.g. insufficient
   resources), it should reject the request by sending a SYN event
   followed by a RESET event. Note that both events can be sent as part
   of the same TMP packet.

   If either party receives a TMP packet that it does not understand, or
   an event in an incorrect state, it closes the TCP connection.

   +==============+=========+==========+==============+
   | Entry State  | Event   | Action   | Exit State   |
   +==============+=========+==========+==============+
   | Closed       | SYN     | SYN      | ReadWrite    |
   |              | OPEN    | SYN      | OpenWrite    |
   +--------------+---------+----------+--------------+
   | OpenWrite    | SYN     | Accept   | ReadWrite    |
   |              | WRITE   | DATA-OUT | OpenWrite    |
   |              | CLOSE   | FIN      | OpenSynRead  |
   |              | ABORT   | RESET    | OpenSynReset |
   +--------------+---------+----------+--------------+
   | OpenSynRead  | SYN     | Accept   | CloseRead    |
   +--------------+---------+----------+--------------+
   | OpenSynReset | SYN     | Accept   | Closed       |
   +--------------+---------+----------+--------------+
   | ReadWrite    | DATA-IN | Accept   | ReadWrite    |
   |              | FIN     | Accept   | CloseWrite   |
   |              | RESET   | Accept   | Closed       |
   |              | WRITE   | DATA-OUT | ReadWrite    |
   |              | CLOSE   | FIN      | CloseRead    |
   |              | ABORT   | RESET    | Closed       |
   +--------------+---------+----------+--------------+
   | CloseWrite   | RESET   | Accept   | Closed       |
   |              | WRITE   | DATA-OUT | CloseWrite   |
   |              | CLOSE   | FIN      | Closed       |
   |              | ABORT   | RESET    | Closed       |
   +--------------+---------+----------+--------------+
   | CloseRead    | DATA-IN | Accept   | CloseRead    |
   |              | FIN     | Accept   | Closed       |
   |              | RESET   | Accept   | Closed       |
   |              | ABORT   | RESET    | Closed       |
   +--------------+---------+----------+--------------+

        TMP Event Priorities and State Transitions




Lyon, et. al.               Standards Track                    [Page 30]

RFC 2371                    TIP Version 3.0                    July 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.
























Lyon, et. al.               Standards Track                    [Page 31]