File: rfc1921.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 (1683 lines) | stat: -rw-r--r-- 57,475 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
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






Network Working Group                                          J. Dujonc
Request for Comments: 1921                                     Bull S.A.
Category: Informational                                       March 1996


                             TNVIP Protocol

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

   The goal of this document specifies a Telnet profile to support VIP
   terminal emulation allowing the access to the BULL hosts applications
   through a TCP/IP network.

Table of Contents

    1.       Motivation . . . . . . . . . . . . . . . . . . . . . . 2
    2.       Background . . . . . . . . . . . . . . . . . . . . . . 3
    3.       Telnet Options and Commands Used . . . . . . . . . . . 3
    3.1.      Terminal type option  . . . . . . . . . . . . . . . . 4
    3.1.1.      Subnegotiation of the Terminal Type . . . . . . . . 4
    3.1.2.      Terminal-types supported by the TNVIP protocol  . . 4
    3.1.3.      TNVIP terminal models . . . . . . . . . . . . . . . 5
    3.1.4.      Mailbox name  . . . . . . . . . . . . . . . . . . . 5
    3.2.      End of Record Option  . . . . . . . . . . . . . . . . 6
    3.3.      Binary Transmission option  . . . . . . . . . . . . . 6
    3.4.      Suppress Go Ahead option  . . . . . . . . . . . . . . 7
    4.       TNVIP functions  . . . . . . . . . . . . . . . . . . . 8
    4.1.      TNVIP terminal station  . . . . . . . . . . . . . . . 9
    4.1.1.      Local and online states . . . . . . . . . . . . . . 9
    4.1.2.      Data receiving  . . . . . . . . . . . . . . . . .  10
    4.1.3.      Data sending  . . . . . . . . . . . . . . . . . .  10
    4.2.      TNVIP Server functions  . . . . . . . . . . . . . .  10
    4.2.1.      VIP Terminal Manager  . . . . . . . . . . . . . .  10
    5.       TNVIP Messages Format  . . . . . . . . . . . . . . .  12
    5.1.      Address Field . . . . . . . . . . . . . . . . . . .  12
    5.2.      Command field . . . . . . . . . . . . . . . . . . .  13
    5.3.      Parameter field . . . . . . . . . . . . . . . . . .  14
    6.       The screen flow  . . . . . . . . . . . . . . . . . .  14
    6.1.      Screen data messages  . . . . . . . . . . . . . . .  14
    6.2.      Local state monitoring messages . . . . . . . . . .  15
    6.3.      Screen response messages  . . . . . . . . . . . . .  16
    6.3.1      Page overflow processing . . . . . . . . . . . . .  17



Dujonc                       Informational                      [Page 1]

RFC 1921                     TNVIP Protocol                   March 1996


    6.4.      Screen data purge indication message  . . . . . . .  17
    7.       The printer flow . . . . . . . . . . . . . . . . . .  17
    7.1.      Printer data messages . . . . . . . . . . . . . . .  17
    7.2.      Printer response messages . . . . . . . . . . . . .  18
    7.3.      7800 printer status management  . . . . . . . . . .  19
    7.4.      Printer state request message   . . . . . . . . . .  20
    7.5.      Printer state response messages . . . . . . . . . .  20
    7.6.      Printer purge indication message  . . . . . . . . .  20
    8.       The Screen Copy Printing flow  . . . . . . . . . . .  21
    8.1.      Screen copy request messages  . . . . . . . . . . .  21
    8.2.      Screen copy data message  . . . . . . . . . . . . .  21
    8.3.      Screen copy response messages . . . . . . . . . . .  22
    8.4.      Screen copy purge indication message  . . . . . . .  23
    9.       The TM attention . . . . . . . . . . . . . . . . . .  23
    10.      The Break Key  . . . . . . . . . . . . . . . . . . .  24
    11.      The Logout Key . . . . . . . . . . . . . . . . . . .  24
    12.      TNVIP messages list  . . . . . . . . . . . . . . . .  24
    12.1.     Screen Flow . . . . . . . . . . . . . . . . . . . .  24
    12.2.     Printer flow  . . . . . . . . . . . . . . . . . . .  26
    12.3.     Screen Copy Printing messages flow  . . . . . . . .  28
    13.      Security Considerations  . . . . . . . . . . . . . .  29
    14.      References . . . . . . . . . . . . . . . . . . . . .  30
    15.      Author's Address . . . . . . . . . . . . . . . . . .  30

1. Motivation

   P200 [7] and 7800 [8] VIP (Visual Information Projection) terminals
   differ mainly from NVT terminals [1] in that they work in block mode
   and have the capability to manage an associated printer. Generally in
   a DSA (Distributed Systems Architecture) network they are managed
   through the VIP transmission line procedure (character oriented).
   That is the reason why they are generically referred as VIP
   terminals.

   This document specifies the options to be modified successfully, to
   pass from the NVT terminal emulation supported on a Telnet
   connection, to a VIP terminal emulation. It defines also the format
   of the messages exchanged between the server and the client when the
   TNVIP protocol is successfully negotiated.












Dujonc                       Informational                      [Page 2]

RFC 1921                     TNVIP Protocol                   March 1996


2. Background

   VIP terminal family includes a broad range of different terminal
   types. They work in block mode with an ASCII or 8 binary bits set of
   characters.

   The Bull terminals in the DSA network environment use the services of
   a Terminal Manager (TM) [2]. It is generally installed in a
   communication processor (as a Datanet or Mainway system) where it
   assures the connection with the BULL host application generally
   through a DSA session.

   The Terminal Manager is in charge to present the terminal station and
   to manage the session connection to the host computer. It offers
   generally a possibility of dialog with the terminal to allow the user
   to modify the connection parameters, to manage the session
   (connection request, abort, etc ..). The set of commands and
   responses used is called "TM Local Dialog".

3. Telnet Options and Commands Used

   The mandatory telnet parameters to be negotiated successfully between
   the "TNVIP server" and the "TNVIP client" are :

    - the Terminal-Type option [3] to define a VIP terminal model and
      if necessary a Mailbox name to request a specific access point in
      the "TNVIP server",

    - the End Of Record option [4] to delimit the TNVIP message at the
      Telnet level. As the End Of Record (EOR) code indicates the end of
      an effective data unit, Telnet should attempt to send the data up
      to and including the EOR code together to promote communication
      efficiency.

    Others Telnet parameters, can be optionally negotiated as :

    - the Binary Transmission option [5], when the terminal emulation
      uses a 8 binary bits set of characters,

    - the Suppress Go Ahead option [6], when no synchronisation of the
      data transmission from the "TNVIP client" with the DSA session
      turn or the ISO session token is needed.

   When the two parties (the "TNVIP server" and the "TNVIP client") have
   negotiated successfully a TNVIP terminal type and the EOR telnet
   option, that means they agree to respect the TNVIP protocol (the
   TNVIP message format and the exchange rules).




Dujonc                       Informational                      [Page 3]

RFC 1921                     TNVIP Protocol                   March 1996


3.1 Terminal type option

   IAC DO TERMINAL-TYPE

      Sender (the "TNVIP server" party) is willing to receive terminal
      type information in a subsequent sub-negotiation.

   IAC WILL TERMINAL-TYPE

      Sender (the terminal "TNVIP client" party) is willing to send
      terminal-type information in a subsequent sub-negotiation.

3.1.1 Subnegotiation of the Terminal Type

   IAC SB TERMINAL-TYPE SEND IAC SE

      Sender (the "TNVIP server" party) requests the receiver to
      transmit his next terminal-type, and switch emulation modes (if
      more than one terminal type is supported).

   IAC SB TERMINAL-TYPE IS tnvip-terminal-model@MB-name IAC SE

      Sender (the terminal "TNVIP client" party) is stating the name of
      his current (or only) terminal-type. Optionally, a mailbox name
      can be added to request a particular access point in the "TNVIP
      server". By default, the "TNVIP server" uses a generic access
      point.

3.1.2 Terminal-types supported by the TNVIP protocol

   The TNVIP terminal type string given at the Telnet negotiation is
   formatted as follows :

      <TNVIP-terminal-model> [ <@ character> <Mailbox-name> ]

   The @ character is used as separator between the VIP-terminal-model
   and the Mailbox-name.














Dujonc                       Informational                      [Page 4]

RFC 1921                     TNVIP Protocol                   March 1996


3.1.3 TNVIP terminal models

   The valid TNVIP terminal models are the following ASCII character
   strings. (The table gives for each terminal model string the
   hexadecimal number indicating the associated DSA model number defined
   in the DSA terminal presentation protocols ).

                 P200 family                      7800 family
    -------------------------------- --------------------------------
    !   TNVIP model  !    DSA code ! !   TNVIP model  !    DSA code !
    -------------------------------- --------------------------------
    !   VIP7700      !       33    ! !   VIP7804      !       3E    !
    !   VIP7760      !       3A    ! !   VIP7804V     !       4A    !
    !   DKU7005      !       3D    ! !   VIP7814      !       47    !
    !   DKU7007D     !       40    ! !   HDS7         !       4D    !
    !   DKU7105      !       41    ! !   VIP8800      !       4F    !
    !   DKU7107D     !       42    ! --------------------------------
    !   DKU7211      !       45    !
    !   DKU7211D     !       4E    !
    --------------------------------

   The D character at the end of the string indicates that the terminal
   supports the Remote Forms function [9]. It is the capability to store
   forms in the terminal allowing the host application to display a form
   stored in the terminal sending a short length command without sending
   all the data of the form. This function is usually supported by the
   terminal concentrators.

3.1.4 Mailbox name

   The mailbox name allows the "TNVIP client" to request a specialized
   access point referenced by this name in the "TNVIP server". It is an
   ASCII character string. Its presence in the Telnet terminal type
   string is optional. When not present, a generic (default) access can
   be provided by the "TNVIP server".

   When the "TNVIP server" is a gateway to DSA hosts, the mailbox name
   defines the DSA session access point of the terminal in the server.
   Its length is limited to 12 characters. Lower case characters are
   allowed but are processed as upper case. This string is generally
   used to identify a specific terminal station (having a printer for
   example) or to use a particular declaration of this terminal in the
   "TNVIP server".








Dujonc                       Informational                      [Page 5]

RFC 1921                     TNVIP Protocol                   March 1996


3.2 End of Record Option

   VIP device communications are block oriented. That is, each partner
   buffers data until an entire "message" has been built, at which point
   the data are sent to the other side. The end of a message is
   understood to be the last byte transmitted. The Telnet EOR command is
   used to delimit these natural blocks of TNVIP data within the Telnet
   data stream. An <EOR> is sent at the end of each TNVIP message, in
   both directions.

   IAC WILL END-OF-RECORD

      The sender of this command requests permission to begin
      transmission of the Telnet END-OF-RECORD (EOR) code when
      transmitting data characters, or the sender of this command
      confirms it will now begin transmission of EORs with transmitted
      data characters.

   IAC DO END-OF-RECORD

      The sender of this command requests that the sender of data starts
      transmitting the EOR code when transmitting data, or the sender of
      this command confirms that the sender of data is expected to
      transmit EORs.

3.3 Binary Transmission option

   According to the character set used by the emulation, the "TNVIP
   client" and the "TNVIP server" can be led to negotiate the Telnet
   binary transmission option.

   If either side wishes to transmit the decimal value 255 and have it
   interpreted as data, it must "double" this byte. In other words, a
   single occurrence of decimal 255 will be interpreted by the other
   side as an IAC, while two successive bytes containing decimal 255
   will be treated as one data byte with a value of decimal 255.

   IAC DO TRANSMIT-BINARY

      Sender requests that sender of the data starts transmitting or
      confirms that the sender of data is expected to transmit
      characters that are to be interpreted as 8 bits of binary data by
      the receiver.

   IAC WILL TRANSMIT-BINARY

      Sender requests permission to begin transmitting, or confirms it
      will now begin transmitting binary data.



Dujonc                       Informational                      [Page 6]

RFC 1921                     TNVIP Protocol                   March 1996


   IAC WON'T TRANSMIT-BINARY

      If the connection is already being operated in binary transmission
      mode, the sender of this command demands to begin transmitting
      data characters which are to be interpreted as standard NVT ASCII
      characters by the receiver of the data. If the connection is not
      already being operated in binary transmission mode, the sender of
      this command refuses to begin transmitting characters which are to
      be interpreted as binary characters by the receiver of the data
      (i.e., the sender of the data requests to continue transmitting
      characters in its present mode).

   IAC DON'T TRANSMIT-BINARY

      If the connection is already being operated in binary transmission
      mode, the sender of this command requests that the sender of the
      data start transmitting characters which are to be interpreted as
      standard NVT ASCII characters by the receiver of the data
      (i.e.,the party sending this command). If the connection is not
      already being operated in binary transmission mode, the sender of
      this command requests that the sender of data continue
      transmitting characters which are to be interpreted in the present
      mode.

3.4 Suppress Go Ahead option

   The "TNVIP client" can use the receiving of the Telnet GoAhead
   command as the signal allowing the terminal operator to transmit
   data. That can allow the synchronisation between the data transmitted
   from the terminal and the DSA "turn".

   When the Suppress Go Ahead option is not negotiated, the "TNVIP
   server" must send the Telnet Go Ahead command (GA) when its input
   message queue (from the "TNVIP client") is empty and the DSA turn is
   at the terminal side, to invite the terminal to transmit some data.

   To suppress this mechanism, the "TNVIP client" can request the no
   sending of the Telnet GoAhead commands by the "TNVIP server",
   negotiating the Suppress GO Ahead option of the Telnet Protocol.

   In this case, the terminal transmission to the "TNVIP server" is
   synchronised on the transport credit.

   Note: The Telnet GA command never need to be sent by the "TNVIP
         client" even if the telnet Suppress Go Ahead has not been
         negotiated.





Dujonc                       Informational                      [Page 7]

RFC 1921                     TNVIP Protocol                   March 1996


   IAC DO SUPPRESS-GO-AHEAD

   The sender of this command (the "TNVIP client" party) requests that
   the sender of data starts suppressing GA when transmitting data.

   IAC WILL SUPPRESS-GO-AHEAD

      The sender of this command (the "TNVIP server" party) confirms it
      will now begin suppressing transmission of GAs with transmitted
      data characters.

   IAC DON'T SUPPRESSS-GO-AHEAD

      The sender of this command (the "TNVIP client" party) requests
      that the receiver of the command start transmitting GAs when
      transmitting data.

   IAC WON'T SUPPRESS-GO-AHEAD

      The sender of this command (the "TNVIP server" party) confirms it
      will now begin transmitting the GA character when transmitting
      data characters.

4. TNVIP functions

   The TNVIP protocol allows the following functions :

    - Support of a VIP terminal emulation addressing the screen and its
      associated printer .

    - Selection of the terminal type model at the connection time.

    - Specific or generic access to the "TNVIP server" by referencing or
      not a Mailbox name.

    - TNVIP protocol independent of the terminal data presentation
      protocol (7800 or P200).

    - Support of the DSA End To End Acknowledgement.

    - Support of the DSA Terminal Manager local attention.

    - Support of the DSA turn to the terminal side.

    - Support of the DSA secret read.

    - Control of the hard copy.




Dujonc                       Informational                      [Page 8]

RFC 1921                     TNVIP Protocol                   March 1996


4.1 TNVIP terminal station

   The "TNVIP client" acts as the interface adapter between the TNVIP
   connection and an application program. The "TNVIP client" is mainly
   defined to support a VIP terminal emulation program but can be used
   by other else program using the TNVIP protocol.

   A VIP terminal emulation manages:

    - a screen buffer,

    - a printer buffer if it supports the associated printer,

    - the interface with the communication line

   and runs using the following rules:

   When the VIP terminal emulation exchanges a message on the
   communication line, it is in the BUSY state until the end of the
   message exchange. That means when the VIP terminal is sending a
   message it can't receive and when it is receiving a message it can't
   send.

   Note: If a VIP terminal works in the half duplex mode, as the TNVIP
         protocol uses a Telnet connection it allows a full duplex
         mode processing.

4.1.1 Local and online states

   The VIP terminal has the capability to switch between these two
   states. The LOCAL state is generally used to process local terminal
   tests or to modify the configuration. In this state, the data coming
   from the line are ignored.

   The LOCAL state allows the "TNVIP client" to request to the server
   the screen and printer data flows to be suspended.

   The ONLINE state indication allows the "TNVIP server" to resume the
   screen and printer flows.

   For these reasons the TNVIP protocol differentiates the screen and
   printer flows from the screen copy printing flow and defines to
   report the two states to the "TNVIP server".








Dujonc                       Informational                      [Page 9]

RFC 1921                     TNVIP Protocol                   March 1996


4.1.2 Data receiving

   When a VIP terminal emulation receives a data message from the line,
   according to the address given in the header message,it sends data to
   the screen buffer or to the printer buffer.

   A message received at the screen or printer address is deleted and
   ignored if the terminal emulation is in the LOCAL state and a BUSY
   status is returned.

   The printer buffer is busy when the terminal is transmitting the data
   from the printer buffer to the printer device. A data message for the
   printer is deleted and ignored if the terminal is in the printing
   state and a BUSY status is returned.

   When a BUSY state is encountered, the "TNVIP client" according to the
   type of message received (request or indication) reports or not the
   BUSY acknowledgement to the "TNVIP server".

4.1.3 Data sending

   A VIP terminal emulation can send message even if the terminal is in
   the LOCAL state.

4.2 TNVIP Server functions

4.2.1 VIP Terminal Manager

   Its function is to act as a gateway between the VIP terminal and the
   VIP application. Generally the application is a remote DSA
   application.

   It manages the screen and printer devices of the VIP terminal
   station.

















Dujonc                       Informational                     [Page 10]

RFC 1921                     TNVIP Protocol                   March 1996


   In the following example figure, the "TNVIP server" is a DSA server
   and manages three VIP terminal units TU1, TU2 and TU3.

    Generic access
    --------------
              !----> LD 1S ----> DV 1S (screen)  ---->!
    MB 1 --> SN 1                                     TU 1
              !----> LD 1P ----> DV 1P (printer) ---->!

    Specific accesses
    -----------------
              !----> LD 2S ----> DV 2S (screen)  ---->TU 2
    MB 2 --> SN 2
              !----> LD 2P ----> !
                                 !
              !----> LD 3P ----> DV 3S (printer) ---->!
    MB 3 --> SN 3                                     TU 3
              !----> LD 3S ----> DV 3P (screen)  ---->!

   Each Terminal Unit (TU object) is declared as containing one or two
   devices (DV objects). The Terminal Manager maps this physical
   representation to a logical representation where the station (SN
   object) is the logical representation of a terminal unit, and the
   logical device (LD) object a logical representation of the real
   device.

    - TU1 will be chosen by default on generic request (without mailbox
      name) or by the MB1 name addressing on specific request. It can
      manage the associated printer device.

    - MB2 will be addressed to access the TU2 terminal unit. TU2 is
      defined in a specific way because it will be presented to the host
      application as a station composed of a screen (the TU2 one's) and
      a printer (the TU3 one's).

    - MB3 will be addressed to access TU3 terminal unit. TU3 is also
      defined in a specific way because the printer device is shared by
      several logical stations (SN2 and SN3) and must be well
      identified.












Dujonc                       Informational                     [Page 11]

RFC 1921                     TNVIP Protocol                   March 1996


5. TNVIP Messages Format

   Each TNVIP message is delimited by the Telnet EOR command.

   Therefore, a TNVIP message has the following format:

    <TNVIP Header> <parameters> <IAC EOR>

   The TNVIP header is mandatory and have a fixed length of two bytes.

   Some TNVIP messages need no parameter. In this case, the TNVIP
   message has the following construction:

    <TNVIP Header> <IAC EOR>

   It is strongly recommended that Telnet commands (other than IAC IAC)
   should be sent between TNVIP messages, with no TNVIP header and no
   trailing IAC EOR. If a TNVIP data message containing any other IAC-
   command sequence (other than IAC IAC) is received, it is
   implementation dependent when the IAC-command sequence will be
   processed, but it must be processed. The receiver may process it
   immediately, which in effect causes it to be processed as if it had
   been received before the current TNVIP message, or the processing may
   be deferred until after the current TNVIP message has been processed.
   It is because of this ambiguity that the presence of Telnet commands
   within a TNVIP message is not recommended; neither "TNVIP client"s
   nor "TNVIP server"s should send such data.

   The TNVIP header contains 2 bytes. The first one indicates the
   address <ADR> and the second the command <CDE>.

5.1 Address Field

   The <ADR> address field is mandatory and is defined on one byte.

   The TNVIP protocol defines 3 addresses:

    - ADR = SCREEN  = 96 (0x60) for the screen commands flow,

    - ADR = PRINTER = 104 (0x68) for the printer commands flow,

    - ADR = SCPM    = 105 (0x69) for the screen copy printing commands
      flow.

   A request message with an unknown or unsupported address will be
   discarded by the receiver which replies with a NOT-AVAILABLE response
   message.




Dujonc                       Informational                     [Page 12]

RFC 1921                     TNVIP Protocol                   March 1996


5.2 Command field

   The <CDE> command field is mandatory and defined on one byte.

   The command byte <CDE> is structured as follows:

    <Command-Type><Message-Type>

    - The Command-Type fills the six most significant bits of the <CDE>
      byte. The most significant bit is always 0.

      Its value is ranged from 0 to 31 included. It defines the command
      associated to the message for the flow identified by the address
      field.

    - The Message-Type fills the two less significant bits of the <CDE>
      byte.

      0 = Indication message. No response message is expected. An
      indication message with an undefined command type or with an
      unknown address is deleted and ignored.

      1 = Request message. The sender of a request message is waiting
      for a response message having the same address value. When a
      request message is sent for a given address, it is not allowed to
      send another request to the same address before the receiving
      response. If an end point receives a request before having sent
      the response of the previous request, it deletes the second
      request but have to send back a PROTOCOL-VIOLATION response after
      the response of the first request. A request message with a not
      defined address is replied to by a NOT-AVAILABLE response message.
      A request message with an unknown or unsupported command <CDE> for
      this address will be deleted by the receiver and replied to by an
      UNKNOWN-COMMAND response message.

      2 = Response message. This message is the response to the current
      request message. The receiver of this message is allowed to send
      another request message on the flow defined by the ADR field.

      3 = Response and request message. This message is a positive
      response to the current request message sent by the receiver, but
      is also a request message.









Dujonc                       Informational                     [Page 13]

RFC 1921                     TNVIP Protocol                   March 1996


   The following table gives the <CDE> commands list with their
   hexadecimal values

    Command          Indication  Request  Response  Resp/Req
    --------------------------------------------------------
    DATA                00         01
    PASSW               04         05
    ACK                                      0A
    ERROR                                    0E
    BUSY                                     12
    ABORTED                                  16
    PURGED                                   1A
    NOT-AVAILABLE                            1E
    PROTOCOL-VIOLATION                       22
    UNKNOWN-COMMAND                          26
    PURGE               28
    LOCAL-STATE                    2D
    ONLINE-STATE        30
    STATE-REQ                      35
    READY                                    3A
    STANDBY                                  3E
    COPY-REQ                       41
    LOCAL-COPY                                         47

5.3 Parameter field

   This field has a variable length and its content is depending on the
   two previous fields (address and command).

6. The screen flow

   All the following messages contain the value SCREEN = 96 (0x60) in
   the ADR field.

6.1 Screen data messages

   These messages are defined to transport in the parameter field of the
   TNVIP message, the data in the terminal presentation negotiated by
   the "Terminal Type" telnet command.

   The parameter has the following format:

    <FC1> <FC2> <STX> < screen data>

    - The FC1, FC2 bytes are the functions codes of the VIP procedure
      transmission [9]. Their values are comprised between 32 (0x20)
      included and 127 (0x7F) included.




Dujonc                       Informational                     [Page 14]

RFC 1921                     TNVIP Protocol                   March 1996


    - The STX byte is defined by the value 2 and acts as the introducer
      of the screen data.

   A screen data message can be sent in a request or in an indication
   message. The command values are defined as follows:

    <CDE> = DATA indication = 0

    <CDE> = DATA request = 1

    <CDE> = PASSWORD indication = 4

    <CDE> = PASSWORD request = 5

   Generally, the "TNVIP server" only sends indication messages to the
   screen. The request message is used mainly for the printer device.
   But a DSA/TNVIP gateway server should use the screen data request
   message when it processes a DSA end to end acknowledgement request
   from the DSA application and synchronizes the response message
   receipt with the DSA end to end acknowledgement.

   The password request and the password indication message are defined,
   to be used by the programs in the "TNVIP client" machine which don't
   emulate terminal. In this way, they have the indication that a secret
   read (password acquisition) is requested by the "TNVIP server". When
   the program is a terminal emulation this information is not necessary
   because the data contains the terminal presentation command to
   request this secret read.

6.2 Local state monitoring messages

   Before to switch in the local state, the "TNVIP client" sends a
   LOCAL-STATE request message to the "TNVIP server". This last one
   sends back an acknowledgement message and suspends the screen and
   printer data flow until it receives a LINE-STATE indication message.

   Note: In the local state, only the messages from the "TNVIP server"
         to the screen or printer devices are deleted. The messages
         from the "TNVIP client" screen device or the messages
         associated to others addresses are allowed.

   The following command values are defined as:

    <CDE> = LOCAL-STATE request = 45 (0x2D). It is sent by the "TNVIP
    client". There is no parameter field.






Dujonc                       Informational                     [Page 15]

RFC 1921                     TNVIP Protocol                   March 1996


    <CDE> = ONLINE-STATE indication = 48 (0x30). It is sent by the
    "TNVIP client" to indicate the "TNVIP server" is allowed to resume
    the screen data flow. There is no parameter field.

6.3 Screen response messages

   These messages are indications used to respond to the screen data
   request previously received.

   The command values are defined as follows:

    <CDE> = ACK response indication = 10 (0x0A). The screen data
    previously received has been well processed or the LOCAL STATE is
    acknowledged by the "TNVIP server". There is no parameter field.

    <CDE> = ERR response indication = 14 (0x0E). The screen data
    previously received has not been correctly processed. There is no
    parameter field.

    <CDE> = BUSY response indication = 18 (0x12). The screen data
    previously received has been deleted because the terminal is in the
    local state. There is no parameter field.

    <CDE> = ABORTED response indication = 22 (0x16). The receipt of the
    screen data request has been aborted by a reset terminal command.
    There is no parameter field.

    <CDE> = PURGED response indication = 26 (0x1A). The processing of
    the screen data request has been aborted by a purge indication
    message. There is no parameter field.

    <CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The screen
    device is not supported. Normally this command has never to be
    generated because the screen device should always be present. There
    is no parameter field.

    <CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
    screen request received has been deleted because an other screen
    request is already in process. That means several screen request
    messages have been sent without waiting for the response. It is a
    consequence of the non-compliance of the protocol. There is no
    parameter field.

    <CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The screen
    request received has been deleted because the <CDE> field value is
    unknown. It is a consequence of the non-compliance of the protocol.
    There is no parameter field.




Dujonc                       Informational                     [Page 16]

RFC 1921                     TNVIP Protocol                   March 1996


6.3.1 Page overflow processing

   The page overflow processing is not supported through the TNVIP
   protocol to avoid the retransmission of the message. That leads the
   "TNVIP client" side to process it locally. When a data message
   induces a page overflow, the terminal emulation alerts the user
   possibly requesting (in manual mode) an "enter" action before
   clearing the screen and reprocessing the data received.

   Note: When the "TNVIP client" is processing a page overflow , the
         terminal emulation should be in the BUSY state and should
         stop getting message from the line ("TNVIP server") until the
         page overflow processing is complete.

6.4 Screen data purge indication message

   This message is used to purge the current screen request message.
   When the side which receive the message has not already acknowledged
   the screen request, it tries to abort the processing of the request
   and returns a screen purged response message. If it has already
   replied, it ignores and deletes the message.

   The following command value is defined as:

    <CDE> = PURGE indication = 40 (0x28). There is no parameter field.

7. The printer flow

   All the following messages contain the PRINTER value 104 (0x68) in
   the ADR field. The support of this address is optional. If the "TNVIP
   server" doesn't address this device, no message with this address
   will be exchanged. If the "TNVIP client" receives a request message
   with this address and does not support the printer, it replies with a
   printer NOT-AVAILABLE response message.

7.1 Printer data messages

   These messages are defined to transport the printer data in the
   parameter field of the TNVIP message. These messages are only sent
   from the "TNVIP server" to the "TNVIP client".

   The parameter has the following format:

    <FC1> <FC2> <STX> <printer data>

    - The FC1, FC2 bytes are the function codes of the VIP procedure
      transmission. Their values are ranged from  32 (0x20) to 127
      (0x7F) included.



Dujonc                       Informational                     [Page 17]

RFC 1921                     TNVIP Protocol                   March 1996


    - The STX byte is defined by the value 2 and acts as the introducer
      of the printer data.

   To manage correctly the printer device, the protocol only defines
   request message. Whereas the "TNVIP server" is ensured than the
   "TNVIP client" processes a screen data message only when the previous
   one have been processed. When it receives a printer data message, the
   "TNVIP client" transfers it in the printer buffer. The terminal is
   busy only during this transfer. So, if the "TNVIP client" receives
   another printer data it deletes them because the previous printing
   (transfer between the printer buffer and the printer) is not ended.

   The printer data structure depends on the terminal presentation
   family (P200 or 7800). The two presentations define two modes of
   printing. The first one needs the printer data are in the
   presentation of the screen (7800 or P200 commands) and data are
   converted by the terminal in the printer presentation (TTY, SDP,
   copy. The second mode allows to give the printer data in the real
   presentation of the printer. For this reason it is called
   "transparent print".

   In the P200 terminal presentation, transparent print data are
   introduced by the sequence of the two ASCII characters ESC Z (0x1B
   0x5A ). P200 formatted print are introduced by the sequence of two
   ASCII characters ESC X (0x1B 0x58) or ESC Y (0x1B 0x59).

   In the 7800 terminal presentation, transparent print data are
   introduced by the command PTD (Print Transparent Data). 7800
   formatted print are introduced by the command PHD (Print Host Data).

    <CDE> = DATA request = 1 (0x01).

7.2 Printer response messages

   These messages are used to report the printing end status of the
   printer data request previously received.

   The following command values are defined as:

    <CDE> = ACK response indication = 10 (0x0A). The printer data
    previously received have been well processed.

    <CDE> = ERR response indication = 14 (0x0E). The printer data
    previously received have not been correctly processed (invalid
    command, buffer overflow , printer off...)

    <CDE> = BUSY response indication = 18 (0x12). The printer data
    received have been deleted because the previous printing request is



Dujonc                       Informational                     [Page 18]

RFC 1921                     TNVIP Protocol                   March 1996


    not ended. Several printer data request messages have been sent
    without waiting for the response.

    <CDE> = ABORTED  response indication = 22 (0x14). The printing has
    been aborted by the terminal operator.

    <CDE> = PURGED response indication = 26 (0x18). The printing request
    has been aborted by a printer data purge indication message.

    <CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The printer
    device is not supported.

    <CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
    printer request received has been deleted because an other printer
    request is already in process. That means several printer request
    messages have been sent without waiting for the response. It is a
    consequence of the non-compliance of the protocol. There is no
    parameter field.

    <CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The
    printer request received has been deleted because of an unknown
    <CDE> field value. It is a consequence of the non-compliance of the
    protocol. There is no parameter field.

    For all the above commands, the parameter field may contain
    specific terminal status if one was requested in the printer data
    received (response to PDENQ 7800 terminal presentation command).

7.3 7800 printer status management

   When emulating a 7800 terminal [8], the "TNVIP client" takes charge
   of adding to the printer data the printer differed status request
   (PDENQ 7800 command) to synchronize the printing end with the sending
   of the printer acknowledgement response.

   Some DSA applications are written to manage the 7800 printer status,
   so they send themselves the printer status request at the beginning
   of the printer data. That is the reason why when the "TNVIP client"
   receives this command at the beginning of the printer data, it must
   send back the 7800 status response in the parameter field of the
   printer data response message.

   The 7800 terminal presentation defines also immediate printer status
   request and response (PENQ which allows to get an immediate response
   indicating the current printer status). These commands have to be
   exchanged in the TNVIP screen data flow.





Dujonc                       Informational                     [Page 19]

RFC 1921                     TNVIP Protocol                   March 1996


7.4 Printer state request message

   This message is sent by the "TNVIP server" to know the printer state
   of the "TNVIP client" without sending printer data.

   The following command value is defined as:

    <CDE> = STATE-REQ request = 53 (0x35). There is no parameter field.

7.5 Printer state response messages

   These messages are sent by the "TNVIP client" in order to report the
   printer state to the "TNVIP server".

   The following command values are defined as:

    <CDE> = READY response indication = 58 (0x3A). The printer state is
    ready to print. There is no parameter field.

    <CDE> = STANDBY response indication = 62 (0x3E). The printer device
    is in standby and is temporarily unavailable. There is no parameter
    field.

    <CDE> = PURGED response indication = 26 (0x1A). The printer state
    request has been aborted by a printer state purge indication
    message. There is no parameter field.

    <CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The printer
    device is not supported. There is no parameter field.

    <CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
    printer state request received has been deleted because an other
    printer request is already in process. That means several printer
    request messages have been sent without waiting for the response. It
    is a consequence of the non-compliance of the protocol. There is no
    parameter field.

    <CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The printer
    state request received has been deleted because the <CDE> field
    value is unknown. It is a consequence of the non-compliance of the
    protocol. There is no parameter field.

7.6 Printer purge indication message

   This message is used by the "TNVIP server" to purge the current
   printer request message. When the "TNVIP client" receives this
   message, if it has not already acknowledged the printer data, it
   aborts the printing and returns a printer data purge acknowledgement



Dujonc                       Informational                     [Page 20]

RFC 1921                     TNVIP Protocol                   March 1996


   response message. If it has already replied, it ignores and deletes
   the message.

   The printer purge command value is defined as:

    <CDE> = PURGE indication = 40 (0x28). There is no parameter field.

8. The Screen Copy Printing flow

   All the following messages contain the SCPM address value 105 (0x69)
   in the ADR field. The support of this address is mandatory.

8.1 Screen copy request messages

   As the printer device can be used by the "TNVIP server", if the
   terminal user wishes a screen copy printing, the "TNVIP" client has
   to synchronize the user request with the "TNVIP server" printing .

   The TNVIP protocol defines that the "TNVIP client" has to inform the
   "TNVIP server" when it wants to print a screen copy and waits for its
   authorization before beginning

   The following command values are defined as:

    <CDE> = COPY-REQ request = 65 (0x41). It is used from the "TNVIP
    client" to the "TNVIP server" to request a screen copy printing.

    <CDE> = LOCAL-COPY response and request = 71 (0x47). It is sent by
    the "TNVIP server" to acknowledge the COPY-REQ message indicating
    the screen copy can be done locally. It is also a request message
    because it is equivalent to a screen copy data request message and
    the "TNVIP server" is waiting for a screen copy response message
    from the "TNVIP client" but on the SCPM flow. There is no parameter
    field.

8.2 Screen copy data message

   They are defined in order to transport in the parameter of the
   message the screen copy data in the terminal presentation. It is used
   by the "TNVIP client" when it wants to send the screen copy data
   directly to the DSA application (a VIP terminal using a VIP
   transmission procedure indicates this special request by the STA byte
   =PRT=0x1A).








Dujonc                       Informational                     [Page 21]

RFC 1921                     TNVIP Protocol                   March 1996


   The parameter field has the following format:

    <FC1> <FC2> <STX> <screen-copy-data>

    - The FC1, FC2 bytes are the functions codes of the VIP procedure
      transmission. Their values are ranged from 32 (0x20) to 127
      (0x7F) included.

    - The STX byte is defined by the value 2 and acts as the introducer
      of the screen data.

   Screen copy data message can be sent in a request or indication
   message.

   The command values are defined as follows:

    <CDE> = DATA indication = 0

    <CDE> = DATA request = 1

8.3 Screen copy response messages

   These messages are sent by the "TNVIP client" (local copy) to report
   the end of printing status of the screen copy.

   The ACK response is also used by the "TNVIP server" to acknowledge a
   screen copy data request sent to the host application.

   The ERR message is also used by the server to refuse a COPY-REQ
   message.

   The following command values are defined as:

    <CDE> = ACK response indication = 10 (0x0A). The "TNVIP client"
    reports the screen copy has been well printed or the "TNVIP server"
    acknowledges the screen copy data request. There is no parameter
    field.

    <CDE> = ERR response indication = 14 (0x0E). The screen copy has not
    been correctly printed (invalid command, buffer overflow ...) or has
    been refused by the "TNVIP server". It can optionally contain a
    reason code value defined on one byte.

    - 1 : The printer is busy, retry later.

    <CDE> = BUSY response indication = 18 (0x12). The screen copy has
    not been correctly printed because the printer device is already
    printing. There is no parameter field.



Dujonc                       Informational                     [Page 22]

RFC 1921                     TNVIP Protocol                   March 1996


    <CDE> = ABORTED  response indication =22 (0x16). The screen copy has
    been aborted by the terminal operator. There is no parameter field.

    <CDE> = PURGED response indication = 26 (0x1A). The screen copy
    request message has been aborted by a purge indication message.
    There is no parameter field.

    <CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The screen
    copy has not been correctly printed because the printer device is
    not supported. There is no parameter field.

    <CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
    screen copy request received has been deleted because an other
    screen copy request is already in process. That means several screen
    copy request messages have been sent without waiting for the
    response. It is a consequence of the non-compliance of the protocol.
    There is no parameter field.

    <CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The screen
    copy request received has been deleted because the <CDE> field value
    is unknown. It is a consequence of the non-compliance of the
    protocol. There is no parameter field.

8.4 Screen copy purge indication message

   This message is used to purge the current screen copy request
   message. When the "TNVIP server" or the "TNVIP client" receives this
   message, if it has not already acknowledged the request message, it
   returns a screen copy purge acknowledgement message. If it has
   already replied, it ignores and deletes the message.

   The following command value is defined as:

    <CDE> = PURGE indication = 40 (0x28).There is no parameter field.

9. The TM attention

   The TM attention is the signal used to activate the local dialog of
   the DSA Terminal Manager.

   The Telnet Abort Output (AO) command [1] is the mechanism used to
   implement the TM attention key support in TNVIP.

   IAC AO (0xFF 0xF5)

   In order to implement the TM attention key support, "TNVIP clients"
   should provide a key (or combination of keys) that is identified as
   mapping to the TM attention key. When the user presses this key(s),



Dujonc                       Informational                     [Page 23]

RFC 1921                     TNVIP Protocol                   March 1996


   the "TNVIP client" should transmit a Telnet AO command to the "TNVIP
   server".

   Upon receipt of the AO command, a "TNVIP server" that implements the
   DSA Terminal Manager should enter in what will be loosely termed "TM
   Local Dialog", suspending the eventual DSA host connection, else it
   should simply ignore it.

10. The Break Key

   Generally, there is no break key on the real VIP terminal. The break
   signal is transmitted to the host application through a TM local
   dialog command ($*$BRK for example)

   On "TNVIP client" emulating VIP terminal, it is often possible to map
   the break signal on a special key combination or by other way (using
   mouse ...).

   The Telnet Break (BRK) command [1] is used to map the Break signal of
   the TNVIP.

   IAC BRK (0xFF 0xF3)

11. The Logout Key

   The Telnet Interrupt Process (IP) command [1] can be used to map the
   logout command of the TM Local Dialog ($*$LO for example) if it is
   implemented on the "TNVIP server".

   IAC IP (0xFF 0xF4)

12. TNVIP messages list

   All the TNVIP commands are summarized here after (and the values are
   given in hexadecimal).

12.1 Screen Flow

   Data request (allowed in the two ways)

    SCREEN DATA-REQ <FC1> <FC2> STX [<screen-data>]  IAC EOR
    60     01       <FC1> <FC2> 02  [<screen-data>]  FF  EF

    - Allowed responses to the screen Data request.

      SCREEN ACK  IAC EOR
      60     0A   FF  EF




Dujonc                       Informational                     [Page 24]

RFC 1921                     TNVIP Protocol                   March 1996


      SCREEN ERROR  IAC EOR
      60     0E     FF  EF

      SCREEN BUSY  IAC EOR
      60     12    FF  EF

      SCREEN ABORTED  IAC EOR
      60     16       FF  EF

      SCREEN PURGED  IAC EOR
      60     1A      FF  EF

   Password request (only from the "TNVIP server" to the "TNVIP client")

    SCREEN PASSW-REQ <FC1> <FC2> STX [<screen-data>]  IAC EOR
    60     05        <FC1> <FC2> 02  [<screen-data>]  FF  EF

    - Allowed responses to the password request.

      SCREEN ACK  IAC EOR
      60     0A   FF  EF

      SCREEN ERROR  IAC EOR
      60     0E     FF  EF

      SCREEN BUSY  IAC EOR
      60     12    FF   EF

      SCREEN ABORTED  IAC EOR
      60     16       FF  EF

      SCREEN PURGED  IAC EOR
      60     1A      FF  EF

   Local state request (only from the "TNVIP client" to the "TNVIP
   server").

    SCREEN LOCAL-ST IAC EOR
    60     2D       FF  EF

    - Allowed responses to the Local state request.

      SCREEN ACK  IAC EOR
      60     0A   FF  EF

      SCREEN PURGED  IAC EOR
      60 1A FF EF




Dujonc                       Informational                     [Page 25]

RFC 1921                     TNVIP Protocol                   March 1996


   Responses to request violating the TNVIP protocol (allowed in the two
   ways)

    SCREEN NOT-AVAIL  IAC EOR
    60     0E         FF  EF

    SCREEN PROT-VIOL  IAC EOR
    60     22         FF  EF

    SCREEN UNKN-CDE  IAC EOR
    60     26        FF  EF

   Indications (allowed in the two ways)

    SCREEN DATA-IND <FC1> <FC2> STX [<screen-data>]  IAC EOR
    60     00       <FC1> <FC2> 02  [<screen-data>]  FF  EF

    SCREEN PURGE  IAC EOR
    60     28     FF  EF

   Password indication (only from the "TNVIP server" to the "TNVIP
   client").

    SCREEN PASSW-IND <FC1> <FC2> STX [<screen-data>]  IAC EOR
    60     04        <FC1> <FC2> 02  [<screen-data>]  FF  EF

   On line state indication (only from the "TNVIP client" to the "TNVIP
   server").

    SCREEN ONLINE-ST  IAC EOR
    60     30         FF  EF

12.2 Printer flow

   Data request (only from the "TNVIP server" to the "TNVIP client")

    PRINTER DATA-REQ <FC1> <FC2> STX [<printer-data>]  IAC EOR
    68 01 <FC1> <FC2> 02 [<printer-data>] FF EF

    - Allowed responses to the printer data request.

      PRINTER ACK [<status>]  IAC EOR
      68      0A  [<status>]  FF  EF

      PRINTER ERROR  [<status>] IAC EOR
      68      0E     [<status>] FF  EF





Dujonc                       Informational                     [Page 26]

RFC 1921                     TNVIP Protocol                   March 1996


      PRINTER BUSY [<status>]  IAC EOR
      68      12   [<status>]  FF  EF

      PRINTER ABORTED  [<status>] IAC EOR
      68      16       [<status>] FF  EF

      PRINTER PURGED  [<status>] IAC EOR
      68      1A      [<status>] FF  EF

      PRINTER NOT-AVAIL  [<status>] IAC EOR
      68      1E         [<status>] FF  EF

   State request (only from the "TNVIP server" to the "TNVIP client")

    PRINTER STATE-REQ  IAC EOR
    68      35         FF  EF

    - Allowed responses to the state request.

      PRINTER READY  IAC EOR
      68      3A     FF  EF

      PRINTER STANDBY  IAC EOR
      68      3E       FF  EF

      PRINTER PURGED  IAC EOR
      68      1A      FF  EF

      PRINTER NOT-AVAIL  IAC EOR
      68      1E         FF  EF

   Responses to request violating the TNVIP protocol (allowed in the two
   ways)

    PRINTER PROT-VIOL  IAC EOR
    68      22         FF  EF

    PRINTER UNKN-CDE  IAC EOR
    68      26        FF  EF

   Indication (only from the "TNVIP server" to the "TNVIP client")

    PRINTER PURGE  IAC EOR
    68 28 FF EF







Dujonc                       Informational                     [Page 27]

RFC 1921                     TNVIP Protocol                   March 1996


12.3 Screen Copy Printing messages flow

   Copy request (only from the "TNVIP client" to the "TNVIP server")

    SCPM COPY-REQ  IAC EOR
    69   41        FF  EF

    - Allowed responses to the copy request (from the "TNVIP server" to
      the "TNVIP client")

      SCPM  ERROR  <reason> IAC EOR
      69    0E     <reason> FF  EF

      SCPM  PURGED  IAC EOR
      69    1A      FF  EF

      SCPM  NOT-AVAIL  IAC EOR
      69    1E         FF  EF

      SCPM  LOCAL-COPY-RQ   IAC EOR
      69    47              FF  EF

   Local copy request (only from the "TNVIP server" to the "TNVIP
   client" )

    SCPM  LOCAL-COPY-RQ   IAC EOR
    69    47              FF  EF

    - Allowed responses to the local copy request (from the "TNVIP
      client" to the "TNVIP server").

      SCPM ACK  IAC EOR
      69   0A   FF  EF

      SCPM ERROR  IAC EOR
      69   0E     FF  EF

      SCPM BUSY IAC EOR
      69   12   FF  EF

      SCPM ABORTED IAC EOR
      69   16      FF  EF

      SCPM PURGED IAC EOR
      69   1A     FF  EF

      SCPM NOT-AVAIL IAC EOR
      69   1E        FF  EF



Dujonc                       Informational                     [Page 28]

RFC 1921                     TNVIP Protocol                   March 1996


   Data request. (only from the "TNVIP client" to the "TNVIP server")

    SCPM DATA-REQ <FC1> <FC2> STX [<screen-data>]  IAC EOR
    69   01       <FC1> <FC2> 02  [<screen-data>]  FF  EF

   - Allowed responses to the data request

      SCPM ACK  IAC EOR
      69   0A   FF  EF

      SCPM PURGED IAC EOR
      69   1A     FF  EF

      SCPM NOT-AVAIL IAC EOR
      69   1E        FF  EF

   Responses to request violating the TNVIP protocol (allowed in the two
   ways)

    SCPM PROT-VIOL  IAC EOR
    69   22         FF  EF

    SCPM UNKN-CDE  IAC EOR
    69   26        FF  EF

    Indications (allowed in the two ways)

    SCPM DATA-IND <FC1> <FC2> STX [<screen-data>]  IAC EOR
    69   00       <FC1> <FC2> 02  [<screen-data>]  FF  EF

    SCPM PURGE  IAC EOR
    69   28     FF  EF

13.  Security Considerations

   Security issues are not addressed in this document.  It is
   anticipated that once authentication mechanisms have become well
   established, use of them can be made by TNVIP.  One of the important
   uses of authentication would be to answer the question of whether or
   not a given user should be allowed to "use" a specific terminal.











Dujonc                       Informational                     [Page 29]

RFC 1921                     TNVIP Protocol                   March 1996


14. References

   [1] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD
       8, RFC 854, USC/Information Sciences Institute, May 1983.

   [2] "Communications. MainWay. Terminal Management. DNS-E",
       Ref : 39A213EB Rev00, BULL S.A.

   [3] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP
       Software, Inc., February 1989.

   [4] Postel, J., "Telnet End of Record Option", RFC 885,
       USC/Information Sciences Institute, December 1983.

   [5] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD
       27, RFC 856, USC/Information Sciences Institute, May 1983.

   [6] Postel, J., and J. Reynolds, "Telnet Suppress Go Ahead Option",
       STD 29, RFC 858, USC/Information Sciences Institute, May 1983.

   [7] "Affinity V2. DKU7107 Reference Manual"
       Ref : 40 A2 23 WA, BULL S.A.

   [8] "Affinity V2. VIP7800 Reference Manual"
       Ref : 40 A2 24 WA,  BULL S.A.

   [9] "Bull Questar 200. TCS 7424 et TCS 7434. Transmission de donnees.
       Manuel de  reference"
       Ref : 80 F2 41DC Rev0,  BULL S.A.

15. Author's Address

   Jean-Yves Dujonc
   BULL S.A.
   rue Jean Jaures
   78340 Les Clayes-sous-Bois
   France

   Phone: 1 30 80 62 95
   Fax:   1 30 80 65 40
   EMail: J.Y.Dujonc@frcl.bull.fr










Dujonc                       Informational                     [Page 30]