File: rfc1698.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 (1627 lines) | stat: -rw-r--r-- 67,433 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
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






Network Working Group                                         P. Furniss
Request for Comments: 1698                                    Consultant
Category: Informational                                     October 1994


                  Octet Sequences for Upper-Layer OSI
              to Support Basic Communications Applications

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document states particular octet sequences that comprise the OSI
   upper-layer protocols (Session, Presentation and ACSE) when used to
   support applications with "basic communications requirements". These
   include OSI application protocols such as X.400 P7 and Directory
   Access Protocol, and "migrant" protocols, originally defined for use
   over other transports.

   As well as the octet sequences which are the supporting layer headers
   (and trailers) around the application data, this document includes
   some tutorial material on the OSI upper layers.

   An implementation that sends the octet sequences given here, and
   interprets the equivalent protocol received, will be able to
   interwork with an implementation based on the base standard, when
   both are being used to support an appropriate application protocol.

Table of Contents

   1. Introduction ...................................................2
   2. General ........................................................3
    2.1 Subdivisions of "basic communication applications" ...........3
    2.2 Conformance and interworking .................................5
    2.3 Relationship to other documents ..............................5
   3. Contexts and titles ............................................6
    3.1 The concepts of abstract and transfer syntax .................6
    3.2 Use of presentation context by cookbook applications..........7
    3.3 Processing Presentation-context-definition-list ..............8
    3.4 Application context ..........................................9
    3.5 APtitles and AEqualifiers ....................................9
   4. What has to be sent and received ..............................10
    4.1 Sequence of OSI protocol data units used ....................10
    4.2 Which OSI fields are used ...................................12



Furniss                                                         [Page 1]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


    4.3 Encoding methods and length fields ..........................14
    4.3.1 Session items .............................................14
    4.3.2 ASN.1/BER items (Presentation and ACSE) ...................14
    4.4 BER Encoding of values for primitive datatypes ..............15
    4.5 Unnecessary constructed encodings ...........................16
   5. Notation ......................................................16
   6. Octet sequences ...............................................17
    6.1 Connection request message ..................................17
    6.2 Successful reply to connection setup ........................20
    6.3 Connection rejection ........................................22
    6.4 Data-phase TSDU .............................................23
    6.5 Closedown  - release request ................................24
    6.6 Closedown - release response ................................25
    6.7 Deliberate abort ............................................25
    6.8 Provider abort ..............................................27
    6.9 Abort accept ................................................27
   7. References ....................................................27
   8. Other notes ...................................................28
   9. Security Considerations .......................................29
   10. Author's Address .............................................29

1.  Introduction

   The upper-layer protocols of the OSI model are large and complex,
   mostly because the protocols they describe are rich in function and
   options. However, for support of most applications, only a limited
   portion of the function is needed. An implementation that is not
   intended to be a completely general platform does not need to
   implement all the features. Further, it need not reflect the
   structuring of the OSI specifications - the layer of the OSI model
   are purely abstract.

   This document presents the protocol elements required by the OSI
   upper layers when supporting a connection-oriented application with
   only basic communication requirements - that is to create a
   connection, optionally negotiate the data representation,
   send/receive data, close a connection and abort a connection.
   Optionally, data may be sent on the connection establishment, closing
   and abort messages.

   In this document, the protocol elements needed are given in terms of
   the octet sequences that comprise the 'envelope' around the
   application data. The envelope and its enclosing data form a
   Transport Service Data Unit (TSDU) that can be passed via the OSI
   Transport Service [ISO8072] (which in turn may be supported as
   specified in [RFC1006] or any class of the OSI Transport Protocol
   [ISO8073]).




Furniss                                                         [Page 2]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   The octet sequences to be sent and the description of the alternative
   forms that may be received are equivalent to an informal re-
   specification of the relevant parts of the upper-layer protocols.
   The "relevant parts" are determined by the requirements of the
   supported applications (this is a reflexive definition! - if
   application Z needs something that is not here, it is not supported).
   The formal specifications remain the base standards, the appropriate
   profiles and the requirements of the application. However, an
   implementation based on this document will be able to interwork with
   an implementation based directly on the full standards when both are
   supporting a basic communication application. The "full"
   implementation will exhibit only part of its potential behaviour,
   since the application will only invoke part.

   In addition to the octet sequences, the document includes some
   tutorial material.

2.  General

2.1 Subdivisions of "basic communication applications"

   Distinctions can be made within the "basic communication
   applications", as defined above, based on how much use they make of
   the OSI upper-layer services, and thus how much of the protocol
   described in this memo will be used to support a particular
   application. One distinction is:

      a) whether application data is sent on the connection
         establishment, close and abort, or only during "date phase"
         on an established connection; OR

      b) whether the application data is of only one kind (abstract
         syntax) and one format (transfer syntax) or more than one
         (i.e., how much use is made of the Presentation layer syntax
         negotiation and identification features)

   Further distinctions are possible, but in this memo, elements of
   protocol needed (or not needed) by four groups of "basic
   communications application" are identified. All groups have "basic
   communications requirements" in requiring only connection, data
   transfer and (perhaps) orderly release of connection. The four groups
   are:

      Group I: applications which send data only on an established
      connection, and use a single abstract and transfer syntax.






Furniss                                                         [Page 3]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


      Group II: applications which send data on connection
      establishment and release and use a single abstract and transfer
      syntax.

      Group III: applications that send data of only one kind (one
      abstract syntax) on the connection, but which have more than one
      format (transfer syntax) specified (they use the Presentation
      context negotiation facility).

      Group IV: applications that will send data of several kinds on the
      connection (and which much therefore distinguish on each write
      which kind is being sent).

   Group III applications are equivalent to Group I (or possibly Group
   II) after the establishment exchange has negotiated the particular
   transfer syntax that will be used on the connection.

   Possible examples of the Groups are:

      Group I: Application protocols designed for use over transport-
      level protocols. Typically these are non-OSI protocols "migrated"
      to an OSI environment. X Window System protocol is an example.

      Group II: OSI-originated protocols with simple requirements,
      including many of the ROSE-based ones, such as Directory Access
      Protocol.

      Group III: Protocols that can be treated as Group I, but for
      which more than one encoding of the data is known, such as a
      standardised one and a system-specific one - all implementations
      understand the standard encoding, but Presentation layer
      negotiation allows like-implementations to use their internal
      encoding for transfer, without loss of general interworking. The
      same could apply to OSI protocols.

      Group IV: OSI protocols with multiple abstract syntaxes (but with
      each individual message from a single abstract syntax) that do
      not use any of the special Session functional units - X.400 P7 is
      an example.

   Some of the OSI protocols that are not included are those that use
   more than one abstract syntax in a single message (such as FTAM or
   Transaction Processing) or use Session functional units (RTSE-based
   protocols, Virtual Terminal).







Furniss                                                         [Page 4]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


2.2 Conformance and interworking

   The protocol elements specified in this memo correspond to the kernel
   functional units of Session, Presentation and ACSE, and the duplex
   functional unit of Session.

   The octet sequences given below are derived from the specifications
   in the International Standards for the protocols Session [ISO8327],
   Presentation [ISO8822] and ACSE [ISO8650]. The intention of this memo
   is to summarise those specifications, as applicable to the supported
   application groups, so that an implementation could be developed
   without direct reference to the original standards, but capable of
   interworking with implementations that had made direct reference. The
   OSI standards (especially Presentation) allow considerable
   flexibility in the encoding of the protocol data units. Accordingly,
   this memo defines particular octet sequences to be sent, and
   describes the variations that can be expected in data received from
   an implementation based directly on the OSI standards, rather than on
   this cookbook. It is intended that an implementation that sends these
   sequences and that is capable of interpreting the variations
   described will be fully able to interwork with an implementation
   based directly on the OSI standards. An implementation that is only
   capable of interpreting the octet sequences specified in this memo
   for transmission may not be able to interwork with standards-based
   implementations.

   The intent is to be able to interwork with conformant implementations
   in support of the relevant application (or group of applications).
   Some of the OSI standards have conformance requirements that go
   beyond that necessary for successful interworking, including
   detection of invalid protocol. Tests for conformance sometimes go
   beyond the strict conformance requirements of the standard.
   Consequently an implementation based on this memo may or may not be
   able to formally claim conformance to the International Standard. It
   may be able to legitimately claim conformance, but fail a conformance
   test, if the test is over-specified. (Efforts are being made to
   correct this, but in the meantime, the target is interworking with
   conformant implementations.)

2.3 Relationship to other documents

   The flexibility allowed in the Session, Presentation and ACSE
   standards is restricted in the Common Upper-Layer Requirements Part 1
   [CULR-1]).  This is a proposed International Standardised Profile
   (pdISP 11188-1) that can be assumed to be obeyed by most
   implementations. This memo applies the restrictions of CULR-1,
   especially where these concern maximum sizes of fields and the
   like.Points where advantage is taken of a CULR-1 limitation are



Furniss                                                         [Page 5]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   noted.

   Additional parts of CULR are under development. Part 3 [CULR-3]
   covers the protocol elements needed for "basic communications
   applications", and is being developed in (informal) liaison with this
   memo. CULR-3 is presented as a normal profile, largely consisting of
   prescribed answers to the questions in the PICS (Protocol
   Implementation Conformance Statement) of the three protocols.  CULR-3
   does not make the distinction between the four Groups.  An
   implementation of this memo (at least if it supported Group IV) would
   be able to claim conformance to CULR-3, with the possible exception
   of any more-than-interworking conformance requirements inherited by
   CULR-3 from the base standards.

   An extension [XTI/mOSI] to the X/Open Transport Interface [XTI] is
   shortly to be published as a preliminary specification. This defines
   an API to the OSI upper-layers, again as appropriate to a basic
   communications application. XTI/mOSI would be usable as an interface
   to support applications in groups I, II and III, and possibly group
   IV.

3.  Contexts and titles

3.1 The concepts of abstract and transfer syntax

   OSI includes the concepts of "abstract syntax" and "transfer syntax".
   These are terms for the content (abstract syntax) and format "on-
   the-line" (transfer syntax) of the protocol elements. The combination
   of an abstract syntax and transfer syntax is called a presentation
   context.

   Application protocols devised explicitly under OSI auspices have used
   ASN.1 for the definition of the abstract syntax, and nearly all use
   the Basic Encoding Rules applied to the ASN.1 to define the transfer
   syntax. However, there is no such requirement in OSI in general or in
   OSI Presentation, and still less is there any requirement to change
   the representation of existing application protocols to ASN.1 (for
   their definition) or BER (for their transmission). It is not
   generally realised (even in OSI circles) that all communicating
   applications, in all environments, are using some form of these,
   although under different names and without the explicit
   identification that the OSI Presentation provides. OSI separates the
   identification of the content and format of the data from the
   addressing.

   Formal specifications of non-OSI application protocols (such as
   TELNET, FTP, X Windows System) generally do not use ASN.1, but will
   invariably be found to define abstract and transfer syntaxes.  For a



Furniss                                                         [Page 6]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   less formalised protocol used between similar systems, the abstract
   syntax may be defined simply in programming language structures, and
   the transfer syntax determined by how some compiler represents this
   in memory.

   The OSI Presentation protocol requires that "names" be assigned to
   the abstract and transfer syntaxes of the application data that is
   carried.  The names are always object identifiers ("oid"): globally
   unique names assigned hierarchically. Presentation supports the
   negotiation of a transfer syntax for a particular abstract syntax -
   several can be offered and one selected.

   This transfer syntax negotiation facility may be especially useful
   for non-ASN.1 syntaxes where there is more than one representation
   available (perhaps differing in byte-ordering or character code). In
   such a case, on the connection establishment, all of the transfer
   syntaxes supported by the initiator are offered, and any one of these
   accepted by the responder, at its own choice. If the two systems
   share some "native" format they can negotiate that, avoiding
   transformation into and out of a more general format that is used for
   interworking with unlike systems. The same applies to an ASN.1-
   defined abstract syntax, but in practice non-BER encodings of ASN.1
   are rare.

3.2 Use of presentation context by cookbook applications

   An application protocol not originally specified with OSI
   Presentation in mind (a "migrant" protocol) will not normally need to
   identify the abstract and transfer syntaxes being used - they are
   known by some other means (effectively inferred from the addressing).
   A generic (anonymous, if you like) name for both syntaxes can be used
   and [CULR-3] defines object identifiers for "anonymous" abstract and
   transfer syntax names (currently called "default", but this is
   expected to change).

   In some cases object identifier names will be assigned for the
   syntaxes of a migrant application protocol. If these exist, they
   should be used.  However, since the processing required will be the
   same, it will be legitimate to offer both the generic and specific
   names, with the responder accepting the specific (if it knew it) and
   the generic if the specific were not known - this will provide a
   migration option if names are assigned to the syntaxes after
   implementations are deployed using the generic names.

   For abstract syntaxes defined in ASN.1 object identifier names will
   have been assigned to the abstract syntax with the specification.
   This name MUST be used to identify the abstract syntax. The transfer
   syntax will most often be the Basic Encoding Rules (BER) object id,



Furniss                                                         [Page 7]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   but alternatives (e.g., Packed Encoding Rules) are possible.

   For group III and group IV applications, specific object identifier
   names must be used for all the abstract and transfer syntaxes. If
   these names are not assigned with the specification (e.g., if the
   specification not in ASN.1) they can be assigned by whoever needs
   them - ideally the "owner" of the syntax specification.

3.3 Processing Presentation-context-definition-list

   In Presentation context negotiation on connection establishment the
   initiator sends a list (the presentation context definition list) of
   the abstract syntaxes it intends to use, each with a list of transfer
   syntaxes. Each presentation context also has an integer identifier.
   To build the reply, a responder has to examine this list and work out
   which of the offered presentation contexts will be accepted and which
   (single) transfer syntax for each. The responder sends back the reply
   field, the Presentation-context-definition-result-list, in the accept
   message. The result list contains the same number of result items as
   the definition-list proposed presentation-contexts. They are matched
   by position, not by the identifiers (which are not present in the
   result- list). An acceptance also includes the transfer syntax
   accepted (as there can be several offered). This can be copied from
   the definition list.

   For the group I, group II and group III cases,  only the ACSE and one
   application-data P-context will be used and all other contexts
   rejected. For the group IV case, several presentation contexts will
   be accepted.

   However, even for group I applications there may be synonyms for an
   application-data Presentation-context. Unknown synonyms are rejected.
   The reply shown in 6.2 includes a rejection (It can therefore not be
   the reply to the connection request shown in 6.1, since that has only
   two items in the definition list.)

   In all cases, the connection responder must identify and keep the
   presentation context identifiers (called pcid's here) for all the
   accepted presentation contexts. These are integers (odd integers, in
   this case). CULR-1 limits them to no greater than 32767, but they
   will usually be <= 255 (so taking up one octet).

   A presentation context is sometimes used (i.e., data is sent using
   it) before the negotiation is complete. As will be seen in section 6,
   in these cases, the transfer syntax name sometimes appears with the
   integer identifier.





Furniss                                                         [Page 8]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


3.4 Application context

   The Association Control Service Element also exchanges the name
   (another Object Identifier) of the application context, which
   identifies what the communication is all about, again independently
   of the naming and addressing.  As for the syntaxes, although some
   name must be present in the protocol, a generic name can be used for
   applications that do not have a specific name assigned. (This will
   almost certainly be a group I application - if a specific name is
   assigned, it must be used.) The only negotiation allowed is that the
   reply may be different from that sent by the initiator. CULR-3
   provides a generic application context name (i.e., assigns an object
   identifier).

3.5 APtitles and AEqualifiers

   In addition to the addressing constructs (transport address and
   possibly session and presentation selectors), the communicating
   application entities have names - Application-Entity titles
   (AEtitle).  These are carried by ACSE as two fields -the
   Application-process titles (APtitle) and the Application-entity
   qualifier (AEqualifier). The AEtitle is compound, and the APtitle
   consists of all but the last element, which is the AEqualifier. (This
   explanation can be run backwards). There are two non-equivalent
   forms. AP-titles and AE-titles can be Directory Name or an Object
   Identifier. AE-qualifiers can be Relative Distinguished Name (RDN) or
   an integer - the forms must match, since the AE-qualifier is the last
   component of the AP-title. In practice, the Directory form is likely
   to be the only one seen for a while.

   Use of the these names is rather variable. This cookbook proposes
   that implementations should be able to handle any value for the
   partner's names, and set (as initiator) its own names. This is
   primarily to facilitate OSI:non-OSI relaying (e.g., X/osi:X/tcp),
   allowing the names of the end-system to be carried to the relay,
   where they can be converted into hostnames, and the lower-layer
   address determined. OSI assumes that name-to-address lookup is
   possible (via the Directory or other means), but does not assume
   address-to-name will work. Thus the calling AE-title is needed if the
   responder is to know who the initiator is. However, most protocols
   work perfectly well without these names being included.

   As for their encoding, a RDN will almost always be a single attribute
   value assertion, with the attribute defined either by the Directory
   standard [ISO9594 = X.500], or in [Internet/Cosine Schema] [RFC1274].
   Using the notation defined below, the encoding of an RDN using a
   Directory-defined standard attribute is:




Furniss                                                         [Page 9]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   31  80  {1         - RDN, [SET OF]
   30  80  {2         - AttributeValueAssertion, [SEQUENCE]
   06  03  5504yy     -- OID identifying an attribute named in
                      -- the Directory standard
                      -- which one is determined by yy
   13  La  xxxxxx     -- [Printable string]
                      -- could be T61 string, with tag 14
   00  00  }2         - end of AVA
   00  00  }1         - end of RDN

   The most likely attributes for an RDN have the following hex values
   for yy.

        CommonName               03
        Country                  06
        Locality                 07
        State/Province           08
        Organisation             0A
        OrganisationUnit         0B

   For non-Directory attributes, the object id name must be substituted
   (thus changing the immediately preceding length)

   If there are multiple attribute value assertions in the RDN, the
   group between {2 and 2} is repeated (with different attributes).
   Order is not significant.

   The encoding of a [Directory] Name for the AP-titles is the RDNs
   (high- order first) within

   30  80  {1        - [SEQUENCE] Name
    -- put the RDN encodings here
   00  00  }1

   An Object Identifier AP-title is encoded as a primitive (see below),
   with the "universal" tag for an object identifier, which is 6. The
   integer AE-qualifier uses the universal tag for an integer, which is
   2.

4.  What has to be sent and received

4.1 Sequence of OSI protocol data units used

   OSI defines its facilities in terms of services but these are
   abstract constructs (they do not have to correspond to procedure
   calls) - the significant thing is the transmission of the resulting
   protocol data unit (PDU). The PDU at each layer carries (as user
   data) the PDU of the layer above. The different layers follow



Furniss                                                        [Page 10]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   different conventions for naming the pdus. This section gives an
   overview of the sequence of PDUs exchanged - the details of these are
   given in section 6.

   The requirements of the application are to create a connection
   (strictly an association for the application-layer in OSI, but called
   a connection here), to send and receive data and to close the
   connection.  The PDUs used are thus:

   To create connection:

        First create transport-level connection

        Initiator sends the message defined in 6.1, which is Session
        CONNECT carrying Presentation CONNECT request [CP] carrying
        ACSE A-ASSOCIATE request [AARQ] optionally carrying application
        data.

        Responder replies with the message defined in 6.2, which is
        Session ACCEPT carrying Presentation CONNECT response [CPA]
        carrying ACSE response [AARE] optionally carrying application
        data.

     -  If the responder rejects the attempt, the reply will be Session
        REJECT. This is defined in 6.3, where the REJECT carries no
        user data. A received REJECT may carry Presentation, ACSE and
        application data, although 6.3 shows only how to reject at
        Session level..

   To send/receive data on an connection

        send the message defined in 6.4, which is an empty Session
        GIVE-TOKEN followed by Session S-DATA carrying Presentation P-
        DATA [TD] containing the application data (The GIVE-TOKEN is
        just two octets required by Session for some backwards
        compatibility.)

   To close connection gracefully

        One side sends the message defined in 6.5, which is Session
        FINISH carrying P-RELEASE request carrying A-RELEASE request
        [RLRQ] optionally carrying application data (This side may now
        receive, but not send data.)

        The other side replies with the message defined in 6.6, which
        is Session DISCONNECT carrying P-RELEASE response carrying A-
        RELEASE response [RLRE] optionally carrying application data




Furniss                                                        [Page 11]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


        First side disconnects transport connection on receiving the
        reply

   To close connection abruptly but also send application data

        Send the message defined in 6.7, which is Session ABORT
        carrying Presentation U-ABORT [ARU] carry ACSE U-ABORT [ABRT]
        carrying application data (delivery not guaranteed)

        On receiving Session ABORT, disconnect transport

   To close connection abruptly

     -  Either send the message defined in 6.8, which is Session ABORT
        carrying nothing;

        Or, just disconnect at transport level

   A group I application is assumed (by definition) not to send data on
   the establishment and release exchanges, a group II application will.

   It would be possible to use the abort-with-data facility with a group
   I to send a (possibly non-standardised) error message for diagnostic
   purposes.

   A special rule is used if a release collision occurs (i.e., FINISH+P-
   RELEASE+RLRQ received after sending the same): the side that
   initiated the original upper-layer connection waits and the other
   side replies with the DISCONNECT etc.

4.2 Which OSI fields are used

   There are a number of fields (parameters) in the pdus involved. These
   can be categorised by what is needed to support applications (of a
   particular Group) in general - a field may  be "useful", "send-only",
   "fixed", "fixed with default", "internal" or "not important". Even
   those that are not important may be received from another
   implementation, but since the application has no use for them, they
   can be ignored. If an implementation is intended to support only a
   particular application, it may be able to downgrade the "useful" to
   "not important".

   The text below describes the processing that is required for each
   category and which fields are in each category.

   "Useful" - when sending, an implementation of general use should be
   able to set any (legal) value of these fields (via the upper
   interface from the application or via some configuration or lookup



Furniss                                                        [Page 12]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   mechanism) and SHOULD pass received values for the Calling values to
   the application (for specific applications, these fields may be
   either required or unnecessary.)

    AARQ:

      Called application-process title
      Called application-entity qualifier
      Calling application-process title
      Calling application-entity qualifier

   "Send-only" - to interwork, the implementation must be able to set
   any value of these, but can ignore any received value. Both are octet
   strings.

      Presentation selector (up to 4 octets, limited by CULR-1)
      Session selector (up to 16 octets, limited by base standard)

   "Fixed" (constant for all applications)

      abstract and transfer syntax identifiers for presentation context
      for ACSE Version numbers - 2 for session, 1 for Presentation
      and ACSE

   "Fixed with default" - the value is specific to the application. For
   non-ASN.1 abstract syntaxes (group I or group II only) applications,
   the anonymous values assigned by the OIW minimal OSI profile [CULR-3]
   can be used. The CULR-3 default application context can be used where
   a proper context name is neither available nor needed.

      Application context
                       CULR-3  default is {1 0 11188 3 3}
      Abstract syntax identifier for application data
                       CULR-3 anonymous name is {1 0 11188 3 1 1}
      Transfer syntax identifier for application data
                       CULR-3 anonymous name is {1 0 11188 3 2 1}

   "Internal" - an arbitrary value can be sent; a received value must be
   stored for use in sending.

      Presentation context identifiers for ACSE and the application
      data (always odd integers)

   "Not important" - for interworking, any legal received value for the
   other fields must be received (i.e., the pdu is parsed successfully),
   but can then be ignored. There is no requirement (in this cookbook)
   to check the existence, value or internal format of these fields.




Furniss                                                        [Page 13]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


      All other fields (which includes a large number of session
      fields)

4.3 Encoding methods and length fields

   Both Session and ASN.1/BER [ISO8824, ISO8825] use a type-length-value
   structure for their encodings, but different ones. Presentation
   protocol and ACSE protocol use the ASN.1/BER encoding and
   consequently a Presentation PDU containing an ACSE PDU can be
   constructed or parsed as if it were a single structure.

   All the protocols contain pdu fields with a compound structure. If
   one of these is being ignored it may be necessary (for BER, not
   session) to determine the lengths of its components to find the
   length of the ignored field.

   Many of the lengths in the specification below will vary, dependent
   on the values of the fields.

4.3.1 Session items

   The type field of a session item is always a single octet.

   For session items, given a particular length, there is no
   flexibility:

      If the length is less than 255, represent as one octet

      If the length is greater, represent as three octets, first is
      0xFF, next two are the length, high-order octet first.

   (Some "real" implementations are known to use the second encoding in
   all cases. This is wrong, but should only concern conformance
   testers.)

4.3.2 ASN.1/BER items (Presentation and ACSE)

   The type field for ASN.1-BER is the tag. Although it is possible for
   large tags (>30) to be multi-octet, there are no large tags in the
   protocols involved in this memo. Bit 6 (0x20) of the tag octet is 1
   if the item is constructed (i.e., the value is itself one or more
   ASN.1 BER items) or 0 if it is primitive.

   There is considerable flexibility, at senders option, in how lengths
   are represented in BER. There are three forms: short, long and
   indefinite.

      Short (usable only if the length is less than 127) : one octet



Furniss                                                        [Page 14]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


      Long (usable for *any* length) : first octet has the top bit set,
      the rest is a count of how many octets are holding the length
      value; that many subsequent octets hold the length. A long length
      may use more than the minimum number of octets (so 0x8400000001
      is a valid representation of length 1)

      Indefinite (usable only for the length of a compound field) : the
      single octet is 0x80, then one or more items (their tag-length-
      values) and finally two octets of 0x00 (equivalent to tag and
      length of zero).

   To be able to interwork generally, an implementation must be able to
   handle any of these forms when receiving.

   The encodings specified in the octet sequences below use indefinite
   length for all constructed items with a few exceptions. This slightly
   increases the number of octets sent, but means that the length of a
   varying field (e.g., user data, or a varying object identifier)
   affects only the length of the item itself, and not the enclosing
   lengths. It is thus possible to use the octet sequences as templates
   interspersed by the varying fields.

   It is important to note that this choice of indefinite (which is
   equivalent to the "Canonical Encoding Rules" variant of BER) applies
   only to the Presentation and ACSE protocols themselves. It does not
   apply to ASN.1/BER encoded application data. The processing required
   of application data may suggest alternative "best" options.

4.4 BER Encoding of values for primitive datatypes

   The following ASN.1 primitive datatypes are used in the thinosi
   stack.

   Integers are encoded in twos-complement, high-order first. Unlike
   lengths, they must be encoded in the minimum number of octets (no
   leading 00 padding).

   Object Identifiers have a rather peculiar, but compressed encoding:

      Combine the first two integers of the OID into one element by
      multiplying the first (always 0, 1 or 2) by 40, and add the
      second.

      Each element (that one, and each subsequent integer in the OID
      taken on its own), is a taken as a binary number and divided into
      7-bit "bytes". This is apportioned into bits 1-7 of the minimum
      number of octets. Bit 8 is one for all octets of the sequence
      except the last. (This means that elements of less than 127 are



Furniss                                                        [Page 15]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


      single octet integers.)

   Printable Strings - as if in ISO 646 (ASCII)

   OCTET STRING - just put the octets there

4.5 Unnecessary constructed encodings

   BER allows the sender to break some items (such as OCTET STRINGS,
   character strings) into several pieces (i.e., as constructed
   encoding) or send them as primitive. CULR-1 requires that this is
   only done to one level. The pieces of both OCTET STRING and character
   string are tagged as if they were OCTET STRING - they have the tag
   04. This memo does not include any of these optional constructions,
   but they may be received in interworking.

5.  Notation

   The constructs are shown in their tag - length - value form. All
   numbers are in hexadecimal. Comments are preceded by a '-' character.
   Multiple '-' mean the comment is more than just information.

   The tag column contains one of:

      single fixed octets.

      * in the tag field indicates one or more pdu fields (possibly
      constructed) that may be received but are not sent. If received
      they can be ignored.

      ! indicates the tag is defined elsewhere.

      .  is a place holder for the column.

      ? preceding the tag value indicates that the field is not always
      present - the comment will explain.

   The length column contains one of

      explicit value

      Ls - a length according to session rules which depends on the
      total size of the value (usually constructed)

      La - a length according to BER rules

      . is a placeholder




Furniss                                                        [Page 16]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


      yy is exactly one octet (i.e., one hex digit per y) holding part
      of the length

   The value column contains one of

      the hex value

      xxxxxx - value of varying length (sometimes constructed)

      {n - (n = number) the start of a constructed value

      n - (n=number) the end of the constructed value with the
      corresponding number. (The number is sometimes omitted on the
      innermost nest of construction)

      yy - as part of a value - a variable value, each y represents one
      hex digit

      ? a value, possibly constructed that may be received but is not
      sent. It may be ignored if received

   Note that all presentation lengths may be received in one of the
   alternative forms. All constructed lengths are shown in indefinite
   form. If a received length is definite, the corresponding end item
   (which will be shown here as 00 00 }n)  will become  . . }n.

   In the comments, the notation {n} refers to the constructed item
   bracketed by the {n, }n fields.

6.  Octet sequences

6.1 Connection request message

        - CONNECT SPDU
   0D  Ls  {1       - "SI" value for CONNECT = 13
   *   Ls  ?        - Connection Identifier
   05  06  {2       - Connect/Accept Item
   13  01  00       - protocol options (probably mandatory)
   *   Ls  ?

   16  01  02       -- version number (bottom bit = v1, next bit =v2.
                    --     may get offers of either or both
   *   Ls  ?
   14  02  0002     - Session User Requirements (functional units)
                    - Id (20), length (always 2), duplex fu only.
                    -- On receipt, other bits may be set
                    -- check that the 2 bit is set
   *   Ls  ?        - we do not send any Calling Session Selector



Furniss                                                        [Page 17]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   ?34 Ls  xxxx     -- Called Session Selector (i.e., the other end's)
                    -- up to 16 octets - you must set what the other
                    -- side demands.  - May be anything characters,
                    -- binary etc.
                    -  {3} disappeared in editing
   C1  Ls  {4       -- User Data, Identifier=193. if length is > 512,
                    -- then identifier is 194 (hex C2) instead
   - CP - P-CONNECT-RI PPDU. Everything below is in ASN.1 BER
   31  80  {5       - [SET]
              --- Mode-selector (the {6} group) could possibly
              --- come after everything else {7}
              --- This will probably only be done by
              --- evil-minded conformance testers
   A0  80  {6       - Mode-selector [0] IMPLICIT SET
   80  01  01       - [0] IMPLICIT INTEGER {normalmode(1)}
   00  00  }6
   A2  La  {7       - [2] unnamed IMPLICIT SEQUENCE
   *   La  ?
   ?82 La  xxxx     - [2] Called-presentation-selector
                    - CULR says maximum length is 4
                    -- must be what the other side wants
   A4  80  {8       - [4] Presentation-context-definition-list
                ---  items (the outer SEQUENCEs) within the {8} list may
                ---  be in any order.
   30  80  {9       - [SEQUENCE]
   02  01  01       -- Defines pcid for ACSE; received value will be
                    -- a one or two octet odd integer
   06  04  52010001 - [OID] for ACSE abstract syntax
   30  80  {        - [SEQUENCE]
   06  02  5101     - [OID] Transfer syntax name is BER
   00  00  }        - end t-s list
   00  00  }9       - end acse pctx defn
   30  80  {10      - [SEQUENCE]
   02  01  03       -- [INTEGER] Defines pcid for application data;
                    -- received value will be a one or two octet odd
                    -- integer
   06  La  xxxxxx   - [OID] object identifier name of application
                    - abstract syntax (if CULR-3 default is used, this
                    - line is 06  06  28D734030101)
   30  80  {11
   06  La  xxxxxx   - [OID] t-s name for application data
                    - (if CULR-3 default is used, this line is
                    -  06  06  28D734030201)
                -- will be several of these if multiple t-s offered
                -- (application is Group III)
                -- all will have the same tag 06
   00  00  }11      - end transfer syntax list for application p-ctx
   00  00  }10      - end application pctx definition



Furniss                                                        [Page 18]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


                -- if multiple presentation contexts are offered, (Group
                -- IV), the {10} SEQUENCE will repeat appropriately
                -- if multiple contexts are to be accepted, all the
                -- pcid's must be remembered
   00  00  }8       - end of p-ctx-def-list
   *   La  ?
   61  80  {12      - [APPLICATION 1] User-data - Fully-encoded
   30  80  {13      - [SEQUENCE] PDV-list
   02  01  01      -- [INTEGER], value is acse pcid
   A0  80  {14      - [0] Single-ASN1
   - ACSE A-ASSOCIATE request APDU - AARQ
   60  80  {15      - [APPLICATION 0] - AARQ
   *   La  ?        -  protocol version defaults to 1 (only one defined)
   A1  80  {        - [1] Application-context
   06  La  xxxxxx   -- object identifier name of application context
                    - (if CULR-3 default is used, this line is
                    -  06  05  28D7340303)
   00  00  }
             -- Called application process title {16} and application
             -- entity qualifier may or may not be needed (see 3.4)
   ?A2 80  {16      - [2] Called Application-Process title
   ?!  La  xxxxxx   -- see 3.5 - either a Directory Name or an oid
   ?00 00  }16      - end Called APtitle
   ?A3 80  {17      - [3] Called Application-Entity Qualifier
   ?!  La  xxxxxx   -- see 3.5
   ?00 00  }17
   *   La  ?
             Calling AP-title and AE-qualifier may or may not be needed.
   ?A6 80  {18      - [6] Calling Application-Process title
   ?!  La  xxxxxx   -- see 3.5
   ?00 00  }18
   ?A7 80  {19      - [7] Calling Application-Entity Qualifier
   ?!  La  xxxxxx   -- see 3.5
   ?00 00  }19
   *   La  ?
            -- the user information field may or may not be required
            -- (not required for Group I)
   ?BE 80  {20      - [30] IMPLICIT SEQUENCE
   ?28 80  {21      - [EXTERNAL]
   ?06 La xxxxxx   -- [OID] This is the oid identifying the transfer
                    -- syntax used for the user data.
                    -- It is (almost certainly) required even if only
                    -- one transfer syntax was proposed.
   ?02 01  03       -  [INTEGER] this is the pcid for the application
                    -  data
   ?A0 La  xxxxxx   -- [0] single-ASN.1-type - the application data
                    --      (see paragraph at end of this section below}
   ?00 00  }21      - end of EXTERNAL



Furniss                                                        [Page 19]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


            -- conceivably there may be several EXTERNALS, probably in
            -- different presentation contexts (different pcids)
   ?00 00  }20      - end of user information field
   00  00  }15      - end of AARQ
   00  00  }14      - end of single-ASN-type
   00  00  }13      - end of PDV-list
   00  00  }12      - end of Presentation User-data
   00  00  }7       - end of third element of CP-type SET
   00  00  }5       - end of CP-type

   The application data carried in the EXTERNAL is shown (as A0 La xxxx)
   assuming it is a single-ASN.1 type, which it often will be for group
   II (since these tend to be OSI applications). The xxxx will be the
   BER encoding of the application pdu (probably something like Z-BIND
   or Y- INITIALIZE). The length may be indefinite.

   If the application data is not a single ASN.1 type, but is an octet-
   aligned value, the A0 La xxxx is replaced by 81 La xxxx, where xxxx
   is the value. In this case the length must be definite (unless an
   "unnecessary" constructed encoding is used.)

   Identical considerations apply to the other EXTERNALs carried in the
   ACSE pdus.

6.2 Successful reply to connection setup

   If the connection attempt is successful, the following is sent to the
   initiator on a T-DATA.

   0E  Ls  {1         - ACCEPT SPDU
   *   Ls  ?
   05  06  {2         - Connect/Accept Item
   13  01  00         - Protocol Options
   *   Ls  ?
   16  01  02         - version number (this shows version 2 only)
                  -- if version 2 was not offered, omit all of {2}
   *   Ls  ?
   14  02  0002       - Session User Requirements (functional units)
                      - duplex fu only (kernel is automatic)
   *   Ls  ?
   C1  Ls  {3         -- User Data.
     - CPA - P-CONNECT response
   31  80  {4         - [SET]
                      -- again, Mode-selector could come at the end
   A0  80  {          -  Mode-selector [0]
   80  01  01         -  normal mode - [0], length=1, value=1
   00  00  }
   A2  80  {5         - [2] SEQUENCE (unnamed)



Furniss                                                        [Page 20]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   *   La  ?
   A5  80  {6         - [5] P-context-definition-result-list
                   -- following result items are in the order
                   -- corresponding to the pctx-definition-list in
                   -- the connect
                   -- this example assumes that was ACSE, user, rubbish
                   -- with rubbish rejected
   30  80  {7         - [SEQUENCE] result item for acse
   80  01  00         -- [0] result, value 0 is acceptance
   81  02  5101       -  [1] accepted transfer syntax name = BER
                      - note that this has an implicit tag, not 06
   00  00  }7         - end result item for acse p-ctx

   30  80  {8         - [SEQUENCE] result item for application-data pctx
   80  01  00         - [0] value 0 is acceptance
   81  La  xxxxxx     - [1] oid for transfer syntax, as on definition list
                      -- if there were several (groupIII) , the one you
                      -- liked most
   00  00  }8         - end result item for app-data p-ctx
   00  00  }6         - end p-ctx-def-result-list
   *   La  ?
   61  80  {10        - [APPLICATION 1] User-data, Fully-encoded

   30  80  {11        - [SEQUENCE] PDV-list
   02  01  01         -- [INTEGER] value is pcid for ACSE, as stored from
                      -- the pctx-definition-list on the P-CONNECT
                      -- request
   A0  80  {12        - [0] single-ASN1-type
        - A-ASSOCIATE response APDU - AARE
   61  80  {13        - [APPLICATION 1] identifies AARE
   *   La  ?
   A1  80  {14        - [1] Application-context
   06  La  xxxxxx     - [OID] name of application context
                      - usually the same as on AARQ, can differ
   00  00  }14
   A2  03  {15        - [2] result
   02  01  00         - [INTEGER] value 0 means accepted
   00  00  }15
   A3  80  {16        - [3] result-source-diagnostic
                      - (curiously, a non-optional field)
   A1  80  {17        - [1] acse-service-user
   02  01  00         - [INTEGER] value 0 = null ! (why no implicit tag)
   00  00  }17        - end acse-service-user
   00  00  }16        - end result source diagnostic
   *   La  ?
            -- the user information field may or may not be required
            -    (not used for Group I)
   ?BE 80  {20      - [30] IMPLICIT SEQUENCE



Furniss                                                        [Page 21]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   ?28 80  {21      - [EXTERNAL]
                   -- the transfer-syntax oid is not present this time
   ?02 01  03       - [INTEGER] this is the pcid for the application
                    - data
   ?A0 La  xxxx     -- [0] single-ASN1-type (see note at end of 6.1)
   ?00 00  }21      - end of EXTERNAL
            -- conceivably there may be several EXTERNALS, probably in
            -- different presentation contexts (different pcids)
   ?00 00  }20      - end of user information field
   00  00  }13        - end AARE
   00  00  }12        - end single-asn1-type
   00  00  }11        - end PDV-list
   00  00  }10        - end Presn user-data
   00  00  }5         - end [2] implicit sequence in cpa
   00  00  }4         - end CPA-type set

   The following sequence are the octets need to reject a presentation
   context that was offered in the presentation-context-definition-list.
   Since the result-list matches the definition list by position, it is
   placed at the corresponding point within {6} (e.g., it would come
   immediately after {8}, if the rejected context was the third one.

                 -- next SEQUENCE is a rejection of a pctx
   30  80  {9         - [SEQUENCE] result item for a rejected pctx
   80  01  02         -- [0] result, value 2 is provider rejection
   82  01  00         - [2] reason, value 0 is reason-not-specified
                      -- there are other reasons, but let's keep it
                      -- simple
   00  00  }9         - end result item for rejected pctx

6.3 Connection rejection

   Refusal is at session-level, but by session user, with no reason
   given.  This is a compromise avoiding making unfounded accusations of
   (session) protocol misbehaviour. If the implementation finds it does
   not like the received message, it is not essential to attempt to
   communicate with the partner why, though this may be helpful if the
   reason is correctly identified. (In most cases, a wise implementor
   will make sure an error message goes somewhere or other).

   0C  03  {1          - REFUSE SPDU
   *   Ls  ?
   32  01  00          - rejected by SS-user, no reason

   The far-end may send interesting things explaining why you are not
   getting interworking. If this is a session reason, the reason code
   will one octet between 81 and 86. If the rejection is higher than
   session, this will be carried on S-REFUSE (so first octet is still



Furniss                                                        [Page 22]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   0C) and the higher pdu will appear as part of the reason code, which
   will start with 02.  (The only remaining code is 01 = user
   congestion.)

6.4 Data-phase TSDU

   This is the core of the skinny stack. The lengths shown use a
   particular set of choices for indefinite and definite lengths that
   means that the application data length only affects one field. Making
   the two earlier indefinite lengths definite would require more
   calculation - adding 4 octets after the application data is assumed
   to be quicker. This header is also designed to be 20 octets long,
   thus maintaining 4-byte alignment between transport and application
   buffers.  Implementations are recommended to use this encoding. It is
   possible to rapidly match incoming data against it - if there is no
   mismatch until the length field, the location of the beginning of the
   data can be determined without further analysis.

             SPDUs
   01  00  .      - S-GIVE-TOKEN - required by basic concatenation
                  - but no parameters
   01  00  .      - S-DATA - no parameters - what follows is User
                  - Information, not User Data, so is not included in
                  - the SPDU length fields
     - P-DATA PPDU - TD (why TD ? Typed-data id TTD !)
   61  80  {1     - User-data [APPLICATION 1]
   30  80  {2     - [SEQUENCE] PDV-list
   02  01  03     - [INTEGER] pcid for application data, P-CONNECT PPDU
                  - remembered by both sides
   81  83yyyyyy   xxxxxx  -- [1] octet-aligned presentation data value(s)
                 -- length of length (3 octets) then three octets yyyyyy
                 -- for the length of the user data xxxxxx
   00  00  }2      - End-of-contents for end of PDV-list
   00  00  }1      - End-of-contents for end of Presentation User-data

   If the application data is in ASN.1, and a single ASN.1 value is
   being sent on the TSDU, the same header can be used except for the
   tag on the presentation data values, which becomes A0 (= [0],
   constructed).

   If there are multiple data values to be sent, this header can be
   expanded in several ways:

      a) if there are several ASN.1 values from the same
         presentation context, they can be concatenated and
         treated as an octet-aligned value (using the header
         as shown above, with tag 81 (or A1 - I think its
         primitive) or each ASN.1 value can be an item



Furniss                                                        [Page 23]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


         (tagged A0), one after the other

      b) if the data values are from different presentation
         contexts (group IV), each is in its own {2} group
         within the {1}.

   On receipt, for the simple octet-aligned case, the data value may
   itself have a constructed encoding - this will make the tag A1, and
   it will contain elements each tagged 04 (OCTET STRING). According to
   CULR- 1, these elements are primitive (otherwise they would be 24 of
   course).

6.5 Closedown  - release request

   When all is done, and you want to close down gracefully, send this on
   T-DATA.

       - FINISH SPDU
   09  10  {1         - 9 identifies FINISH
   *   Ls  ?          - No Transport Disconnect item
                      - default is release Transport-connection
   C1  0E  {2         - User data (code 193)
       - P-RELEASE req/ind PPDU (has no name)
   61  80  {3         - [APPLICATION 1], user data, fully-encoded
   30  80  {4         - [SEQUENCE] PDV-list
   02  01  01         -- pcid for ACSE, remembered from setup
   A0  80  {5         - [0] single asn.1-type
       - A-RELEASE request APDU - RLRQ
   62  80  {6         - [APPLICATION 2] identifies RLRQ
   80  01  00         - [0] reason, value 0 means normal
   *   La  ?
            -- the user information field may or may not be required
            - ( not required for Group I)
   ?BE 80  {7       - [30] IMPLICIT SEQUENCE
   ?28 80  {8       - [EXTERNAL]
                    -- the transfer-syntax oid is not present this time
   ?02 01  03       - [INTEGER] this is the pcid for the application
                    - data
   ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
                    -- (see note at end of 6.1)
   ?00 00  }8       - end of EXTERNAL
            -- conceivably there may be several EXTERNALS, probably in
            -- different presentation contexts (different pcids)
   ?00 00  }7       - end of user information field
   00  00  }6         - end of RLRQ
   00  00  }5         - end of single asn.1-type
   00  00  }4         - end of PDV-list
   00  00  }3         - end of Presentation User-data



Furniss                                                        [Page 24]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


6.6 Closedown - release response

   On receiving a FINISH, you send this to tell the other end it is all
   over

       - Session DISCONNECT SPDU
   0A  Ls  {1         - SI=10, DISCONNECT
   C1  Ls  {2         - User data
       - P-RELEASE rsp PPDU
   61  80  {3         - [APPLICATION 1], user data, fully-encoded
   30  80  {4         - [SEQUENCE] PDV-list
   02  01  01         -- [INTEGER] pcid for ACSE, remembered from setup
   A0  80  {5         - [0] single asn.1-type
       - A-RELEASE response APDU - RLRE
   63  80  {6         - [APPLICATION 3] identifies RLRE
   80  01  00         - [0] reason, value 0 means normal
   *   La  ?
            -- the user information field may or may not be required
            - (not required for Group I)
   ?BE 80  {7       - [30] IMPLICIT SEQUENCE
   ?28 80  {8       - [EXTERNAL]
                   -- the transfer-syntax oid is not present this time
   ?02 01  03       - [INTEGER] this is the pcid for the application
                    - data
   ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
                    -- (see note at end of 6.1)
   ?00 00  }8       - end of EXTERNAL
            -- conceivably there may be several EXTERNALS, probably in
            -- different presentation contexts (different pcids)
   ?00 00  }7       - end of user information field
   00  00  }6         - end of RLRE
   00  00  }5         - end of single asn.1-type
   00  00  }4         - end of PDV-list
   00  00  }3         - end of Presentation userdata

6.7 Deliberate abort

   It is not clear whether this is any use - just clearing the Transport
   connection will be more effective. It goes on T-DATA, but asks for
   the far-side to close the T-connection.

       - Session ABORT SPDU
   19  Ls  {1      - SI of 25 is ABORT
   11  01  03      - Transport Disconnect PV, code 17
                   --  value = '...00011'b means please
                   -- release T-conn, user abort
   *   Ls  ?
   C1  11  {2      - Session User Data



Furniss                                                        [Page 25]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


       - P-U-ABORT PPDU - ARU
   A0  80  {3      - [0] implicit sequence for normal mode
   A0  80  {4      - [0] presentation-context-identifier-list
   30  80  {5      - [SEQUENCE]
   02  01  01      - [INTEGER]pcid for ACSE
   06  02  5101    - [OID] for acse transfer syntax = BER
   00  00  }5
            -- there will be one {6} group for each application
            -- presentation context that is used in this message
            -- if there is no user data, the {6} group can be
            -- omitted
   30  80  {6
   02  01  03      - [INTEGER] pcid for application data
   06  La  xxxxxx  - [OID] transfer syntax for application data
   00  00  }6
   00  00  }4      - end of presentation-context-identifier-list
   61  80  {7      - [APPLICATION 1], user data, fully-encoded
   30  80  {8      - [SEQUENCE] PDV-list
   02  01  01      - [INTEGER] pcid for ACSE as on CP PPDU
   A0  05  {9      - [0] single asn.1-type
       - A-ABORT APDU - ABRT
   64  80  {10     - [APPLICATION 4] identifies ABRT
   80  01  01      -  [0] value 1 is acse-service-provider
            -- the user information field may or may not be required
   ?BE 80  {11      - [30] IMPLICIT SEQUENCE
   ?28 80  {12      - [EXTERNAL]
                   -- the transfer-syntax oid is not present this time
                   -- (according to CULR-1)
   ?02 01  03       - [INTEGER] this is the pcid for the application
                    - data
   ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
                    -- (see note at end of 6.1)
   ?00 00  }12      - end of EXTERNAL
            -- conceivably there may be several EXTERNALS, probably in
            -- different presentation contexts (different pcids)
   ?00 00  }11      - end of user information field
   00  00  }10     - end of ABRT
   00  00  }9      - end of single asn.1-type
   00  00  }8      - end of PDV-list
   00  00  }7      - end of Presentation user-data
   00  00  }3      - end of ARU-PPDU










Furniss                                                        [Page 26]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


6.8 Provider abort

   Generated when an internal error occurs (i.e., something has gone
   mildly (?) wrong in the cookbook implementation). Rather than accuse
   anyone of protocol errors, we just abort at session.

             ABORT SPDU
   19  03  {1         - SI=25 = ABORT SPDU
   11  01  09         - Transport Disconnect PV, code 17
                    -- value = '...01001'b  release T-conn
                    --  no reason
   *   Ls  ?

6.9 Abort accept

   If a Session abort (of any kind) is sent, it is possible that the
   far-end will send back an abort accept. If this happens, disconnect
   the transport. (The abort messages above do not propose that the
   transport connection be reused, and in this case, an abort accept is
   just the far-end passing the transport-disconnect initiative back.)
   This session message need never be sent - just disconnect transport
   on receiving an abort.

             ABORT ACCEPT SPDU
   1A  00  .         - SI=26 = ABORT ACCEPT SPDU, no parameters

7.  References

   [CULR-1] ISO/IEC DISP 11188-1 - Information Technology -
   International Standardised Profile - Common Upper Layer Requirements
   - Part 1: Basic Connection oriented requirements (DISP ballot ends
   June 1994).

   [CULR-3] Draft of Common Upper-layer requirements - Part 3: Minimal
   OSI upper layers facilities (A later draft will be proposed as ISP
   11188/3).

   [ISO8072] Information processing systems - Open Systems
   Interconnection - Transport service definition; ISO, 1986.

   [ISO8073] Information processing systems - Open Systems
   Interconnection - Transport protocol specification; ISO, 1986.

   [ISO8326] Information processing systems - Open Systems
   Interconnection - Basic connection oriented session service
   definition; ISO, 1987 (or review copy of revised text = ISO/IEC
   JTC1/SC21 N4657, April 1990).




Furniss                                                        [Page 27]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   [ISO8327] Information processing systems - Open Systems
   Interconnection - Basic connection oriented session protocol
   specification; ISO, 1987 (or review copy of revised text = ISO/IEC
   JTC1/SC21 N4656, April 1990).

   [ISO8649] Information processing systems - Open Systems
   Interconnection - Service definition for the Association Control
   Service Element; ISO, 1989.

   [ISO8650] Information processing systems - Open Systems
   Interconnection - Protocol specification for the Association Control
   Service Element; ISO, 1989.

   [ISO8822] Information processing systems - Open Systems
   Interconnection - Connection-oriented presentation service
   definition; ISO, 1989.

   [ISO8823] Information processing systems - Open Systems
   Interconnection - Connection-oriented presentation protocol
   specification; ISO, 1989.

   [ISO8824] Information technology - Open Systems Interconnection -
   Specification of Abstract Syntax Notation One (ASN.1), ISO/IEC 1990.

   [ISO8825] Information technology - Open Systems Interconnection -
   Specification of Basic Encoding Rules for Abstract Syntax Notation
   One, ISO/IEC 1990.

   [RFC1006] Rose, M., and D. Cass, "ISO Transport Services on Top of
   the TCP", STD 35, RFC 1006, Northrop Research and Technology Center,
   May 1987.

   [ISO9594] Information technology - Open Systems Interconnection - The
   Directory; ISO/IEC, 1990.

   [RFC 1274] Barker, P., and S. Kille, "The COSINE and Internet X.500
   Schema", RFC 1274, University College London, November 1991.

8. Other Notes

   The Session, Presentation and ACSE standards have been the subject of
   considerable amendment since their first publication. The only one
   that is significant to this cookbook is Session addendum 2, which
   specifies session version 2 and unlimited user data. New editions of
   these standards, incorporating all the amendments, will be published
   during 1994.





Furniss                                                        [Page 28]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   The coding choices made in the cookbook are (nearly) those made by
   the "Canonical Encoding Rules", which are a form of Basic Encoding
   Rules with no optionality, specified in the new edition of ISO/IEC
   8825. A defect report has been proposed against Presentation and
   ACSE, suggesting that a note to the protocol specifications recommend
   use of the canonical encoding options when sending, and then
   optimising for this on receipt.

9.  Security Considerations

   Security issues are not discussed in this memo.

10.  Author's Address

   Peter Furniss
   Peter Furniss Consultants
   58 Alexandra Crescent
   Bromley, Kent BR1 4EX
   UK

   Phone & Fax +44 81 313 1833
   EMail: P.Furniss@ulcc.ac.uk





























Furniss                                                        [Page 29]