Question 8/VII - Study of DTE-DCE interface procedures for dissimilar terminal interworking (Continuation of Question 8/VII studied in 1985- 1988) considering (a) that administrations recognize the interest that some users would have in interworking between different terminals; (b) that the technical feasibility and economics of such interworking must be established before a user requirement can be determined, What are the interface requirements for data communications between dissimilar DTEs? 1. Study should include the following points relating to enhancement and extension of Recommendations X.3, X.28 and X.29: 1.1 PAD-to-PAD. Realizing that work has progressed over the last study period in this area, what additional procedures are needed (or enhancement to the existing ones) in Recommendation X.28 to fully accomplish this interworking? 1.2 Definition of the function of character 0/10 (FE). Recommendation V.3 provides for character 0/10 to be used as Line Feed (LF) or New Line (NL). The need for a new parameter which allows for this alternative use should be studied. Study should include the characters to be echoed. 1.3 Establishment of the access information path by the PAD in response to an incoming call or direct call from the remote DTE. The following item remains identified as open and should be considered: -automatic speed and code detection by the PAD if speed and code are not specified by facilities in the incoming call packet. 1.4 Establishment of the access information path for a start-stop mode DTE to a PAD via a PSTN. The following points should be considered: -speed and parity detection; -use of NUI; -disconnecting the access information path after call clear. 1.5 What happens to an incoming call when the interface is not in the PAD waiting state? 1.6 Various timers have been identified in the operation of the PAD (as found in the appendix to Recommendation X.20). Further definition and values for those timers currently undefined needs to be studied. In addition, this should include the definition of a time-out for the waiting for command state (state 10) so that the characters are received from the DTE. 1.7 Are there any mechanisms to increase PAD command handling efficiency? Study should include the concept and support of an operator sending more than one PAD command continuously (e.g. the PAD command and the selection PAD command continuously). In addition, functions such as type-ahead and overlap should be considered. 1.8 Expansion and enhancements to Recommendation X.25 have taken place during the last study period. What additional procedures (and/or parameters) should be added to the PAD Recommendations to take advantage and support the changes to Recommendation X.25? 1.9 While work has been done in adding access rates at higher speeds to the PAD, additional higher speeds may be necessary. 1.10 Recommendation X.2 provides for a variety of facilities: -call redirection notification; -call redirection and deflection; -local charging prevention; -fast select; -direct call; -hunt group; -on-line facility registration; -flow control parameter negotiation; -throughput class negotiation. Since additional facilities may enhance the PAD service, what new procedures (and/or parameters) need to be added to the PAD Recommendations to support them? 1.11 What new PAD procedures need to be defined in the PAD Recommendations to support permanent virtual circuits? 1.12 What support can the PAD give for escape sequences as used by the start-stop mode DTE (such as those conforming to ISO 2022), and how can the PAD be prevented from sending or echoing the undesired escape sequences? 1.13 Should the PAD send DC1 (XON) if the value of parameter 5 is changed from 1 to 0 when the interface is in XOFF state? 1.14 What new PAD procedures need to be defined to enable more flexibility in the page wait function when used in conjunction with manual page control? Study should include having control of the page wait service signal being independent from the control of the other PAD service signals. 1.15 Which link protective protocol needs to be supported to provide an error protected access to the PAD? (This is especially required for DTEs operating automatically and in applications such as file transfer via the PAD.) The possibility of implementing the protocol either in the PAD or in the PAD modem or similarly, within the start-stop mode DTE or the DTE modem, should be studied. Existing CCITT Recommendations (e.g. using a LAP-based protocol such as LAPB or LAPD) should be considered to improve quality and the wide-spread use of these protocols. Close liaison is necessary with the work on error-control modems in Study Group XVII. See also annexes to this Question. 2. Study should include the following points relating to the provision of the Packet Assembly/Disassembly (PAD) facility for Group 3 facsimile terminals: 2.1 What new parameters in the existing PAD Recommendations and/or new Recommendations are needed to enable this service? 2.2 What new procedures are needed to transfer the control information and document data defined in Recommendation T.30 between a PAD providing this service and a packet mode DTE or another PAD? 2.3 What new parameters and/or Recommendations are needed to provide access to this service? 3. Depending upon the conformation of service requirements, study should include the following points relating to the provision of the Packet Assembly/Disassembly (PAD) facility for other non-packet mode DTE: 3.1 What procedures are required for interworking between dissimilar terminals utilizing other procedures for data interchange? Study should include DTEs operating as follows: -basic control procedure; -under an ISDN; -asynchronous as well as synchronous (not covered by Recommendation X.21) block mode. Alternatives such as mapping from a terminal specific protocol to CCITT Recommendations should also be considered. What new parameters and/or Recommendations are needed to enable this service? ANNEX 1 (to Question 8/VII) SOURCE: COM VII-R 17, ANNEX 5, APPENDIX 6, ATTACHMENT 1, OCTOBER 1986 TITLE: LINK PROTECTIVE PROTOCOLS UNDER CONSIDERATION The protocol described in Delayed Contribution D.10 has the advantage that it allows ordinary asynchronous character oriented operation without any special precaution. There is not even a need to switch from character mode operation to block mode operation, therefore, neither is there for a switching procedure between the two. This allows the design of a block mode PAD including the normal asynchronous operation or, what is the same, the inclusion of the block mode operation in the X.28 PAD as an extension (see also Delayed Contribution D.9). For this characteristic to be achieved it is necessary to process in the PAD the control characters and character strings used by the block mode protocol in the "control state" (see D.10, 3.1.2). These characters and strings are given here once more as follows: STX 0/2 DLE STX 1/0, 0/2 ENQ 0/5 DLE ENQ 1/0, 0/5 EOT 0/4 DLE EOT 1/0, 0/4 ACK 0 1/0, 3/0 ACK 1 1/0, 3/1 ACK 0/6 NAK 1/5 WACK 1/0, 3/11 The only character of the above which is used in the X.28 PAD is DLE. It can be used to escape from the data transfer state. Two possibilities exist to overcome this problem: 1) As the character to escape from the data transfer state can be defined by parameter 1, another character could be used as default. 2) As DLE is used in the "control state" of the block mode link layer protocol only in conjunction with other control characters (i.e. ENQ, EOT and STX), it could also be processed only in this sequence and used as escape signal when appearing in any other combination. This then would not interfere with the X.28 PAD (see also X.28, 4.9.1., pt. d)). To allow maximum compatibility, the options left open in the block mode protocol (parameter settings) should be controlled by non-blocked command strings, i.e., the same way as for the X.28 PAD. These options and parameters still are to be defined. Summary To sum up, the following characteristics can be assigned to the protocol described in Delayed Contribution D.10 (of the Geneva meeting 1985): -compatibility with the X.28 PAD through the possibility of character mode and block mode operation; -error detection and correction; -simplicity of implementation; -asynchronous transmission; -octet orientation; -full duplex operation and half duplex operation possible; -transparent transmission possible; -split speed transmission possible; -flow control. ANNEX 2 (to Question 8/VII) SOURCE: ISO/IEC JTC1/SC6 N 4842 TITLE: PROGRESSION OF WORK ON START/STOP FRAMING MODE TRANSMISSION OPERATION OF HDLC PROTOCOLS - - - - - - - - - - - - - - - - - The attached documents have been distributed to SC6 Member Bodies for ballot as Proposed Draft Addenda to ISO 3309, 4335, 7809, and 8885 to add an optional capability for use of HDLC protocols in Start/Stop transmission environments. SC6 welcomes comments on the technical content of these addenda. SC6 is particularly interested in the suitability of the proposed mechanism for use in various applications. For example, suggestions have been made that the mechanism be enhanced to work in transmission environments which convey only seven data bits (and possibly a parity bit) between start and stop bits. Comments related to other special requirements are encouraged. The next meeting at which these matters will be considered is the ISO/IEC JTC1/SC6/WG1 meeting in Copenhagen, Denmark, 19-23 September 1988. Attachments: Proposed Draft Addenda to ISO 3309, 4335, 7809, and 8885