TN3270E Working Group G. Pullen Internet-Draft: <draft-ietf-tn3270e-extensions-04.txt> Alcatel USA Extends: RFC 2355 M. Williams Expiration Date: October 2002 S2 Systems April 17, 2002 TN3270E Functional Extensions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999, 2000, 2001, 2002). All Rights Reserved. Abstract This draft addresses issues and implementation problems defined and discussed at the TN3270E/TN5250E Interoperability Events. It does not replace the current TN3270 Enhancements protocol. It describes functional extensions to the TN3270E protocol. The TN3270E function negotiation mechanism is used to allow the server and client to determine which, if any, of these functions will be supported during a session. This preserves backward compatibility between clients and servers that do not support these features. Among the issues to be address by this draft are SNA/TN3270E Contention state resolution and SNA Sense Code support. Pullen & Williams Internet Draft [Page 1]
Internet Draft TN3270E Functional Extensions April 2002 1. Table of Contents 1. Table of Contents . . . . . . . . . . . . . . . . . . . 2 2. Negotiated Function Codes . . . . . . . . . . . . . . . 3 3. Negotiated Function Example . . . . . . . . . . . . . . 3 4. Contention Resolution Function . . . . . . . . . . . . . 4 4.1 Keyboard Restore Problem . . . . . . . . . . . . . . . . 4 4.2 Implied Keyboard Restore Problem . . . . . . . . . . . . 4 4.3 Bid Problem . . . . . . . . . . . . . . . . . . . . . . 4 4.4 Signal Problem . . . . . . . . . . . . . . . . . . . . . 5 4.5 CONTENTION-RESOLUTION Implementation . . . . . . . . . . 5 4.5.1 SEND-DATA Indicator (SDI) . . . . . . . . . . . . . . . 6 4.5.2 KEYBOARD-RESTORE Indicator (KRI) . . . . . . . . . . . . 7 4.5.3 BID Data Type . . . . . . . . . . . . . . . . . . . . . 8 4.5.4 SIGNAL Indicator . . . . . . . . . . . . . . . . . . . . 9 5. SNA Sense Code Function . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . 13 7. Term Definitions . . . . . . . . . . . . . . . . . . . . 13 8. Abbreviations . . . . . . . . . . . . . . . . . . . . . 14 9. Conventions . . . . . . . . . . . . . . . . . . . . . . 14 10. Author's Note . . . . . . . . . . . . . . . . . . . . . 14 11. Change Log . . . . . . . . . . . . . . . . . . . . . . 14 12. Author's Address . . . . . . . . . . . . . . . . . . . . 15 Pullen & Williams Internet Draft [Page 2]
Internet Draft TN3270E Functional Extensions April 2002 2. Negotiated Function Codes To maintain backward compatibility with clients and servers that do not support the extended TN3270E functions all new functionality will be negotiated. The current TN3270E function negotiation rules apply. Either side may request one or more of the extended functions by adding them to the function code list during TN3270E function negotiations. Either side may reject the function by removing it from the function list. The extended TN3270E function negotiation codes are defined as: CONTENTION-RESOLUTION 5 SNA-SENSE 7 3. Negotiated Function Example The SNA-SENSE function support is enabled by the negotiation below: Server: IAC DO TN3270E Client: IAC WILL TN3270E . . . Client: IAC SB TN3270E FUNCTIONS REQUEST ... SNA-SENSE IAC SE Server: IAC SB TN3270E FUNCTIONS IS ... SNA-SENSE IAC SE Support is disabled by the negotiation below (the server does not support the SNA-SENSE function): Server: IAC DO TN3270E Client: IAC WILL TN3270E . . . Client: IAC SB TN3270E FUNCTIONS REQUEST ... SNA-SENSE IAC SE Server: IAC SB TN3270E FUNCTIONS REQUEST ... IAC SE Client: IAC SB TN3270E FUNCTIONS IS ... IAC SE Pullen & Williams Internet Draft [Page 3]
Internet Draft TN3270E Functional Extensions April 2002 4. Contention Resolution Function This function addresses shortcomings in the current TN3270E (RFC 2355) specification that stem from the fact that SNA is a send/receive state oriented protocol, while TN3270E is relatively state free. The following subsections define the problems to be addressed and the methods to resolve those issues. 4.1 Keyboard Restore Problem The Keyboard Restore problem concerns uncertainty over when the client can send data to the TN3270E server. TN3270E provides for an End-Of-Record (EOR) mechanism, which allows the client to determine where the boundary is between 3270 data stream commands. The server sends EOR whenever it sends data to the client for which the LIC (Last-In-Chain) indicator was set. Clients have no choice but to interpret the presence of EOR as an indication that it is okay to go ahead and send data back to the host (providing the 3270 data-stream has restored the keyboard). Since it is not uncommon for the Server to receive a LIC from the host with no CDI (Change Direction Indicator) set, a serious problem is created where the client will send data to the server when it does not own the send state. The solution is for the server to provide the client with an indication that it may send data. The Send Data Indicator (SDI) mechanism will be discussed later in this document. 4.2 Implied Keyboard Restore Problem The Implied Keyboard Restore problem occurs when an application never explicitly sets the keyboard restore bit of the WCC byte in any of the 3270 data streams during a bracket. In SNA, EB is considered an "implied" keyboard restore in this case. However, since TN clients are not aware of the bracket or direction state the client is not aware that it is allowed to send data and often hangs in X-CLOCK state. The solution for this problem is for the server to detect the implied keyboard restore condition and send the Keyboard Restore Indicator (KRI) flag to inform the client that its keyboard is unlocked (ready state). 4.3 BID Problem In SNA, when a session is in the BETB (Between Bracket), the Primary LU (PLU), or host, may bid for the bracket by either sending an explicit or implicit BID. The Secondary LU (SLU), or terminal, processes the BID, either granting the bracket to the host or rejecting the request. Having granted the bracket the SLU must enter the X-CLOCK (Time) input inhibited state. Pullen & Williams Internet Draft [Page 4]
Internet Draft TN3270E Functional Extensions April 2002 An implicit BID occurs when the session is BETB and the host sends a message to the SLU with Begin Bracket (BB) indicated. No BID actually flows but is implied. The SLU may accept or reject as if a BID had been sent. In the TN3270 world, there is no mechanism for including the client in the BID process. The server must process the BID on the client's behalf, without the ability to request the client yield the send state. This leads to a variety of problems when the client attempts to send data inbound after the server has sent positive response to a BID from the host. These problems include hung or lost sessions, lost data, or SNA or host application error messages, depending on data flow, timing, and how the server handles the BID process. This problem can be addressed by allowing the BID to propagate to the client. When the server receives a valid BID (implicit or explicit) from the host (i.e. one that occurs in the BETB state) it will forward it to the client. The client will respond either positively or negatively. Having granted the BID (positive response), the client enters the X-CLOCK input inhibited state until the session reenters contention state. 4.4 Signal Problem The Signal problem occurs when the PLU sends a Signal in order to force the SLU to yield direction. For example, when the secondary has rejected a BID and the host needs to override it. The BID reject may occur when the user types some data (perhaps an unintentional depression of the space bar) and does not press an AID key. The SNA architecture provides that the primary (host) can send a Signal. The secondary should reply with a positive response, send a null RU with Change Direction to yield direction (and Begin Bracket if appropriate), and enter send inhibit state. With TN3270 there is no way for the server to force the client to yield the send state. 4.5 CONTENTION-RESOLUTION Implementation This section defines a new negotiated TN3270E function called CONTENTION-RESOLUTION. Support of this function implies that both the client and the server are able to handle the SDI, KRI and Signal header flags and the BID data type as defined in this specification. This function is intended for SNA TN3270E environments only. Non-SNA server implementations should ALWAYS disable this function during TN3270E function negotiations. When the CONTENTION-RESOLUTION function is supported, the REQUEST-FLAG header field is interpreted as a bit mask, instead of a byte value, to allow the field to be used for Send Data, Keyboard Restore and Signal indicators. Pullen & Williams Internet Draft [Page 5]
Internet Draft TN3270E Functional Extensions April 2002 4.5.1 Send Data Indicator (SDI) To use the Send Data Indicator the CONTENTION-RESOLUTION function must be supported by and agreed upon by both the server and client during TN3270E function negotiations. SDI is only valid for TN3270E terminals in PLU-SLU session (3270-DATA type). SDI is not used for SSCP-LU mode to avoid the overhead of the server having to BID to send asynchronous SSCP-LU-DATA records to the client. SDI is meaningful only when sent by the server. It is sent in the REQUEST-FLAG field of the TN3270E header. The SDI bit mask is: SEND-DATA-MASK 0x01 A bit value of 1 (true) indicates to the client that it holds the send state. A bit value of 0 (false) indicates the server (and host by extension) holds the send state. In SNA LU-LU session, the server sends SDI when the host relinquishes send state with either the CDI or the EBI set in the SNA RU header. It is valid for the server to send a null 3270-DATA message (TN3270E header and EOR, no data) to indicate the send state to the client. This allows the server and client to handle a NULL RU containing EBI or CDI received from the host. The server ignores SDI in messages from the client and processes any data as usual depending on data type. When SDI is received by the client and the current TN3270E message has been processed (upon receipt of EOR) the client may send data to the server. If RESPONSES have been negotiated, the client must send RESPONSES to the server regardless of the send state. Upon receipt of SDI, the client must send all pending RESPONSE messages before sending any keyboard input to the server. SDI is not a replacement for the 3270 data stream WCC Keyboard Restore bit. The client must track the 3270 WCC Keyboard Restore flag, TN3270E Keyboard Restore Indicator (KRI) and SDI to determine whether or not it can start sending data to the server. If keyboard restore (WCC or KRI) is received, the keyboard input must still be buffered until the SDI is received. The client may send an ATTN key (IAC IP) regardless of the keyboard State, including input inhibited state. ATTN causes the server to send a SIGNAL to the host requesting Change Direction. This may allow the user to recover from a direction state timing or synchronization problem (i.e. server neglected to send SDI). The client should avoid subsequent ATTN keys until it receives direction from the host. The server may disregard successive ATTN keys while waiting for the first ATTN to be processed and direction is yielded by the host. Pullen & Williams Internet Draft [Page 6]
Internet Draft TN3270E Functional Extensions April 2002 The client may also send SYSREQ (if enabled by TN3270E function negotiation) to override the input inhibit state. This allows the user to switch to SSCP-LU session (possibly to logoff). The RESET key is used to clear local terminal and X-SYSTEM error conditions. RESET purges all buffered (type-ahead) keystrokes, except when entered to remove terminal Insert mode. In this case, a second RESET is required to purge the type-ahead buffer. RESET does restore the keyboard allowing the user to begin typing buffered keystrokes. However, it does NOT clear the X-CLOCK condition or allow the client to override the send state and forward data to the server. 4.5.2 Keyboard Restore Indicator (KRI) To use the Keyboard Restore Indicator the CONTENTION-RESOLUTION Function must be supported by and agreed upon by both the server and Client during TN3270E function negotiations. KRI is only valid for TN3270E terminals in PLU-SLU session (3270-DATA type mode). 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: KEYBOARD-RESTORE-MASK 0x02 A bit value of 1 (true) indicates to the client that its keyboard has been restored. The client's X-CLOCK indicator is turned off, allowing the user to enter data. However, the client may not send data to the server until it has also received SDI from the server (which may be set in the same REQUEST-FLAG field). 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 stream WCC Keyboard Restore bit. The client must still track both the KRI and 3270 WCC Keyboard Restore flag to determine the keyboard state. Normally, one or the other will be received. However, the client should not balk if both are received on a 3270-DATA message. The server ignores KRI in messages from the client and processes any data as usual depending on data type. The server sends KRI when it detects an "implied" keyboard restore during LU-LU session. The server must track whether the host application has explicitly set the keyboard restore bit of the WCC byte in any of the 3270 data streams during a bracket. If not, the server must set KRI in the TN3270E message header when EB is set in the SNA header. It is valid for the server to send a null 3270-DATA message (TN3270E Header and EOR, no data) to indicate the KRI to the client. This allows the server and client to handle a NULL RU containing EBI received from the host. Pullen & Williams Internet Draft [Page 7]
Internet Draft TN3270E Functional Extensions April 2002 4.5.3 BID Data Type To use the BID data type the CONTENTION-RESOLUTION function must be supported by and agreed upon by both the server and client during TN3270E function negotiations. The BID data type message is only valid on terminal sessions in 3270-DATA (LU-LU) mode. The BID data type is not valid during SSCP-LU mode, NVT mode, or on printer sessions. The BID DATA-TYPE code is defined as: Data-type Name Code Meaning -------------- ---- ------------------------------------------- BID 0x09 The server indicates that the host has sent an implicit or explicit BID by sending this data type to the client. 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 server must never send BID to the client when the host already has direction (holds send state). 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 REQUEST-FLAG field, inserts ALWAYS-RESPONSE (0x02) in the 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 (there is no data portion for a BID message). The BID data type must always receive a response from the client regardless of whether the RESPONSES function is supported on the session. The client's positive or negative response to a BID should be exactly the same as those defined in the TN3270 Enhancements RFC, unless the SNA Sense Code Function (defined in section 6) is used by the client to communicate a more specific code. The SEQ-NUMBER is returned by the client in its response, to allow the server to coordinate the response with the BID. When the client receives a BID message it is accepted by returning a positive response, or rejected by returning a negative response. The format of a positive response is the same as the positive response defined for the TN3270E RESPONSES function (i.e., RESPONSE data type, POSITIVE-RESPONSE code in RESPONSE-FLAG field, SEQ-NUMBER from BID). When the client accepts the BID the keyboard state goes to input inhibited, the client displays the X-CLOCK symbol and may 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. Pullen & Williams Internet Draft [Page 8]
Internet Draft TN3270E Functional Extensions April 2002 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 RESPONSES format (i.e., RESPONSE data type, NEGATIVE-RESPONSE code in RESPONSE-FLAG field, SEQ-NUMBER from BID). Unless the client supports the SNA Sense Codes function, there is no defined reason information in the data portion of the negative response. The server rejects the host's BID with a "Bracket Bid Reject" sense code (0x08130000). The client's send state should remain unchanged upon negatively responding to a BID (i.e. if send state is input inhibited, it stays that way). If the client supports the SNA Sense Code function, it has the option of returning "Receiver in Transmit Mode" (0x081B0000) sense code. This may be returned to reject the Bid when the user has started typing data but has not yet pressed an AID key. A potential race condition exists, where the client sends data at the same time the server is sending a BID to the client. The race condition is handled by the server, and is relatively transparent to the client. When the server receives data before the expected response to the BID, the data is treated as an implied negative response. The server sends the Bracket Bid Reject (0x08130000) negative response to the host's BID and forwards the client's data to the host. When the client's response to the BID is received it is discarded by the server. The client's keyboard state should be input inhibited, whether it responded positively or negatively to the BID, because it has not received SDI for the data it sent previously. 4.5.4 SIGNAL Indicator To use the SIGNAL indicator the CONTENTION-RESOLUTION function must be supported by and agreed upon by both the server and client during TN3270E function negotiations. The SIGNAL indicator is only valid on BID data type messages. The SIGNAL indicator is sent in the REQUEST-FLAG field of the TN3270E header. The SIGNAL bit mask is: SIGNAL-MASK 0x04 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 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. Pullen & Williams Internet Draft [Page 9]
Internet Draft TN3270E Functional Extensions April 2002 When a Signal is received from the PLU the TN3270E Server's behavior may be summarized as follows: Send positive response to the host for the Signal If the host already has direction, or in contention state. . . there is nothing more to do Else client has direction. . . send BID with Signal to client and wait for reply or data If data received first. . . forward data to host as normal (will carry CD) Else response received first. . . send null RU CD to Host (with BB if necessary) Upon receipt of Signal from the host, the server returns positive response to the host, regardless of whether the host or client holds direction. If the host holds direction (send state), there is nothing more to be done. The client should already be awaiting data from the host. If the client holds direction, the server sends a BID with the SIGNAL indicator set to inform the client that it no longer holds send state and its keyboard state is input inhibited. The server will receive either data or a positive response from the client. The server forwards any inbound data from the client to the host, while awaiting response to the signal BID. The inbound data record will cause the direction (CD) state to return to the host. When the positive response is received from the client the server has nothing further to do. If the server receives only a response from the client, the server sends a null RU with Change Direction (CD) to the host. The client MUST return positive response to the server. If the client sends 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 accordingly. The Client's behavior when a BID containing the Signal indicator is summarized as: Receive BID with Signal indicator If client has direction and buffered keystrokes with AID. . . send first AID buffer Else host has direction (race condition) or no AID. . . the buffered keystrokes are left unchanged Return positive response to Signal Enter X-CLOCK input inhibited mode Buffer any keystrokes/AID typed after the Signal Pullen & Williams Internet Draft [Page 10]
Internet Draft TN3270E Functional Extensions April 2002 A Signal does not cause the client to purge any buffered keystrokes. If the client holds direction when the Signal is received, it may send one buffered AID message (if any) before sending positive response to the Signal. If the Host already had direction (race condition) or no AID key is buffered, the type-ahead buffer is retained, as is. The client then accepts the BID, and enters input inhibit mode. No further buffered data may be forwarded to the host until direction is returned to the client. The following diagram illustrates how the client should handle buffered keystrokes relative to BID/SIGNAL processing: |<--- Data typed before BID --->|<--- Data typed after BID --->| | is displayed on the screen. | is NOT displayed on screen. | This allows the host application to do a Read Buffer, update the portion of the screen it wants to change, put the cursor back to the right place for the suspended input and restore the keyboard. The client then streams the buffered keystrokes into the screen image. Upon completion of these processes the screen image should be restored correctly. Pullen & Williams Internet Draft [Page 11]
Internet Draft TN3270E Functional Extensions April 2002 5. SNA Sense Code Function This function is intended for SNA TN3270E environments only. Non-SNA server implementations should ALWAYS disable this function during TN3270E function negotiations. When the server and client operate in an SNA environment, it is impractical to perpetuate the one-byte error code mapping style of TN3270E. Especially, when SNA already provides a table of defined Sense codes. The SNA Sense Code function allows the client to return SNA Sense codes to the server, which are in turn forwarded to the SNA Host as a negative response. The client indicates that the data portion of the response message contains a 4-byte SNA sense code by setting the following code in the RESPONSE-FLAG field: SNA-SENSE-CODE 2 The SNA-SENSE function may be negotiated on either terminal or printer sessions. When the SNA-SENSE and RESPONSES functions have been negotiated, the server is committed to accepting SNA-SENSE-CODE responses to 3270-DATA, SCS-DATA (LU1) and BID data type messages. The client retains the option of providing specific SNA Sense codes, or letting the server map all errors to the appropriate SNA sense codes. Pullen & Williams Internet Draft [Page 12]
Internet Draft TN3270E Functional Extensions April 2002 6. References [1] IBM's "3174 Functional Description", Bookshelf book CN7A7003, GA23-0218-11. [2] IBM's "Systems Network Architecture Formats", GA27-3136-14. [3] RFC 2355 [4] IBM's "IPDS and SCS Technical Reference", S544-5312-00. 7. Term Definitions This section defines some of the terms used in this document. Input Inhibited - a state where the client does not hold send state. Either the client has presented an AID message to the host or the host has gained direction via the BID process. The keyboard state is any of the type-ahead or keyboard disabled states. Only SYSREQ or ATTN may be forwarded to the server while the client is in Input Inhibited state. SYSREQ and ATTN should never be buffered by the client. Keyboard Disabled - a keyboard state where keystrokes may NOT be buffered by the client. Keyboard disabled states include (X-f), etc. Keyboard States - define the various modes a keyboard may be in during a TN3270E session. When the client holds send state the keyboard is in Ready state. The client is free to process all keyboard input and forward any entered or buffered AID data to the server. An Input Inhibited state is entered when the client surrenders send state by sending an AID buffer or granting a BID request from the host. The diagram below summarizes the various keyboard states: ------------------------------------------------------------- Ready | Input Inhibited |----------------------------------------------------- | Type-ahead | Keyboard Disabled |----------------------------+------------------------ | X-CLOCK | X-SYSTEM | . . . | X-f | . . . ------------------------------------------------------------- Pullen & Williams Internet Draft [Page 13]
Internet Draft TN3270E Functional Extensions April 2002 Type-ahead - is a state in which the client (terminal) may buffer keystrokes when the keyboard is an Input Inhibited state. Displayed keyboard state may be either X-CLOCK (Time) or X-SYSTEM (System Lock). Keystrokes (text and AID keys) are buffered waiting for send state to be returned to the client. 8. Abbreviations BB Begin Bracket, byte 2 bit 0 of RH of BC RU BC Begin chain, byte 0 bit 6 of RH BC RU An RU with BC = 1 EB End Bracket, byte 2 bit 1 of RH of BC RU EC End chain, byte 0 bit 7 of RH EC RU An RU with EC = 1 FI Format Indicator, byte 0 bit 4 of RH FIC First In Chain - an RU with BC = 1 and EC = 0 IPDS Intelligent Printer Data Stream LIC Last In Chain - an RU with BC = 0 and EC = 1 LU Logical Unit LUn Logical Unit Type n, n = 0, 1, 2, etc. MIC Middle In Chain - an RU with BC = 0 and EC = 0 OIC Only In Chain - an RU with BC = 1 and EC = 1 RH Request Header, 3 byte header on SNA RU RU Request Unit, an SNA frame starting with an RH SNA Systems Network Architecture 9. Conventions - Byte order is big-endian, e.g. bit 0 is the most significant bit. 10. Author's Note Portions of this document were drawn from the following sources: - Contention Resolution proposal by Rodger Erickson (Wall Data). - SNA Sense Code Support proposal by Derek Bolton (Cisco Systems). - Discussions on the TN3270E list and at the TN3270E/TN5250E Interoperability Events, 1997-1998. Particularly contributions by Jim Mathewson II (IBM), Derek Bolton, Michael Boe, and Diane Henderson (Cisco Systems). 11. Change Log - Removed FMH and Byte-Doubling Suppression Support with consensus of TN3270E Work Group. Pullen & Williams Internet Draft [Page 14]
Internet Draft TN3270E Functional Extensions April 2002 12. Author's Addresses Gene Pullen Alcatel USA, Inc. 1000 Coit Road Plano, Texas 75075 Email: gene.pullen@usa.alcatel.com Marty Williams S2 Systems, Inc. 4965 Preston Park Blvd Suite 800 Plano, Texas 75093 Email: marty_williams@s2systems.com Draft Expiration Date: October 2002 Full Copyright Statement Copyright (c) The Internet Society (1999, 2000, 2001, 2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Pullen & Williams Internet Draft [Page 15]
