draft-ietf-tn3270e-extensions-00.txt   draft-ietf-tn3270e-extensions-01.txt 
TN3270E Working Group G. Pullen TN3270E Working Group G. Pullen
Internet Draft: <draft-ietf-tn3270e-extensions-01.txt> M. Williams Internet-Draft: <draft-ietf-tn3270e-extensions-01.txt> M. Williams
Extends: RFC 2355 OpenConnect Systems Extends: RFC 2355 OpenConnect Systems
Expiration Date: October 1999 April 30, 1999 Expiration Date: November 2000 May 3, 2000
TN3270E Functional Extensions TN3270E Functional Extensions
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working Internet-Drafts are working documents of the Internet Engineering
documents of the Internet Engineering Task Force (IETF), its areas, Task Force (IETF), its areas, and its working groups. Note that
and its working groups. Note that the other groups may also other groups may also distribute working documents as
distribute working documents as Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced or made obsolete by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-
as reference material or to cite them other than as "work in Drafts as reference material or to cite them other than as
progress." "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
a session. This preserves backward compatibility between clients a session. This preserves backward compatibility between clients
and servers that do not support these features. and servers that do not support these features.
Among the issues to be address by this draft are SNA/TN3270E Among the issues to be address by this draft are SNA/TN3270E
Contention state resolution, SNA Sense Code support, Function Contention state resolution, SNA Sense Code support, Function
Management Header support, and TN3270E header byte-doubling Management Header support, and TN3270E header byte-doubling
suppression. suppression.
1. Table of Contents 1. Table of Contents
1. Table of Contents . . . . . . . . . . . . . . . . . . . . 2 1. Table of Contents . . . . . . . . . . . . . . . . . . . 2
2. Negotiated Function Codes . . . . . . . . . . . . . . . . 3 2. Negotiated Function Codes . . . . . . . . . . . . . . . 3
3. Negotiated Function Example . . . . . . . . . . . . . . . 3 3. Negotiated Function Example . . . . . . . . . . . . . . 3
4. Contention Resolution Function . . . . . . . . . . . . . . 4 4. Contention Resolution Function . . . . . . . . . . . . . 4
4.1 Keyboard Restore Problem . . . . . . . . . . . . . . . . . 4 4.1 Keyboard Restore Problem . . . . . . . . . . . . . . . . 4
4.2 Implied Keyboard Restore Problem . . . . . . . . . . . . . 4 4.2 Implied Keyboard Restore Problem . . . . . . . . . . . . 4
4.3 Bid Problem . . . . . . . . . . . . . . . . . . . . . . . 4 4.3 Bid Problem . . . . . . . . . . . . . . . . . . . . . . 4
4.4 Signal Problem . . . . . . . . . . . . . . . . . . . . . . 5 4.4 Signal Problem . . . . . . . . . . . . . . . . . . . . . 5
4.5 CONTENTION-RESOLUTION Implementation . . . . . . . . . . . 5 4.5 CONTENTION-RESOLUTION Implementation . . . . . . . . . . 5
4.5.1 SEND-DATA Indicator (SDI) . . . . . . . . . . . . . . . . 6 4.5.1 SEND-DATA Indicator (SDI) . . . . . . . . . . . . . . . 6
4.5.2 KEYBOARD-RESTORE Indicator (KRI) . . . . . . . . . . . . . 7 4.5.2 KEYBOARD-RESTORE Indicator (KRI) . . . . . . . . . . . . 7
4.5.3 BID Data Type . . . . . . . . . . . . . . . . . . . . . . 8 4.5.3 BID Data Type . . . . . . . . . . . . . . . . . . . . . 8
4.5.4 SIGNAL Indicator . . . . . . . . . . . . . . . . . . . . . 9 4.5.4 SIGNAL Indicator . . . . . . . . . . . . . . . . . . . . 9
5. Function Management Header (FMH) Support Function . . . . 12 5. Function Management Header (FMH) Support Function . . . 12
5.1 FMH Overview . . . . . . . . . . . . . . . . . . . . . . . 12 5.1 FMH Overview . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1 LU1 FMH1 Support . . . . . . . . . . . . . . . . . . . . . 13 5.1.1 LU1 FMH1 Support . . . . . . . . . . . . . . . . . . . . 13
5.1.2 Usage of DSSEL in FMH1 . . . . . . . . . . . . . . . . . . 13 5.1.2 Usage of DSSEL in FMH1 . . . . . . . . . . . . . . . . . 13
5.1.3 Structured Field Data Stream . . . . . . . . . . . . . . . 14 5.1.3 Structured Field Data Stream . . . . . . . . . . . . . . 14
5.1.4 IPDS Data Stream . . . . . . . . . . . . . . . . . . . . . 14 5.1.4 IPDS Data Stream . . . . . . . . . . . . . . . . . . . . 14
5.2 FMH Data Type . . . . . . . . . . . . . . . . . . . . . . 14 5.2 FMH Data Type . . . . . . . . . . . . . . . . . . . . . 14
5.3 Server Implementation . . . . . . . . . . . . . . . . . . 15 5.3 Server Implementation . . . . . . . . . . . . . . . . . 15
5.3.1 Bind Processing . . . . . . . . . . . . . . . . . . . . . 15 5.3.1 Bind Processing . . . . . . . . . . . . . . . . . . . . 15
5.3.2 Host/Server Flow . . . . . . . . . . . . . . . . . . . . . 15 5.3.2 Host/Server Flow . . . . . . . . . . . . . . . . . . . . 15
5.3.3 Client/Server Flow . . . . . . . . . . . . . . . . . . . . 16 5.3.3 Client/Server Flow . . . . . . . . . . . . . . . . . . . 16
5.3.4 FMH Responses . . . . . . . . . . . . . . . . . . . . . . 16 5.3.4 FMH Responses . . . . . . . . . . . . . . . . . . . . . 16
5.4 Client Implementation . . . . . . . . . . . . . . . . . . 17 5.4 Client Implementation . . . . . . . . . . . . . . . . . 17
6. SNA Sense Code Function . . . . . . . . . . . . . . . . . 18 6. SNA Sense Code Function . . . . . . . . . . . . . . . . 18
7. TN3270E Header Byte-doubling Suppression Function . . . . 19 7. TN3270E Header Byte-doubling Suppression Function . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . 20
9. Term Definitions . . . . . . . . . . . . . . . . . . . . . 20 9. Term Definitions . . . . . . . . . . . . . . . . . . . . 20
10. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 21 10. Abbreviations . . . . . . . . . . . . . . . . . . . . . 21
11. Conventions . . . . . . . . . . . . . . . . . . . . . . . 21 11. Conventions . . . . . . . . . . . . . . . . . . . . . . 21
12. Author's Note . . . . . . . . . . . . . . . . . . . . . . 22 12. Author's Note . . . . . . . . . . . . . . . . . . . . . 22
13. Author's Address . . . . . . . . . . . . . . . . . . . . . 22 13. Author's Address . . . . . . . . . . . . . . . . . . . . 22
2. Negotiated Function Codes 2. Negotiated Function Codes
To maintain backward compatibility with clients and servers that do To maintain backward compatibility with clients and servers that do
not support the extended TN3270E functions all new functionality not support the extended TN3270E functions all new functionality
will be negotiated. The current TN3270E function negotiation rules will be negotiated. The current TN3270E function negotiation rules
apply. Either side may request one or more of the extended apply. Either side may request one or more of the extended
functions by adding them to the function code list during TN3270E functions by adding them to the function code list during TN3270E
function negotiations. Either side may reject the function by function negotiations. Either side may reject the function by
removing it from the function list. removing it from the function list.
skipping to change at page 7, line 31 skipping to change at page 7, line 31
Function must be supported by and agreed upon by both the server and Function must be supported by and agreed upon by both the server and
Client during TN3270E function negotiations. KRI is only valid for Client during TN3270E function negotiations. KRI is only valid for
TN3270E terminals in PLU-SLU session (3270-DATA type mode). TN3270E terminals in PLU-SLU session (3270-DATA type mode).
KRI is meaningful only when sent by the server. KRI is sent in the KRI is meaningful only when sent by the server. KRI is sent in the
REQUEST-FLAG field of the TN3270E header. The KRI bit mask is: REQUEST-FLAG field of the TN3270E header. The KRI bit mask is:
KEYBOARD-RESTORE-MASK 0x02 KEYBOARD-RESTORE-MASK 0x02
A bit value of 1 (true) indicates to the client that its keyboard A bit value of 1 (true) indicates to the client that its keyboard
has been restored. The client's the X-CLOCK indicator is turned has been restored. The client's X-CLOCK indicator is turned off,
off, allowing the user to enter data. However, the client may not allowing the user to enter data. However, the client may not
send data to the server until it has also received SDI from the send data to the server until it has also received SDI from the
server (which may be set in the same REQUEST-FLAG field). server (which may be set in the same REQUEST-FLAG field).
Logically, the client treats KRI the same as it does the 3270 WCC Logically, the client treats KRI the same as it does the 3270 WCC
Keyboard Restore bit. KRI is not a replacement for the 3270 data Keyboard Restore bit. KRI is not a replacement for the 3270 data
stream WCC Keyboard Restore bit. The client must still track both stream WCC Keyboard Restore bit. The client must still track both
the KRI and 3270 WCC Keyboard Restore flag to determine the keyboard the KRI and 3270 WCC Keyboard Restore flag to determine the keyboard
state. Normally, one or the other will be received. However, the state. Normally, one or the other will be received. However, the
client should not balk if both are received on a 3270-DATA message. client should not balk if both are received on a 3270-DATA message.
skipping to change at page 8, line 30 skipping to change at page 8, line 30
data type to the client. data type to the client.
The server sends the new TN3270E BID data type to the client upon The server sends the new TN3270E BID data type to the client upon
receipt of either an implicit or an explicit BID from the host. The receipt of either an implicit or an explicit BID from the host. The
server must never send BID to the client when the host already has server must never send BID to the client when the host already has
direction (holds send state). direction (holds send state).
To send the BID data type the server inserts the BID data type in To send the BID data type the server inserts the BID data type in
the DATA-TYPE field of the TN3270E header, inserts a null (0x00) in the DATA-TYPE field of the TN3270E header, inserts a null (0x00) in
the REQUEST-FLAG field, inserts ALWAYS-RESPONSE (0x02) in the the REQUEST-FLAG field, inserts ALWAYS-RESPONSE (0x02) in the
RESPONSE-FLAG field and fills in an appropriate SEQ-NUMBER. An RESPONSE-FLAG field and fills in an appropriate SEQ-NUMBER. The server
should use the next number in the progression of sequence numbers. An
End-of-Record (EOR) is appended immediately after the TN3270E header End-of-Record (EOR) is appended immediately after the TN3270E header
(there is no data portion for a BID message). (there is no data portion for a BID message).
The BID data type must always receive a response from the client The BID data type must always receive a response from the client
regardless of whether the RESPONSES function is supported on the regardless of whether the RESPONSES function is supported on the
session. The SEQ-NUMBER is returned by the client in its response, session. The client's positive or negative response to a BID should
to allow the server to coordinate the response with the BID. If be exactly the same as those defined in the TN3270 Enhancements RFC,
RESPONSES has been negotiated the server should use the next number unless the SNA Sense Code Function (defined in section 6) is used by
in the progression of sequence numbers. If RESPONSES has not been the client to communicate a more specific code. The SEQ-NUMBER is
negotiated, the server can use any number it desires. When the returned by the client in its response, to allow the server to
server receives a BID response from the client, it is responsible coordinate the response with the BID.
for constructing the appropriate SNA response to the host.
When the client receives a BID message it is accepted by returning When the client receives a BID message it is accepted by returning
a positive response, or rejected by returning a negative response. a positive response, or rejected by returning a negative response.
The format of a positive response is the same as the positive The format of a positive response is the same as the positive
response defined for the TN3270E RESPONSES function (i.e., RESPONSE response defined for the TN3270E RESPONSES function (i.e., RESPONSE
data type, POSITIVE-RESPONSE code in RESPONSE-FLAG field, SEQ-NUMBER data type, POSITIVE-RESPONSE code in RESPONSE-FLAG field, SEQ-NUMBER
from BID). When the client accepts the BID the keyboard state goes from BID). When the client accepts the BID the keyboard state goes
to input inhibited, the client displays the X-CLOCK symbol and may to input inhibited, the client displays the X-CLOCK symbol and may
not send data until SDI is received from the server. not send data until SDI is received from the server.
When the server receives a BID response from the client, it is
responsible for constructing the appropriate SNA response to the host.
If the client already has buffered data to be sent to the host the If the client already has buffered data to be sent to the host the
client can reject the BID. The negative response uses the TN3270E client can reject the BID. The negative response uses the TN3270E
RESPONSES format (i.e., RESPONSE data type, NEGATIVE-RESPONSE code RESPONSES format (i.e., RESPONSE data type, NEGATIVE-RESPONSE code
in RESPONSE-FLAG field, SEQ-NUMBER from BID). Unless the client in RESPONSE-FLAG field, SEQ-NUMBER from BID). Unless the client
supports the SNA Sense Codes function, there is no defined reason supports the SNA Sense Codes function, there is no defined reason
information in the data portion of the negative response. The information in the data portion of the negative response. The
server rejects the host's BID with a "Bracket Bid Reject" sense code server rejects the host's BID with a "Bracket Bid Reject" sense code
(0x08130000). The client's send state should remain unchanged upon (0x08130000). The client's send state should remain unchanged upon
negatively responding to a BID (i.e. if send state is input negatively responding to a BID (i.e. if send state is input
inhibited, it stays that way). inhibited, it stays that way).
skipping to change at page 10, line 5 skipping to change at page 9, line 50
REQUEST-FLAG field of the TN3270E header. REQUEST-FLAG field of the TN3270E header.
The SIGNAL bit mask is: The SIGNAL bit mask is:
SIGNAL-MASK 0x04 SIGNAL-MASK 0x04
A bit value of 1 (true) indicates that a Signal has been received A bit value of 1 (true) indicates that a Signal has been received
from the PLU. Therefore the BID is "Forced" and the client MUST from the PLU. Therefore the BID is "Forced" and the client MUST
forfeit the send state. forfeit the send state.
The client must always respond to a BID with the SIGNAL indicator, as
described in the BID section. It is not necessary for the client to
echo the SIGNAL indicator in its response. However, the server
should not balk if the client does echo the SIGNAL indicator. The
server must maintain in it's state machine that it is awaiting a
response to a SIGNAL indicator.
When a Signal is received from the PLU the TN3270E Server's When a Signal is received from the PLU the TN3270E Server's
behavior may be summarized as follows: behavior may be summarized as follows:
Send +rsp to the host for the Signal Send positive response to the host for the Signal
If the host already has direction, or in contention state. . . If the host already has direction, or in contention state. . .
there is nothing more to do there is nothing more to do
Else client has direction. . . Else client has direction. . .
send BID w/ Signal to client and wait for reply or data send BID with Signal to client and wait for reply or data
If data received first. . . If data received first. . .
forward data to host as normal (will carry CD) forward data to host as normal (will carry CD)
Else response received first. . . Else response received first. . .
send null RU CD to Host (with BB if necessary) send null RU CD to Host (with BB if necessary)
Upon receipt of Signal from the host, the server returns positive Upon receipt of Signal from the host, the server returns positive
response to the host, regardless of whether the host or client holds response to the host, regardless of whether the host or client holds
direction. If the host holds direction (send state), there is direction. If the host holds direction (send state), there is
nothing more to be done. The client should already be awaiting data nothing more to be done. The client should already be awaiting data
from the host. from the host.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
sends a null RU with Change Direction (CD) to the host. The client sends a null RU with Change Direction (CD) to the host. The client
MUST return positive response to the server. If the client sends MUST return positive response to the server. If the client sends
negative response to a SIGNAL, even though it is not allowed to do negative response to a SIGNAL, even though it is not allowed to do
so, the server treats it as a positive response and handles it so, the server treats it as a positive response and handles it
accordingly. accordingly.
The Client's behavior when a BID containing the Signal indicator is The Client's behavior when a BID containing the Signal indicator is
summarized as: summarized as:
Receive BID with Signal indicator Receive BID with Signal indicator
If client has direction and buffered keystrokes w/ AID. . . If client has direction and buffered keystrokes with AID. . .
send first AID buffer send first AID buffer
Else host has direction (race condition) or no AID. . . Else host has direction (race condition) or no AID. . .
the buffered keystrokes are left unchanged the buffered keystrokes are left unchanged
Return positive response to Signal Return positive response to Signal
Enter X-CLOCK input inhibited mode Enter X-CLOCK input inhibited mode
Buffer any keystrokes/AID typed after the Signal Buffer any keystrokes/AID typed after the Signal
A Signal does not cause the client to purge any buffered keystrokes. A Signal does not cause the client to purge any buffered keystrokes.
If the client holds direction when the Signal is received, it may If the client holds direction when the Signal is received, it may
send one buffered AID message (if any) before sending positive send one buffered AID message (if any) before sending positive
response to the Signal. If the Host already had direction (race response to the Signal. If the Host already had direction (race
skipping to change at page 14, line 43 skipping to change at page 14, line 43
concat = 0 concat = 0
DSP = 0xD DSP = 0xD
DSSEL = BDS, EDS DSSEL = BDS, EDS
No data following FMH in the same chain. No data following FMH in the same chain.
Although no ADS is sent, an EB before EDS implicitly aborts the data Although no ADS is sent, an EB before EDS implicitly aborts the data
stream. stream.
5.2 FMH Data Type 5.2 FMH Data Type
To use the FMH data type the CONTENTION-RESOLUTION function must be To use the FMH data type the FMH-SUPPORT function must be
supported by and agreed upon by both the server and client during supported by and agreed upon by both the server and client during
TN3270E function negotiations. The FMH data type message is only TN3270E function negotiations. The FMH data type message is only
valid on LU1 printer sessions in SCS-DATA mode. The FMH data valid on LU1 printer sessions in SCS-DATA mode. The FMH data
type is not valid during SSCP-LU mode, NVT mode, or on terminal or type is not valid during SSCP-LU mode, NVT mode, or on terminal or
LU3 (DCS) printer sessions. The FMH DATA-TYPE code is defined as: LU3 (DCS) printer sessions. The FMH DATA-TYPE code is defined as:
Data-type Name Code Meaning Data-type Name Code Meaning
-------------- ---- ------------------------------------------- -------------- ---- -------------------------------------------
FMH-DATA 0x0A The sender indicates that the data portion FMH-DATA 0x0A The sender indicates that the data portion
of the message contains one or more Function of the message contains one or more Function
skipping to change at page 16, line 47 skipping to change at page 16, line 47
5.3.4 FMH Responses 5.3.4 FMH Responses
If SNA-SENSE-CODE is not supported, and the client returns a If SNA-SENSE-CODE is not supported, and the client returns a
negative response to a silent FMH (SCS-DATA) or FMH-DATA type, the negative response to a silent FMH (SCS-DATA) or FMH-DATA type, the
server is unable to determine whether the client objects to the FMH or server is unable to determine whether the client objects to the FMH or
the ensuing data. However, of the identified FMHs requiring support, the ensuing data. However, of the identified FMHs requiring support,
only the Structured Field Data Stream can have data in the same only the Structured Field Data Stream can have data in the same
chain. Even then, the cause of the rejection is likely to be that chain. Even then, the cause of the rejection is likely to be that
the client does not support FMHs. Therefore, it is recommended to the client does not support FMHs. Therefore, it is recommended to
the server interpret the negative response as a rejection of the FMH the server interpret the negative response as a rejection of the FMH
itself. The server should send -rsp with 0x10080000 Sense code to itself. The server should send negative response with 0x10080000
the Host. Sense code to the Host.
If SNA-SENSE-CODE is supported the server takes the first four bytes If SNA-SENSE-CODE is supported the server takes the first four bytes
of data following the TN3270E header as an SNA sense code and sends of data following the TN3270E header as an SNA sense code and sends
these, unchanged and unchecked, in the -rsp to the host application. these, unchanged and unchecked, in the negative response to the host.
There are many SNA sense codes associated with FMH errors that the There are many SNA sense codes associated with FMH errors that the
client may return. Most are at the application level and begin with client may return. Most are at the application level and begin with
0x1008. 0x1008.
In addition to codes previously defined, below are some common FMH In addition to codes previously defined, below are some common FMH
Sense codes: Sense codes:
Sense Code Cause Sense Code Cause
---------- ----- ---------- -----
0x10080000 Invalid parameters in FMH. 0x10080000 Invalid parameters in FMH.
skipping to change at page 21, line 13 skipping to change at page 21, line 13
------------------------------------------------------------- -------------------------------------------------------------
Type-ahead - Type-ahead -
is a state in which the client (terminal) may buffer keystrokes is a state in which the client (terminal) may buffer keystrokes
when the keyboard is an Input Inhibited state. Displayed when the keyboard is an Input Inhibited state. Displayed
keyboard state may be either X-CLOCK (Time) or X-SYSTEM (System keyboard state may be either X-CLOCK (Time) or X-SYSTEM (System
Lock). Keystrokes (text and AID keys) are buffered waiting for Lock). Keystrokes (text and AID keys) are buffered waiting for
send state to be returned to the client. send state to be returned to the client.
10. Abbreviations 10. Abbreviations
-rsp Negative response
+rsp Positive response
ADS Abort Destination Selection, value of DSSEL ADS Abort Destination Selection, value of DSSEL
BB Begin Bracket, byte 2 bit 0 of RH of BC RU BB Begin Bracket, byte 2 bit 0 of RH of BC RU
BC Begin chain, byte 0 bit 6 of RH BC Begin chain, byte 0 bit 6 of RH
BC RU An RU with BC = 1 BC RU An RU with BC = 1
BDS Begin Destination Selection, value of DSSEL BDS Begin Destination Selection, value of DSSEL
BEDS Begin and End Destination Selection, value of DSSEL BEDS Begin and End Destination Selection, value of DSSEL
DCA Document Content Architecture DCA Document Content Architecture
DSP Data-stream Profile, byte 3 bits 4-7 of FMH DSP Data-stream Profile, byte 3 bits 4-7 of FMH
DSSEL Destination Selection, byte 4 bits 0-2 of FMH DSSEL Destination Selection, byte 4 bits 0-2 of FMH
EB End Bracket, byte 2 bit 1 of RH of BC RU EB End Bracket, byte 2 bit 1 of RH of BC RU
skipping to change at page 22, line 10 skipping to change at page 22, line 10
11. Conventions 11. Conventions
- Byte order is big-endian, e.g. bit 0 is the most significant bit. - Byte order is big-endian, e.g. bit 0 is the most significant bit.
12. Author's Note 12. Author's Note
Portions of this document were drawn from the following sources: Portions of this document were drawn from the following sources:
- Contention Resolution proposal by Rodger Erickson (Wall Data). - Contention Resolution proposal by Rodger Erickson (Wall Data).
- SNA Sense Code and Function Management Header Support proposal by - SNA Sense Code and Function Management Header Support proposal
Derek Bolton (Cisco Systems). by Derek Bolton (Cisco Systems).
- TN3270E Byte-doubling Suppression proposal by Marty Williams - TN3270E Byte-doubling Suppression proposal by Marty Williams
(OpenConnect Systems). (OpenConnect Systems).
- Discussions on the TN3270E list and at the TN3270E/TN5250E - Discussions on the TN3270E list and at the TN3270E/TN5250E
Interoperability Events, 1997-1998. Particularly contributions by Interoperability Events, 1997-1998. Particularly contributions
Jim Mathewson II (IBM), Derek Bolton, and Michael Boe (Cisco by Jim Mathewson II (IBM), Derek Bolton, Michael Boe, and Diane
Systems). Henderson (Cisco Systems).
13. Author's Address 13. Author's Address
Gene Pullen email: gbp@openconnect.com Gene Pullen Marty Williams
Marty Williams email: mwilliam@openconnect.com gbp@openconnect.com martyw@cisco.com
OpenConnect Systems OpenConnect Systems Cisco Systems
2711 LBJ Freeway 2711 LBJ Freeway 7025 Kit Creek Rd.
Dallas, Texas 75234 Dallas, TX 75234 Research Triangle Park, NC 27709-4987
Phone: (972) 484-5200
 End of changes. 20 change blocks. 
69 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/