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
|
<pre>Network Working Group J. Penner
Request for Comments: 1576 DCA, Inc.
Category: Informational January 1994
<span class="h1">TN3270 Current Practices</span>
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 describes the existing implementation of transferring
3270 display terminal data using currently available telnet
capabilities. The name traditionally associated with this
implementation is TN3270.
Information is provided to aid in the implementation of TN3270
servers as well as client terminal emulators.
The following areas pertaining to TN3270 implementations are covered
in this document:
1. the telnet options negotiated to transition from a NVT ASCII
state to a TN3270 state ready to process incoming 3270 data
stream commands
2. the method for sending and receiving 3270 data
3. the method of handling some special keys known as SYSREQ and
ATTN using current available telnet commands
4. the events that will transition a TN3270 session back to an NVT
session
Table of Contents
<a href="#section-1">1</a>. Motivation . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Background . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-3">3</a>. Telnet Options and Commands Used . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Connection Negotiation . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.1">4.1</a> 3270 Regime Option . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a> Suppress Go Ahead Option . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.3">4.3</a> Echo Option . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.4">4.4</a> Timing Mark Option . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<span class="grey">TN3270 Enhancements Working Group [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1576">RFC 1576</a> TN3270 Current Practices January 1994</span>
<a href="#section-5">5</a>. Testing for session presence . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. Handling 3270 data . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7">7</a>. 3270 Structured Fields . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8">8</a>. The 3270 ATTN (Attention) Key . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-9">9</a>. The 3270 SYSREQ Key . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10">10</a>. Items not addressed by TN3270 . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-12">12</a>. Security Considerations . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-13">13</a>. Author's Note . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-14">14</a>. Author's Address . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Motivation</span>
3270 display terminal data differs from traditional display terminal
data in that it is block mode and uses EBCDIC instead of ASCII
character representation. These two differences are the primary
reason for the differentiation of TN3270 from standard Telnet in this
document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Background</span>
Existing complex IBM 3270 display terminal networks are not easily
integrated with the increasing number of multi-platform networking
environments, specifically TCP/IP. These complex networks include
terminals attached to a 3270 host using SNA (Systems Network
Architecture) and non-SNA connections. To address the issue of easily
connecting display terminals to 3270 hosts using IP networks, several
vendors have introduced telnet servers that provide TCP/IP users a
connection to existing IBM mainframes by supporting display terminal
emulation using a subset of the existing telnet protocol. Telnet
servers may exist on the host itself, or be connected to the host
using SNA or non-SNA methods.
IBM terminals are generically referred to as 3270's which includes a
broad range of terminals and devices, not all of which actually begin
with the numbers 327x.
3270 terminals in the IBM SNA network environment have two sessions
with the host computer application. One is used for communicating
with the host application, the other is used for communicating with
the SSCP (System Services Control Point) that links the terminal with
the appropriate host computer. For the purposes of TN3270, this
distinction is not apparent or relevant since there is actually only
a single telnet session with the host computer or server. On an IBM
SNA network, the 3270 terminal has a special key that toggles between
the two sessions (SYSREQ). A brief discussion on how some telnet
servers deal with this is included.
<span class="grey">TN3270 Enhancements Working Group [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1576">RFC 1576</a> TN3270 Current Practices January 1994</span>
In an SNA environment, a client session is identified by a Logical
Unit (LU) name. In a non-SNA environment, there is not a LU name
associated with a client session. The closest thing to a LU name in
the TN3270 environment is the client's IP address. Although some
telnet servers are connected to the host using SNA, TN3270 clients
using these servers have no defined way to determine the LU name
associated with the session.
Telnet servers that exist in non-SNA environments do not have to be
concerned about providing TN3270 clients with support for the SNA
functions described in this document.
TN3270 does not support typical SNA responses and is classified as a
non-SNA protocol. A TN3270 emulator is not aware or concerned about
how the telnet server is connected to a 3270 host application.
NOTE: Except where otherwise stated, this document does not
distinguish between telnet servers that represent SNA devices and
those that represent non-SNA 3270 devices.
Some typical "SNA" functions such as the SYSREQ and ATTN keys have
been mapped to existing telnet commands and are supported by some
telnet server implementations.
Currently, support for 3270 terminal emulation over Telnet is
accomplished by the de facto standard of negotiating three separate
Telnet Options - Terminal-Type [<a href="#ref-2" title=""Telnet Terminal-Type Option"">2</a>], Binary Transmission [<a href="#ref-3" title=""Telnet Binary Transmission"">3</a>], and End
of Record [<a href="#ref-4" title=""Telnet End of Record Option"">4</a>]. This negotiation and the resulting data flow will be
described below.
<a href="./rfc1041">RFC 1041</a> [<a href="#ref-1" title=""Telnet 3270 Regime Option"">1</a>] attempted to standardize the method of negotiating 3270
terminal support by defining the 3270 Regime Telnet Option.
Historically, very few developers and vendors ever implemented <a href="./rfc1041">RFC</a>
<a href="./rfc1041">1041</a>.
All references in this document to the 3270 datastream, SNA versus
non-SNA operation, 3270 datastream commands, orders, structured
fields and the like rely on [<a href="#ref-6" title=""3270 Information Display System - Data Stream Programmer's Reference"">6</a>].
References to SNA Request and Response Units rely on [<a href="#ref-7" title=""Systems Network Architecture - Formats"">7</a>]. References
to SNA and SSCP rely on [<a href="#ref-12" title=""Systems Network Architecture - Concepts and Products"">12</a>].
<span class="grey">TN3270 Enhancements Working Group [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1576">RFC 1576</a> TN3270 Current Practices January 1994</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Telnet Options and Commands Used</span>
TN3270 makes use of existing Telnet options and does not define any
additional options or commands.
Telnet option Value (decimal)
------------- ---------------
BINARY 0
TERMINAL-TYPE 24
EOR 25
Additional options may be used during a TN3270 session and are
interpreted as per their respective RFCs. These are [<a href="#ref-1" title=""Telnet 3270 Regime Option"">1</a>] 3270-REGIME,
[<a href="#ref-8" title=""Telnet Suppress Go Ahead Option"">8</a>] SUPPRESS-GO-AHEAD, [<a href="#ref-9" title=""Telnet Echo Option"">9</a>] ECHO and [<a href="#ref-10" title=""Telnet Timing Mark Option"">10</a>] TIMING-MARK. Other options
should be rejected unless they are specifically handled by the client
for NVT mode.
Commands that may be encountered during a TN3270 session and are
described in <a href="./rfc854">RFC 854</a> [<a href="#ref-11" title=""Telnet Protocol Specification"">11</a>] include NOP, BREAK and Interrupt Process.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Connection Negotiation</span>
The following example shows a TN3270-capable server and a TN3270
client establishing a connection:
The TCP/IP port used to connect with is 23 (Telnet).
At any place before and during the TN3270 connection negotiation
process, other telnet commands and data may be transferred and will
be interpreted under the existing telnet state. Some existing TN3270
servers start a client connection using an NVT telnet dialog to
establish parameters needed to complete the TN3270 connection to the
desired host.
The order of negotiating terminal type, EOR and BINARY is not
significant, this example shows a typical TN3270 connection.
Server: IAC DO TERMINAL-TYPE
Client: IAC WILL TERMINAL-TYPE
Server: IAC SB TERMINAL-TYPE SEND IAC SE
Client: IAC SB TERMINAL-TYPE IS <terminal type>IAC SE
where <terminal type> is a string consisting of terminal model,
type and support of enhanced attribute bytes; an example is IBM-
3278-2. The acceptable values are listed in <a href="./rfc1340">RFC 1340</a>, Assigned
<span class="grey">TN3270 Enhancements Working Group [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc1576">RFC 1576</a> TN3270 Current Practices January 1994</span>
Numbers [<a href="#ref-5" title=""Assigned Numbers"">5</a>]. Other values are in use that do not exist in [<a href="#ref-5" title=""Assigned Numbers"">5</a>].
The -2 following 3278 designates the alternate screen size. 3270
terminals have the ability to switch between the standard (24x80)
screen size and an alternate screen size. Model -2 is 24x80 which
is the same as the standard size. Model -3 is 32x80, model -4 is
43x80 and model -5 is 27x132.
Appending the two character string "-E" to the end of the terminal
type signifies that the terminal is capable of handling 3270
extended data stream. This is interpreted to mean that the
terminal is able to handle structured fields, which are described
below. Some telnet server implementations also interpret this to
mean that the terminal is capable of handling extended attributes
(highlighting, field validation, character set, outlining, etc.)
[<a href="#ref-6" title=""3270 Information Display System - Data Stream Programmer's Reference"">6</a>].
The 3279 series of terminals is capable of extended attributes
while the 3278 series is not.
Server: IAC DO EOR IAC WILL EOR
Client: IAC WILL EOR IAC DO EOR
Server: IAC DO BINARY IAC WILL BINARY
Client: IAC WILL BINARY IAC DO BINARY
Server: <3270 data stream> IAC EOR
Client: <3270 data stream> IAC EOR
. .
. .
To terminate the connection the socket is closed by one of the
session partners. Typically, when the user logs off of the host, the
telnet server closes the connection.
If the telnet server wishes to go back to NVT mode, it may issue the
following telnet options:
Server: IAC WONT BINARY
Client: IAC DONT BINARY
or
Server: IAC WONT EOR
Client: IAC DONT EOR
Either one of the above two cases causes the connection to not
satisfy the requirements for a valid TN3270 session. The telnet
client would then process data from the server as though it were NVT
ASCII data.
<span class="grey">TN3270 Enhancements Working Group [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc1576">RFC 1576</a> TN3270 Current Practices January 1994</span>
The following examples show how a TN3270 client handles the 3270-
REGIME, SUPPRESS-GO-AHEAD, ECHO and TM options.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> 3270 Regime Option</span>
Very few servers support the 3270 Regime Telnet Option. If the
client does not support this option and responds negatively as shown
in the following example, the server will proceed on to the more
typical example shown above.
Server: IAC DO 3270-REGIME
Client: IAC WONT 3270-REGIME
Normal negotiation:
Server: IAC DO TERMINAL-TYPE
... (see above)
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a> Suppress Go Ahead Option</span>
The Suppress Go Ahead option [<a href="#ref-8" title=""Telnet Suppress Go Ahead Option"">8</a>] is requested by some servers. The
Suppress Go Ahead option RFC lists the default as being go aheads are
transmitted to signal the receiver to begin transmitting. Since
TN3270 negotiates binary and end-of-record and is a block mode
protocol, the telnet go ahead character is not sent. Most servers do
not negotiate this option even though they do not use the telnet go
ahead character.
Server: IAC DO SUPPRESS-GO-AHEAD
Client: IAC WILL SUPPESS-GO-AHEAD
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a> Echo Option</span>
The Echo option [<a href="#ref-9" title=""Telnet Echo Option"">9</a>] is negotiated by those servers that make use of
the telnet NVT mode to allow the user to enter information prior to
negotiating the options necessary for TN3270. This information
includes but is not limited to user identification, password and
destination 3270 host. Some servers accept the default for this
option which is for the client to not do a local echo of characters
the user enters at the keyboard. This allows the server to decide if
it should echo characters back to the client (or not in the case of
password). Echoing characters back to the client causes slow response
time since every character is typically echoed individually. Because
of this, some servers negotiate for the client to do it's own local
echoing (except for passwords). The following example illustrates
this case.
<span class="grey">TN3270 Enhancements Working Group [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc1576">RFC 1576</a> TN3270 Current Practices January 1994</span>
Server: IAC DO ECHO
Client: IAC WILL ECHO
(Client does local display of all characters)
Server: IAC WONT ECHO
Client: IAC DONT ECHO
(Client enters password - not locally displayed or remotely
echoed)
Server: IAC DO ECHO
Client: IAC WILL ECHO
(Client resumes local display of all characters)
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a> Timing Mark Option</span>
The Timing Mark option [<a href="#ref-10" title=""Telnet Timing Mark Option"">10</a>] is used by some servers to test for the
continued presence of a TN3270 client. The following example will
assure the server the client is still alive.
Server: IAC DO TIMING-MARK
Client: IAC WONT TIMING-MARK
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Testing for session presence</span>
The NOP command (hexadecimal F1) [<a href="#ref-11" title=""Telnet Protocol Specification"">11</a>] is used by some servers to test
for the continued presence of a TN3270 client. If a client has
terminated abnormally, TCP/IP send errors will occur. The Timing Mark
option, described above, is also used to test for presence.
Server: IAC NOP
Client: <ignore / no response>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Handling 3270 data</span>
The 3270 data stream consists of a command and its associated data.
Commands include but are not limited to erase screen, erase and write
to screen and read current screen; see [<a href="#ref-6" title=""3270 Information Display System - Data Stream Programmer's Reference"">6</a>] for a complete description
of 3270 commands and parameters.
The reason for negotiating the EOR telnet option [<a href="#ref-4" title=""Telnet End of Record Option"">4</a>] is to provide a
method for separating these commands since no length information is
specified. 3270 commands are interpreted by the telnet client in
their entirety. Each 3270 command and possible data is terminated
with the IAC EOR sequence.
The Binary option [<a href="#ref-3" title=""Telnet Binary Transmission"">3</a>] is also required since 3270 data may contain
the FF (hexadecimal) or IAC character. When this character is
encountered during a TN3270 connection it is handled as per the
Binary RFC [<a href="#ref-3" title=""Telnet Binary Transmission"">3</a>].
<span class="grey">TN3270 Enhancements Working Group [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc1576">RFC 1576</a> TN3270 Current Practices January 1994</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. 3270 Structured Fields</span>
3270 structured fields provide a much wider range of features than
"old-style" 3270 data, such as support for graphics, partitions and
IPDS printer datastreams. A structured field is a 3270 data type that
allows non 3270 data to be embedded within 3270 data. Briefly, a
structured field consists of the structured field command followed by
one or more data blocks. Each data block has a length and a
structured field identifier, followed optionally by additional data.
Not every TN3270 client can be expected to support all structured
field functions. There must be a mechanism by which those clients
that are capable of supporting some or all structured field functions
can indicate their wishes. This is typically done by adding "-E" to
the end of the terminal type string. That is, when the terminal
identifies itself as being able to handle extended attributes, it
also is capable of being able to send and receive structured fields.
The design of 3270 structured fields provides a convenient means to
convey the level of support (including no support) for the various
structured field functions. This mechanism is the Read Partition
Query command, which is sent from the host application to the client.
The client responds with a Query Reply, listing which, if any,
structured field functions it supports.
A TN3270 client that supports structured fields will respond to a
Read Partition Query command with the appropriate reply. The
sequence of events when a client receives a Read Partition Query and
does not support structured fields is left up to the client
implementation. Typically clients can identify at least this
structured field and reply with a null set.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. The 3270 ATTN (Attention) Key</span>
The 3270 ATTN key is interpreted by many host applications in an SNA
environment as an indication that the user wishes to interrupt the
execution of the current process. A majority of the telnet servers
currently accept the telnet IAC BREAK (code 243) [<a href="#ref-11" title=""Telnet Protocol Specification"">11</a>] sequence to
signal this event.
Use of this key requires two things:
- The TN3270 clients provide as part of their keyboard
mapping a single key or a combination of keys that map to
the 3270 ATTN key. When the user presses this key(s), the
client transmits a Telnet BREAK command to the server.
<span class="grey">TN3270 Enhancements Working Group [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc1576">RFC 1576</a> TN3270 Current Practices January 1994</span>
- The TN3270 servers translate the BREAK command received from
a TN3270 client into the appropriate form and pass it along
to the host application as an ATTN key. In other words, the
server representing an SLU in an SNA session would send
a SIGNAL RU to the host application.
The ATTN key is not supported in a non-SNA environment; therefore, a
TN3270 server representing non-SNA 3270 devices ignores any Telnet
BREAK commands it receives from a client.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. The 3270 SYSREQ Key</span>
The 3270 SYSREQ key is useful in an environment where the telnet
server is attached to the host using SNA. The SYSREQ key is useful in
this environment when the host application becomes locked or the user
wishes to terminate the session without closing the Telnet
connection.
The Telnet Interrupt Process (IP) command [<a href="#ref-11" title=""Telnet Protocol Specification"">11</a>] is interpreted by some
telnet servers as a SYSREQ key. Other servers recognize the 3270 Test
Request key as a SYSREQ key. In an SNA environment, pressing this
key toggles the terminal between the host application session and the
SSCP session. Usually the user will enter LOGOFF once this key has
been pressed to terminate the application session and then select a
new host to connect to. Sometimes, if SYSREQ is pressed again, the
host application will become unlocked and normal activities may then
proceed.
It is entirely up to the telnet server to interpret this command and
send the appropriate commands to the host as well as format the
resulting host data for display on the telnet client. The data format
during the SSCP session is in a slightly different format than normal
3270 data. Since the telnet server has no way to pass this data
directly to the telnet client, it must either handle it entirely and
ignore SYSREQ events or convert it to 3270 data to present to the
client.
To implement SYSREQ key support, TN3270 clients provide a key (or
combination of keys) that is identified as mapping to the 3270 SYSREQ
key. When the user presses this key(s), the client would either
transmit a Telnet IP command or Test Request key to the server,
depending on the server implementation.
TN3270 servers representing non-SNA 3270 terminals may ignore any
Telnet IP commands or Test Request keys they receive from a client.
<span class="grey">TN3270 Enhancements Working Group [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc1576">RFC 1576</a> TN3270 Current Practices January 1994</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Items not addressed by TN3270</span>
There are several items that are not supported by current TN3270
implementations; among them are the following:
- TN3270 provides no capability for clients to emulate the 328x
class of printers.
- There is no mechanism by which a Telnet client can request that
a connection be associated with a given 3270 device-name. This
can be of importance when a terminal session is being
established, since many host applications behave differently
depending on the network name of the terminal.
- The 3270 ATTN and SYSREQ keys are not universally supported.
- There is no support for the SNA positive/negative response
process. All data that is sent is assumed to either be handled
or ignored. The lack of SNA response processing in TN3270 is
part of what makes TN3270 efficient.
A negative response indicates some sort of error at the client
while processing the previously received data; this could be
caused by the host application building a 3270 datastream that
contains an invalid command, or by a mechanical error at the
client side, among other things.
Positive responses indicate processing of the previously received
data has completed.
- There is no mechanism by which the client can access the SNA
BIND information. The BIND image in a SNA environment
contains a detailed description of the session between the
telnet server and the host application.
- The connection negotiation does not make it clear whether
clients should support 3270 structured fields.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
[<a id="ref-1">1</a>] Rekhter, Y., "Telnet 3270 Regime Option", <a href="./rfc1041">RFC 1041</a>, IBM
Corporation, January 1988.
[<a id="ref-2">2</a>] VanBokkelen, J., "Telnet Terminal-Type Option", <a href="./rfc1091">RFC 1091</a>, FTP
Software, Inc., February 1989.
[<a id="ref-3">3</a>] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD
27, <a href="./rfc856">RFC 856</a>, USC/Information Sciences Institute, May 1983.
<span class="grey">TN3270 Enhancements Working Group [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc1576">RFC 1576</a> TN3270 Current Practices January 1994</span>
[<a id="ref-4">4</a>] Postel, J., "Telnet End of Record Option", <a href="./rfc885">RFC 885</a>,
USC/Information Sciences Institute, December 1983.
[<a id="ref-5">5</a>] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, <a href="./rfc1340">RFC 1340</a>,
USC/Information Sciences Institute, July 1992.
[<a id="ref-6">6</a>] "3270 Information Display System - Data Stream Programmer's
Reference", publication number GA23-0059, IBM Corporation.
[<a id="ref-7">7</a>] "Systems Network Architecture - Formats", publication number
GA27-3136, IBM Corporation.
[<a id="ref-8">8</a>] Postel, J., and J. Reynolds, "Telnet Suppress Go Ahead Option",
STD 29, <a href="./rfc858">RFC 858</a>, USC/Information Sciences Institute, May 1983.
[<a id="ref-9">9</a>] Postel, J., and J. Reynolds, "Telnet Echo Option", STD 28, <a href="./rfc857">RFC</a>
<a href="./rfc857">857</a>, USC/Information Sciences Institute, May 1983.
[<a id="ref-10">10</a>] Postel, J., and J. Reynolds, "Telnet Timing Mark Option", STD 31,
<a href="./rfc860">RFC 860</a>, USC/Information Sciences Institute, May 1983.
[<a id="ref-11">11</a>] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD
8, <a href="./rfc854">RFC 854</a>, USC/Information Sciences Institute, May 1983.
[<a id="ref-12">12</a>] "Systems Network Architecture - Concepts and Products",
publication number GC30-3072, IBM Corporation.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Security Considerations</span>
Security issues are not discussed in this memo.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Author's Note</span>
Portions of this document were drawn from the following sources:
- A White Paper written by Owen Reddecliffe, WRQ Corporation,
October 1991.
- Experimental work on the part of Cleve Graves and Michelle
Angel, OpenConnect Systems, 1992 - 1993.
- Discussions at the March 1993 IETF meeting and TN3270 BOF at
Interop August 1993.
- Discussions on the "TN3270E" list, 1993.
<span class="grey">TN3270 Enhancements Working Group [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc1576">RFC 1576</a> TN3270 Current Practices January 1994</span>
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. Author's Address</span>
Jon Penner
DCA, Inc.
2800 Oakmont Drive
Austin, TX 78664
Phone: (512) 388-7090 FAX
EMail: jjp@bscs.com
or dca/g=Jon/s=Penner/ou=DCAAUS@mhs.attmail.com
TN3270 Enhancements Working Group [Page 12]
</pre>
|
