InfoMagic Standards 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / ascii / 7_3_08.txt < prev next >

Wrap

Text File | 1991-12-22 | 105.7 KB | 3,420 lines

5i' Recommendation T.62 CONTROL PROCEDURES FOR TELETEX AND GROUP 4 FACSIMILE SERVICES (Malaga-Torremolinos, 1984; amended at Melbourne, 1988) CONTENTS 1 General 1.1 Scope 1.2 Fundamental principles 1.3 Definitions 2 Functions of the procedures 2.1 General 2.2 Background information 3 Elements of procedure 3.1 General 3.2 Session commands, responses and parameters 3.3 Session procedures 3.4 Document commands, responses and parameters 3.5 General rules for document elements of pro- cedure 3.6 Rules for document state diagrams in the basic Teletex service 4 Error recovery 4.1 General principles 4.2 Rules for checkpointing 4.3 Acknowledgement window 5 Coding 5.1 Definitions of terms used in coding 5.2 Principles of coding 5.3 Coding of length indicators 5.4 Coding of command and response identifiers for session elements 5.5 Coding of command and response identifiers for document elements 5.6 Coding of parameter group identifiers and parameter identifiers 5.7 Parameter values Annex A - Definitions Annex B - Telematic modes of operation Annex C - Definition of valid/in valid session pro- tocol data units Annex D - General description and rules of opera- tion for state diagrams Annex E - Types of document Annex F - Interactive session protocol and typed data transfer for the telematic services Annex G - Detailed state transition diagrams for session/document procedures Annex H - State transition tables for session/document procedures 1 General 1.1 Scope 1.1.1 Recommendation F.200 lays down the provisions for the operation of the automatic international Teletex service. On the technical side, Recommendation T.60 specifies the requirements for international compatibility between Teletex terminals and Recommendation T.61 defines the character repertoire and coded character sets for the international Teletex service. 1.1.2 Recommendation F.161 defines the rules to be followed in the Group 4 facsimile service. On the technical side, Recommendations T.563, T.503 and T.521 specify the requirements for Group 4 facsimile apparatus and Recommendation T.6 defines the Group 4 facsimile coding scheme and facsimile control functions. 1.1.3 T.400 series of Recommendations define the document interchange protocol which may be used when services other than basic Teletex are utilized; e.g. Group 4 facsimile, mixed-mode operation, etc. 1.1.4 Network-dependent communication procedures for call establishment and termination are defined in Recommendations T.60 and T.563 for the Teletex and Group 4 facsimile services, respec- tively. 1.1.5 This Recommendation defines the end-to-end procedures to be used within the Teletex and Group 4 facsimile services. 1.1.6 Specifically, this Recommendation concerns the end-to-end control procedures that are network-independent. The network-dependent procedures forming a network-independent tran- sport service are specified in Recommendations T.70 and, as appli- cable, T.71. 1.1.7 The procedure described in this Recommendation should also be used between a Teletex terminal and a Teletex/telex conver- sion facility (see Recommendations F.201, T.60 and T.390) and when a Teletex or G4 facsimile terminal takes an access to IPMS (see Recommendations T.422, T.60, T.330 and T.563). 1.1.8 Interworking between Teletex and services other than telex and IPMS, and between Group 4 facsimile and services other than IPMS is for further study. 1.1.9 This Recommendation assumes that the terminal initiating a call is the terminal regarded as responsible for call charges and that it retains full control of the call. 1.1.10 The provisions in this Recommendation are to be regarded as a first stage in the establishment of Teletex and Group 4 facsimile services in accordance with Recommendations F.200, T.60, T.61 and T.70 as defined in 1980 and Recommendations F.161, T.5, T.6 and T.73 as defined in 1984, respectively. Enhancements and additions to these Recommendations must ensure compatibility with established services. 1.2 Fundamental principles 1.2.1 The relationship between the control procedures in this Recommendation and the transport service shall respect the princi- ple that the higher level procedures require the transport service to preserve the structure of blocks, which may be of arbitrary size, given to it by the session level for transmission. Only one session command or response is allowed in such a block. Only one document command or response is allowed in a CSUI or RSUI field (command or response session user information). 1.2.2 The sending terminal is responsible for verifying the correct delivery of the information in its document to the recipient's physical media, i.e. store, hard copy device. This may include linking and other relevant information. 1.3 Definitions 1.3.1 Terms and their definitions are listed in Annex A. Where appropriate, each definition mentions the control procedures to which it refers. 1.3.2 Some of the terms used in this Recommendation have been defined in ways that may differ from the meanings of similar terms in other Recommendations. 2 Functions of the procedures 2.1 General 2.1.1 The broad functional categories provided to implement the control procedures are listed in Tables 1/T.62 and 2/T.62. H.T. [T1.62] TABLE 1/T.62 Session commands and responses ___________________________________________ ___________________________________________ | | | | | | | | | | Tableau 1/T.62 [T1.62], p.1 BLANC H.T. [T2.62] TABLE 2/T.62 Document commands and responses ___________________________________________ ___________________________________________ | | | | | | | | | | Tableau 1/T.62 [T2.62], p.2 2.1.2 The procedural elements have also been listed in the appropriate categories since the definitions of the elements together with their associated rules completely specify the func- tions of the procedures. 2.2 Background information Note - S 2 is given as an aid for the understanding of the procedures. The exact definitions of the control procedures are given in subsequent sections of the Recommendation. 2.2.1 Exchange of service identification 2.2.1.1 Two terminals, when connected by a transport service, will, at session establishment, exchange information identifying whether they are participating in the Telematic services and thus they will invoke the relevant service facilities and the associated protocol. 2.2.2 Negotiation of optional capabilities 2.2.2.1 Two methods are provided. The first is used at session initiation to exchange a limited list of capabilities. The second method may be used when required, after session initiation, to indicate the sender's requirements for extended capabilities. 2.2.3 Negotiation of storage requirements 2.2.3.1 Storage availability can be indicated in the following ways: a) When a Teletex session is established, it is implicitly assumed that there is adequate receive memory for the call. Exceptionally a receiver memory overflow will occur. The continued sending of the document from the source will be stopped by the sink. The sink shall indicate the reason for stopping the transmission. b) When a Group 4 facsimile session is established, it can only be assumed that the called terminal has adequate recording paper to print at least one page of information (for basic Class 1 apparatus). Negotiation of storage requirements is mandatory for Group 4 Classes 2 and 3 facsimile apparatus. Having negotiated this requirement, exceptionally, a receive memory over- flow may occur. The continued sending of the document from the source will be stopped by the sink. The sink shall indicate the reason for stopping the transmission. c) The provision is also made in the procedure for a mandatory indication that the ability of the receiving terminal to continue to accept traffic is jeopardized. d) The control procedure also provides the possi- bility to investigate the storage availability at the receiving terminal prior to the transmission of a document. 3 Elements of procedure 3.1 General 3.1.1 The paragraphs below contain elements of procedure and rules of use which, when combined, define the control procedures. 3.1.2 Definitions applying to the elements of procedure may be found in Annexes A and B. 3.1.3 Annex D describe the session suspension function, which is not applicable to the basic services. 3.2 Session commands, responses and parameters (For a summary of session commands and responses, see Table 1/T.62.) 3.2.1 Command session start (CSS) 3.2.1.1 The CSS initiates entry into a session. 3.2.1.2 Command parameters are: a) Service identifier - this mandatory parameter identifies whether the sender of this command intends to use the Telematic service b) Terminal identifier - this mandatory parameter identifies the calling terminal in accordance with the terminal identification specified in Recommendation F.200. c) Date and time - this mandatory parameter gives date and time information as specified in Recommendation F.200. d) Additional session reference number - this number shall be used in addition to the basic session reference (terminal identifier of the called terminal, terminal identifier of the calling terminal, date and time) when the basic session refer- ence is not sufficient to uniquely identify the session and such unique identification is required. If the additional session refer- ence number is not used, the parameter shall not be included. e) Non-basic terminal capabilities - these param- eters indicate which of the non-basic terminal capabilities listed in Table 3/T.62 for the Teletex service are available as receiving capabilities of the sender of this command. These parameters are mandatory if the terminal is capable of any of the specific func- tions listed in these table. Absence of the parameter indicates that the specific function is not available. f ) Non-basic session capabilities - if used, this non-mandatory parameter indicates which non-basic session capabili- ties are available as receiving capabilities of the sender of this command. Note - Examples of the use of this parameter are session suspension (see Annex D) and negotiation of the window size for checkpoint (see SS 3.3.2.7 and 4.3). g) Inactivity timer - this non-mandatory parame- ter is used to negotiate the value of the inactivity timer (see SS 4.1.2 and 5.7.2.11). h) Session service functions - this non-mandatory parameter is used to specify the session service capabilities available. This parameter is used for the interactive session protocol (ISP) and typed data transfer (TDX). Note - Examples of the use of this parameter are for further study in association with Annex F. i) Session user data - this non-mandatory parame- ter is used to convey data of the presentation and/or application protocol(s). All information necessary to negotiate the document interchange protocol parameters defined in the T.400 Series of Recommendations is contained in this parameter field. j) Non-standardized capabilities - this non-mandatory parameter is used to ascertain compatibility regard- ing the use of non-standardized terminal capabilities. The first octet following the parameter identifier and the length indicator identifies a particular country. The meaning and code assignments of subsequent octets are defined by the indicated country. k) Private use parameters - these parameters are not mandatory. Their definition and use are not standardized. 3.2.2 Response session start positive (RSSP) 3.2.2.1 The RSSP shall be used to acknowledge entry into a session. It indicates that the CSS command has been understood and is in a correct format. 3.2.2.2 Response parameters are: a) Service identifier - this mandatory parameter identifies whether the sender of this response intends to use the Telematic service Note 1 - For the basic Teletex services, the service iden- tifiers in RSSP and CSS must be identical. Note 2 - In case of interconnections between the terminals of different services, the service identifiers in RSSP and CSS may not be identical. b) Terminal identifier - this mandatory parameter provides the terminal identification of the sender of the RSSP in accordance with the terminal identification specified in Recommendation F.200. c) Date and time - this mandatory parameter must be identical to the corresponding parameter in the CSS. It is used in conjunction with the terminal identifications of both terminals in a session as a reference to that session. d) Additional session reference number - if used in the CSS and if used by the receiver of CSS, this parameter shall have the same value as in the CSS. In this case, it shall also be used, together with the basic session reference when referring to this session in a CDC command. If it is not used by the receiver of CSS, it shall not appear in the RSSP. e) Non-basic terminal capabilities (i.e. those available as receiving capabilities of the sender of the RSSP) - the same conditions apply as for S 3.2.1.2 e) above. f ) Non-basic session capabilities - as for S 3.2.1.2 f ) above. g) Session control functions - this parameter is used to indicate "request control" and "request session suspension" as defined in this Recommendation. h) Inactivity timer - as for S 3.2.1.2 g) above. i) Session service functions - as for S 3.2.1.2 h) above. j) Session user data - as for S 3.2.1.2 i) above. k) Non-standardized capabilities - as for S 3.2.1.2 j) above. l) Private use parameters - as for S 3.2.1.2 k) above. H.T. [T3.62] TABLE 3/T.62 Non-basic terminal capabilities included in CSS _____________________________________ _____________________________________ | | | | | | Tableau 3/T.62 [T3.62], p.3 3.2.3 Response session start negative (RSSN) 3.2.3.1 The negative response indicates that the session was not entered by the receiver of the CSS. It is not mandatory to indicate the reasons for rejection. A non-mandatory private-use parameter may be used with this response. Note - It should be noted that existing equipment may send an RSSN without any parameter fields. This shall not be regarded as an error. 3.2.3.2 Response parameters are: a) Service identifier - this mandatory parameter identifies whether the sender of this response intends to use the telematic service. Note 1 - For the basic services, the service identifiers in RSSN and CSS must be identical. Note 2 - In case of interconnections between the terminals of different services, the service identifiers in RSSN and CSS may not be identical. b) Terminal identifier - this mandatory parameter provides the terminal identification of the sender of the RSSN in accordance with the terminal identification specified in Recommendation F.200. c) Date and time - this mandatory parameter must be identical to the corresponding parameter in the CSS. It is used in conjunction with the terminal identifications of both terminals in a session as a reference to that session. d) Additional session reference number - if used in the CSS and if used by the receiver of CSS, this parameter shall have the same value as in the CSS. If it is not used by the receiver of CSS, it shall not appear in the RSSN. e) Non-basic terminal capabilities (i.e. those available as receiving capabilities of the sender of the RSSN) - the same conditions apply as for S 3.2.1.2 e) above. f ) Non-basic session capabilities - as for S 3.2.1.2 f ) above. g) Reason for sending the negative response - this parameter is used to indicate the reason for sending the RSSN. The parameter value may be presented to an operator when received. One of the following reasons may be used as a value of the parameter: - no reason given; - temporarily unable to enter the session. Shall be used e.g. in the case of memory full; - text message of maximum 69 characters. It may be possible for the operator to enter this message from the keyboard. h) Session service functions: as for S 3.2.1.2 h) above. i) Session user data: as for S 3.2.1.2 i) above. j) Private use parameters: as for S 3.2.1.2 k) above. 3.2.4 Command session end (CSE) 3.2.4.1 The CSE is used for normal (or error-free) termination of a session. Note - A parameter is reserved to indicate whether the tran- sport connection is to be cleared. Absence of this parameter will cause the transport connection to be cleared. 3.2.5 Response session end positive (RSEP) 3.2.5.1 The RSEP indicates to the calling terminal that the called terminal has entered the idle state in an orderly manner. 3.2.6 Command session abort (CSA) 3.2.6.1 The CSA may be used at any time by either terminal to terminate a session, whenever a condition is detected indicating that the session cannot be continued successfully. CSA shall only be used when there is no other suitable way of ending the session. 3.2.6.2 One of the following reasons for the abnormal termina- tion of the session must be given as a CSA parameter: a) local terminal error; b) unrecoverable procedural error; c) reason not defined. Note - One value is reserved to indicate whether the tran- sport connection is to be cleared. 3.2.7 Response session abort positive (RSAP) 3.2.7.1 The RSAP response indicates to the sender of a CSA command (either the source or the sink terminal) that the receiver of CSA has entered the idle state in an orderly manner. 3.2.8 Command session user information (CSUI) 3.2.8.1 The CSUI is used to indicate to the receiver that the associated information field of this command conveys command, parameters and information for the document procedures. 3.2.8.2 CSUI does not call for a response. There is no rela- tionship between this command and the response RSUI. 3.2.9 Response session user information (RSUI) 3.2.9.1 The RSUI is used to indicate to the receiver of this response (source) that the associated information field conveys response and parameters for the document procedures. A non-mandatory parameter, session control function, may be used with this response. 3.2.9.2 This RSUI response is not related to any CSUI command. 3.2.9.3 The parameter, session control functions , is sent with RSUI in conjunction with document response. Use of this param- eter with RSUI but without an associated document response is per- mitted only in the case where the session may intentionally be inactive for a period of time. In this case, when no document responses are being generated, use of the session control functions parameter is permitted without an associated document response. For the Teletex service, this requires a preceding negotiation of the inactivity timer to a value different from the default value. 3.2.10 Command session change control (CSCC) 3.2.10.1 In the two-way alternate (TWA) mode CSCC changes the source/sink relationship between the two terminals. Note - A signal for request control is available in some responses (see coding scheme). It may be used to indicate that a terminal sending this signal has information to transmit. The ter- minal receiving this signal is not required to take any action if this signal is detected. 3.2.11 Response session change control positive (RSCCP) 3.2.11.1 The RSCCP indicates to the sender of the CSCC that the sink terminal intends to enter the session sending state. 3.3 Session procedures 3.3.1 Session modes of operation 3.3.1.1 The following provisions concern the TWA mode of ses- sion operation: a) the basic protocol provides the capability of the TWA mode; b) at session initiation, the sender of the CSS is defined as being the current source of any text information and is therefore the source terminal; c) the CSCC exchanges the source/sink relationship between the two terminals. The CSCC command should only be invoked outside document boundaries. d) only the terminal that is currently the source terminal may send the CSCC; e) there is no requirement for sending text infor- mation prior to sending a CSCC; f ) when the called terminal has finished transmit- ting text, it shall hand back the right of sending text to the cal- ling terminal. Only the calling terminal is allowed to send CSE. 3.3.1.2 The following provisions concern the one-way communi- cation (OWC) mode of session operation: a) the OWC mode is achieved by the CSS sender not issuing a CSCC; b) there is no requirement to send text informa- tion. c) this mode is a subset of TWA. 3.3.2 Rules for session elements of procedure 3.3.2.1 Only the terminal that has established the transport connection (the calling terminal) shall send CSS. 3.3.2.2 It is the responsibility of the sender of CSS to exam- ine the parameters of RSSP and to determine whether the session should continue. If it is not to be continued, the session shall be ended normally (by CSE). 3.3.2.3 In continuing the session, neither terminal is permit- ted to use any procedure or to send any information that does not comply with the receiving capabilities indicated by the session partner in the service identifier and non-basic session and termi- nal capabilities parameters of the CSS/RSSP exchange at session initiation and/or by the parameters of CDCL/RDCLP exchange. 3.3.2.4 In the TWA or OWC mode, only the sender of CSS may send CSE when he is the current source. 3.3.2.5 In the TWA mode, the recipient of both CSS and CSCC must terminate his period as source by sending CSCC. 3.3.2.6 In any mode of operation, CSA may be sent at any time by either terminal whenever a condition is detected indicating that the session cannot be successfully continued (e.g. due to failure or charging problems). The following rules are applied to the ses- sion abort procedure : a) the session abort procedure is in general com- pleted when the sender of a CSA command receives an RSAP response; b) the terminal sending the CSA waits for a response RSAP. In state 14, all other commands or responses received will be discarded. If RSAP is not received before a time-out (e.g. T = 4 seconds), the terminal that send the CSA clears the transport connection. Note - In all cases the transport connection must be cleared when the CSA timer has expired. 3.3.2.7 The following rules should apply to the use of window size : a) the indication of the window size parameter is not mandatory for the Teletex service, but is mandatory for the Group 4 facsimile service. It may have a value in the range of 1 to 255. The absence of this parameter in CSS or its corresponding response must be interpreted as the default value of three for the Teletex service; b) all the Teletex terminals should support a win- dow size of 3. Group 4 facsimile terminals of Classes 2 and 3 should be able to support a window size of 3 when interworking with Teletex. Enhanced Teletex terminals (e.g. with mixed-mode capabil- ity) and all Group 4 facsimile terminals may require other window sizes; c) the rule for the use of window size is that the source terminal is free to use any window size that does not exceed the window size indicated by the sink terminal (in CSS or its corresponding response); d) if the sender of CSS or its corresponding response is a basic Teletex terminal which does not indicate any parameter for the window size, the receiver should be aware that the sender may ignore any window size indicated and use the window size of 3. 3.3.2.8 Figure 1/T.62 is a state transition diagram for TWA and OWC session modes. The change control commands and responses [marked with an "a)" in the diagram] do not apply to the OWC mode. The general description and rules of operation for state diagrams may be found at Annex D. 3.3.2.9 In a session where the use of the RSUI with request control is permitted (as specified in S 3.2.9.3), the following will apply: a) an RSUI requesting control may be received after giving control and before receiving any valid session protocol ele- ment. This shall not be regarded as a procedural error and shall be discarded; b) an RSUI requesting control may be received after sending a CSE and before receiving an RSEP. This shall not be regarded as a procedural error and shall be discarded. Figure 1/T.62, p. 3.4 Document commands, responses and parameters (For summary of document commands and responses, see Table 2/T.62.) 3.4.1 Command document start (CDS) 3.4.1.1 The CDS indicates the start of a document to the receiver of this command. It also indicates the start of the first page. 3.4.1.2 Command parameters are: a) Service interworking identifier - not a manda- tory field (see S 3.5.2). Note - When communicating with a conversion facility , an identifier may be required for: i) Teletex/telex interworking - the identifier will indicate that the document(s) has been prepared in accordance with the rules given in Recommendations F.200, T.90 and T.91; ii) Teletex/Videotex interworking - for further study; iii) Teletex/facsimile interworking - for further study. b) Document type identifier - not a mandatory field. If a normal document is used, this parameter shall not be indicated. If other types of document are used, the inclusion of this field is obligatory (for a description of types of document, see Annex E). c) Document reference number - (see S 4.2.9). d) Indication of required terminal capability (standardized or private use) - not a mandatory field, however, this parameter must be used if standardized optional terminal capabilities are required for the document. e) Session user data - this non-mandatory parame- ter is used to convey data of the presentation and/or application protocol(s). All information necessary to negotiate the document interchange protocol parameters defined in the T.400 Series of Recommendations is contained in this parameter field. f ) Private use parameters (not mandatory) - definition of such parameters is not standardized. 3.4.1.3 There is no response to CDS except in the case of an error, for which RDGR is used. 3.4.2 Response document general reject (RDGR) 3.4.2.1 The RDGR may be used by the sink to indicate to the source that a procedural error has occurred and that resynchroniza- tion is requested. The bit pattern of command or response up to and including the error shall be returned to the source. Only the first detected error within a command or response must be processed by this method. 3.4.2.2 The response parameter is the bit pattern required by S 3.4.2.1. 3.4.2.3 It is the responsibility of the terminal receiving an RDGR response to take appropriate action. Note - Use of RDGR for other kinds of error is for further study. 3.4.3 Command document continue (CDC) 3.4.3.1 The CDC indicates to the receiver of this command the continuation of transmission of a document that has previously been partially transmitted. 3.4.3.2 Command parameters are: a) Document linking information , in order to iden- tify the previous transmission of the partial document, including: - the checkpoint reference number (see S 4.2.7) from which the transmission is being continued; - the document reference number, which shall be the same as the document reference number in the CDS; - the session reference information identifying the session in which the first part of the document was sent. Note 1 - If several continuations are required to complete transmission of a document, all are linked to the partial transmis- sion in which the CDS was used. The sequence of checkpoint refer- ence numbers is then used to identify the correct sequencing for linking and all such continuations shall be transmitted in this sequence. Note 2 - It is the responsibility of the receiving termi- nal to discard any text information that has been duplicated in the process of continuation of an interrupted transmission. Note 3 - The checkpoint reference number appearing in CDC is the last checkpoint reference number for which a positive ack- nowledgement has been received. b) Service interworking identifier - not a manda- tory field (see the note under S 3.4.1.2 a) for CDS). c) Document type identifier - not a mandatory field. If a normal Teletex document is used, this parameter shall not be indicated. If other types of document are used, the inclu- sion of this field is obligatory (for a description of types of document, see Annex E). d) Document reference number (of the current ses- sion): see S 4.2.9. e) Optionally, any other parameter field(s) that appeared in the CDS command at the start of the document may be repeated as parameter(s) in CDC. Indication of required terminal capability is mandatory if standardized optional terminal capabili- ties are required for the document. A terminal receiving a CDC that does not contain all of the terminal capabilities should not reject the continuation of the document. f ) Session user data - this non-mandatory param- eter is used to convey data of the presentation and/or application protocol(s). All information necessary to negotiate the document interchange protocol parameters defined in the T.400 series of Recommendations is contained in this parameter field. 3.4.3.3 There is no response to CDC except in the case of an error, for which RDGR is used. 3.4.4 Command document capability list (CDCL) 3.4.4.1 The CDCL initiates an exchange of information to enable a check of the terminal capabilities (both standardized and private use). The command shall include a list of receiving capa- bilities that may be needed at the receiver by the sender of this command. 3.4.4.2 The command may also be used to investigate the storage capability of the remote terminal. The required amount of storage (given in kilo-octets) is indicated in a parameter of the command in this case. 3.4.4.3 Command parameters are the list of receiving capabili- ties and the required amount of storage. 3.4.4.4 The CDCL command should only be invoked outside docu- ment boundaries. 3.4.4.5 The CDCL command may be used to negotiate the value of the inactivity timer. The value of the inactivity timer that the sender of this command wishes to use is indicated in a parameter field of this command. 3.4.4.6 The CDCL command may be used to convey the session user data of the presentation and/or application protocol(s). All information necessary to negotiate the document interchange proto- col parameters defined in the T.400 series of Recommendations is contained in this parameter field. 3.4.4.7 The CDCL command may be used to ascertain compatibil- ity regarding the use of non-standardized capabilities. 3.4.5 Response document capability list positive (RDCLP) 3.4.5.1 The RDCLP response is sent by the receiver of a CDCL command as a positive acknowledgement of the command. 3.4.5.2 If the CDCL command includes the information to check the non-basic Teletex terminal capabilities, the corresponding RDCLP response has to contain one of the following: a) confirmation that all the requested capabilities are available at the receiver by use of "acceptance of CDCL parame- ters"; b) a list of capabilities available at the receiver by use of the "non-basic Teletex terminal capabilities" parameter. This will indicate one of the following: - the complete list of all the capabilities requested in the CDCL; - a list of the requested capabilities that are available at the receiver. Absence of parameters associated with non-basic capabilities indicated that the requested capabilities are not available at the receiver; - a complete list of non-basic receiving capabili- ties, irrespective of the requested ones. 3.4.5.3 If the CDCL is used for memory negotiation, one of the following shall be included in the RDCLP: a) confirmation that the amount of memory requested is available and has been reserved; b) indication of the available (and reserved) amount of memory (in kilo-octets); c) indication the requested memory capacity cannot now be reserved; d) indication that the available memory cannot be estimated (through either explicit indication or the absence of a memory negotiation parameter in a response to a response to a CDCL with a memory request). Note 1 - Storage that has been reserved by the CDCL com- mand can be released after session termination or when a new CDCL with storage requirement indication is received. Note 2 - The use of the memory negotiation parameter in RDCLP (i.e. indicating that the memory cannot be estimated) when not present in CDCL is not prohibited. Therefore, reception of such RDCLP in response to CDCL is not to be regarded as an error. 3.4.5.4 The RDCLP response may be used to negotiate the value of the inactivity timer. The value of the inactivity timer that the sender of this response wishes to use is indicated in a parameter field of this response. 3.4.5.5 The RDCLP response may be used to convey the session user data of the presentation and/or application protocol(s). All information necessary to negotiate the document interchange proto- col parameters defined in the T.400 Series of Recommendations is contained in this parameter field. 3.4.5.6 The RDCLP response may be used to ascertain compati- bility regarding the use of the non-standardized and private use capabilities. 3.4.6 Command document end (CDE) 3.4.6.1 The CDE shall be used to indicate to the receiver of this command the end of a document. It also represents the final checkpoint to which a response shall be made. 3.4.6.2 The command parameter is the checkpoint reference number. 3.4.6.3 The RDPBN shall be used as the negative response to the checkpoint in CDE. 3.4.7 Response document end positive (RDEP) 3.4.7.1 The RDEP gives a positive acknowledgement to the last checkpoint. In the basic services, this is the last page reference number. 3.4.7.2 The RDEP shall also indicate that the receiver: a) has not detected any error; b) accepts responsibility for the received docu- ment; and c) is ready to receive a new CDS or CDC. 3.4.7.3 The RDEP shall include as a parameter the checkpoint reference number of the CDE. 3.4.7.4 Only if the sink terminal has sent an RDEP and received either a valid CDS, CDC, CDCL, CSE or CSCC, is it certain that the source terminal will not use error recovery procedures regarding the preceding document. In all other cases it can happen that after sending RDEP a repetition of pages takes place and the duplications may be deleted by the sink terminal. 3.4.8 Command document discard (CDD) 3.4.8.1 The CDD shall be used to indicate to the receiver of this command the abnormal ending of a document and that the receiver of the command is not held responsible for the part of the document received so far. Therefore, as a local function outside these control procedures, the receiver can delete the part of the text received. Note 1 - CDD is an invitation to discard the whole of the document and not merely the part of the document transmitted since the last CDC. Note 2 - The receiving terminal may discard the document from its memory and/or indicate to the operator that this part of the document has no value. Note 3 - The implementation of this function for Group 4 fac- simile is for further study. 3.4.8.2 The reason for sending the CDD command may be given as a CDD parameter. If used, only one of the following reasons shall be indicated: a) unable to continue a session (e.g. due to memory full, out of recording paper); b) sequence error; c) local terminal error; d) unrecoverable procedural error; e) no specific reason stated (used for reasons other than those listed). 3.4.8.3 The CDD may only be used to terminate the current document, instead of using CDE or CDR. It cannot be used after a CDR has been sent (see S 4.3.2). 3.4.8.4 The receiver of a CDD is allowed to delete the received part of the document, but has no obligation to do so. If the text is not deleted, the operator shall be informed. 3.4.8.5 No negative response to CDD is allowed except for error conditions where RDGR applies. 3.4.9 Response document discard positive (RDDP) 3.4.9.1 The RDDP acknowledges the CDD and indicates that the receiver of the command is ready to receive a new CDS or CDC. 3.4.10 Command document resynchronize (CDR) 3.4.10.1 The CDR shall be used by the source to indicate to the sink the point of resynchronization abnormally end that document. 3.4.10.2 The reason for an abnormal ending of a document may be given as a CDR parameter. If used, only one of the following rea- sons may be given: a) unable to continue a session (e.g. due to memory full, out of recording paper); b) sequence error; c) local terminal error; d) unrecoverable procedural error; e) no specific reason stated (used for reasons other than those listed). 3.4.10.3 No negative response to CDR is allowed except for error conditions where RDGR applies. 3.4.11 Response document resynchronize positive (RDRP) 3.4.11.1 The RDRP is sent by the receiver of a CDR as a positive acknowledgement of the command. 3.4.11.2 If RDRP is used within a document, it confirms to the sender of a CDR that the sender of RDRP has already accepted responsibility for the received document (up to the last checkpoint for which a positive acknowledgement has been sent). It does not indicate that the sender of RDRP will be able to perform linking of the following parts of the interrupted document. 3.4.11.3 The control procedures provide a means for resuming transmission of an interrupted document. 3.4.11.4 The linking of the parts of an interrupted document is a local operation at the receiver and is therefore not within the responsibility of the control procedures. Thus these procedures cannot guarantee that this linking of parts of a document will be effected. 3.4.12 Command document user information (CDUI) 3.4.12.1 The CDUI indicates to the receiver of this command that the associated information is to be interpreted as the user text information field being conveyed. 3.4.12.2 The basic services do not require any parameter for CDUI. The procedure provides means for adding parameters. Any such need is for further study. For the basic services a CDUI has to contain a user information field. The need for having CDUIs without infor- mation field is for further study. 3.4.12.3 Several CDUIs may be used to transfer the contents of one page. 3.4.13 Command document page boundary (CDPB) 3.4.13.1 The CDPB indicates to the receiver the boundary between pages. It also indicates a checkpoint for error recovery purposes (see S 4). CDPB invites the sink to accept responsibility for the previously received page. 3.4.13.2 The CDPB command parameter is the checkpoint reference number, which, in the basic services, is the page reference number. 3.4.13.3 The checkpoint reference number appearing in the first CDPB after a CDC is the one appearing in this CDC plus one. 3.4.14 Response document page boundary positive (RDPBP) 3.4.14.1 This response shall be used to indicate that the receiver accepts responsibility for that page. 3.4.14.2 Response parameters are: a) a mandatory parameter giving the checkpoint reference number (see S 3.4.13.2 above); b) a mandatory parameter indicating whether or not the ability of the receiving terminal to continue to accept traffic is jeopardized (e.g. whether or not the memory threshold has been reached). 3.4.15 Response document page boundary negative (RDPBN) 3.4.15.1 This response shall be used to indicate that the receiver does not accept the responsibility for that page for example, due to a detected error or other failure. Note - This response may also be returned at any point within the document boundary after the receipt of CDS. 3.4.15.2 The value of the mandatory parameter giving the reason for a negative response should be one of the following: a) unable to continue a session (e.g. due to memory full, out of recording paper); b) sequence error; c) local terminal error; d) unrecoverable procedural error; e) no specific reason stated (used for reasons other than those listed). 3.5 General rules for document elements of procedure 3.5.1 When a document has been either started by CDS or con- tinued by CDC, it must be terminated by either CDE, CDR or CDD prior to sending the next CDS or CDC. 3.5.2 The following rules relate to the CDS and CDC parame- ters: a) the service interworking parameter may be used to indicate that the document is suitable for interworking; how- ever, use of this parameter is mandatory in the case of service interworking; b) absence of the document type identifier indi- cates that the associated document is a normal document. 3.5.3 No negative response to CDS or CDC may be sent after the sending of a positive response to any checkpoint within that docu- ment. No negative response may be sent to any document commands once the checkpoint associated with those commands has been posi- tively acknowledged. 3.5.4 With regard to the responses to CDPB (RDPBP or RDPBN), the receiver may reject reception for a detected error, but the receiver is not obligated to monitor for errors in the document. Once a page has been positively acknowledged, any error recovery for the subsequent detection of an error is beyond the scope of these control procedures. 3.5.5 If, during the transmission of a document, there is an interruption of the transport connection or session such that another call and/or session establishment is needed, the following rules apply. a) In the case that a document transmission is initiated by a CDS and no checkpoint is positively acknowledged during that document transmission: - the receiving terminal shall treat the failure as if a CDD had been received and an RDDP had been sent; - the sending terminal shall treat the failure as if a CDD had been sent and an RDDP had been received. b) In other cases: - the receiving terminal shall treat the failure as if a CDR had been received and an RDRP had been sent; - the sending terminal shall treat the failure as if a CDR had been sent and an RDRP had been received. 3.5.6 If, during the transmission of a document, an abnormal condition except those described in S 3.5.5 takes place, the fol- lowing rules apply: a) in the case that a document transmission is ini- tiated by CDS command and no checkpoint is positively acknowledged, either a CDD or a CDR command should be used. If a CDR is used, it should be interpreted as a CDD; b) in other cases, a CDD or CDR should be used. 3.5.7 When a source terminal receives an RDPBP with the receiving ability jeopardized (RAJ) parameter set to 1 during a document transmission, it may continue to transmit one or more pages until the window is closed. In this context the following rules apply: a) if the source subsequently receives an RDPBP with the RAJ parameter set to 0, it will be able to continue transmission; b) if the source subsequently receives an RDPBN indicating "memory overflow", the document transmission should be terminated abnormally; e.g. exchange of either CDD/RDDP or CDR/RDRP. Note - In other contexts (e.g. window size of 1), the session may be terminated abnormally due to expiration of an inactivity timer. However, this requires further study. 3.5.8 When a sink terminal sends an RDPBP with the receiving ability jeopardized parameter set to 1, and subsequent memory over- flow results in sending RDPBN, the reason code "unable to continue the session" has to be indicated. 3.6 Rules for document state diagrams 3.6.1 General 3.6.1.1 The rules common to all state diagrams are given in Annex D. 3.6.1.2 For any error a terminal is permitted to send CSA. If this procedure is not used, the following rules shall apply. 3.6.2 Rules for the sending protocol (see Figure 2/T.62) 3.6.2.1 Any command or response received in state 1 shall cause an abnormal end of the session and sending of CSA. 3.6.2.2 Reception of any command or response not shown as allowed in the state diagram in states 2 to 11 shall cause CDR or CDD to be sent in accordance with S 3.5.6. 3.6.2.3 Reception of any command or response except RDCLP in state 14 shall cause CDR to be sent. 3.6.2.4 In state 13 receipt of RDRP or RDDP will cause a tran- sition to state 1. Any other command or response will be discarded. 3.6.2.5 The demand response timer started when state 13 is entered is only reset when a valid response is received. 3.6.3 Rules for the receiving protocol (see Figure 3/T.62) 3.6.3.1 Reception of any command or response except CDS, CDC, CDCL, CDR or CDD in state 1 shall cause RDGR to be sent. 3.6.3.2 In state 12 receipt of CDR or CDD will cause a transi- tion to state 13. Any other command or response received will be discarded. 3.6.3.3 Reception of any command or response not allowed in the state diagram or any invalid parameters or parameter values in state 2 to 11 may cause RDGR to be sent. 3.6.3.4 The inactivity timer started when state 12 is entered is only reset when a valid command is received. Figure 2/T.62, p.5 Figure 3/T.62, p.5 4 Error recovery 4.1 General principles 4.1.1 During a session, each partner is responsible for moni- toring for the correct operation of the following: a) maintenance of the currently agreed source/sink relationship; b) proper use of the command/response procedural sequences as described in the state diagrams and rules for opera- tion (see S 3.6); c) detection of any period of inactivity in excess of the inactivity timer value as determined by negotiation (indi- cating, for example, a failure or other inability to continue pro- ductive use of the session); d) detection of a period of time in excess of the demand response timer value in which the remote terminal has failed to issue a response. Note - Negotiation of the demand response timer value is for further study. 4.1.2 The following rules apply to the negotiation of the value of the inactivity timer; a) an inactivity timer value different from 60 seconds will apply only if this parameter is indicated by both ter- minals, i.e. negotiation, at session establishment (via CSS/RSSP) or document boundaries (via CDCL/RDCLP); b) if both terminals indicate an inactivity timer value the following rules apply for the duration of the session or until a subsequent negotiation has taken place: i) The smaller of the two values applies when both values are greater than or equal to 60 seconds. ii) The larger of the two values applies when both values are less than 60 seconds. iii) A timer value of 60 seconds applies if one value is above and one is below 60 seconds. 4.1.3 Upon detection of any failure to maintain proper opera- tion as described in S 4.1.1, use of the error recovery procedures defined for each state is mandatory; or, where such error recovery procedures are not specifically defined, session termination (abnormal end) is mandatory. In the event of an error, this control procedure allows for repeated transmission of information. The number of repetitions should be limited by the sender and may be zero. 4.2 Rules for checkpointing 4.2.1 After an abnormal termination of a document, for recovery in the same session the checkpoint reference number and the document reference number are required in order to identify unambiguously the point from which to recover. 4.2.2 A new session (and call) has to be initiated after abnormal termination of a document where recovery is to be effected in a subsequent session or after an abnormal termination and/or interruption of the call. The information required in order to identify unambiguously the point from which to recover is: a) the reference for the interrupted session; b) the document reference number; and c) the checkpoint reference number. 4.2.3 In the basic services a checkpoint must be inserted at each page boundary using CDPB. 4.2.4 If a negative response is received to a command representing a checkpoint, the transmission must be interrupted by sending a CDR or CDD. 4.2.5 Within a document, a final checkpoint will be represented by the CDE. Transmission of another document is not permitted until the response to this command has been received. 4.2.6 No other checkpointing is permitted in the basic ser- vice. 4.2.7 Each command representing a checkpoint shall contain a parameter showing the reference number. Each such command calls for a response, which shall contain a parameter showing the checkpoint reference number to which that response applies. Each checkpoint in the CDPB must be explicitly acknowledged and the acknowledgements must be in the right sequence. 4.2.8 Checkpoint reference numbers shall be assigned as decimal digits starting from 001 and sequentially incremented by one for each checkpoint within a document. The number does not necessarily have to comprise 3 digits and leading zeros do not necessarily have to be transmitted. In all cases, the leading zeroes must be ignored. 4.2.9 Document reference numbers (DRNs) shall be assigned as decimal digits, preferably, but not necessarily, starting from 001. DRNs shall then sequentially be incremented by one for each succes- sive document. DRNs shall be assigned to all documents in a ses- sion, irrespective of the document type identifier or whether CDS or CDC is used as the initiating command. The number does not necessarily have to comprise 3 digits and leading zeros do not necessarily have to be transmitted. In all cases, the leading zeroes must be ignored. Note - In order to uniquely identify the documents exchanged, it is recommended that the same DRNs should not appear within a session. However, it is noted that some existing terminals may cause duplication of DRNs when documents are exchanged in both directions. 4.2.10 The sum of the numbers of digits contained in the checkpoint reference number and the document reference number shall not exceed six, to permit printing in the available space in the call identification line as defined in Recommendation F.200. There is no constraint on the maximum number of digits in either number, as long as this limitation is not exceeded. 4.3 Acknowledgement window 4.3.1 In the basic Teletex service the sender is prohibited from exceeding an acknowledgement window size of three. The maximum window size may be negotiated during session establishment using the parameters of the CSS command and the corresponding response (see S 5.7.2.6). 4.3.2 In the Group 4 facsimile service, indication of window size parameters in both CSS command and the corresponding response is required (see SS 3.3.2.7 and 5.7.2.6). 4.3.3 There are two ways that the sender is permitted to recover from an interrupted transmission: a) a cancellation is achieved by the subsequent use of CDC and CDD commands and the transmission will be resumed by the CDS command; b) the sender may resume by use of CDC command, starting at the point in the text of the last checkpoint for which an acknowledging response was received. On this basis, the receiver must be able to resume reception at a checkpoint ranging from the last acknowledged checkpoint to the last acknowledged checkpoint plus one, minus the window size. 4.3.4 The window mechanism has been introduced in order to allow continuous transmission of pages. The window mechanism may also be used by the receiving terminal to resolve local time prob- lems without affecting the continuous transmission. Note - For efficiency reasons, the receiving terminal will transmit the response to acknowledge outstanding checkpoint(s) as soon as possible. 4.3.5 The design of a terminal should be such that continuous reception is possible in normal operation of the terminal (e.g. with an average Teletex page content of 1600 octets). The use of the window mechanism should take into account the quality of ser- vice requirements in Recommendations F.200 and F.161. 4.3.6 If transmission flow control is needed, it shall be pro- vided by the transport service. 5 Coding 5.1 Definition of terms used in coding 5.1.1 command identifier (CI) or response identifier (RI) F: identificateur de commande (IC) ou de reponse (IR) S: identificador de instruccion (II) o identificador de respuesta (IR) The heading information that identifies the command or response concerned. 5.1.2 length indicator (LI) F: indicateur de longueur (IL) S: indicador de longitud (IL) Represents the length in octets of an associated field or group of fields. 5.1.3 parameter identifier (PI) F: identificateur de parametre (IP) S: identificador de parametro (IP) Indicates the type of information contained in an associated field or group of fields. 5.1.4 parameter group identifier (PGI) F: identificateur de groupe de parametres (IGP) S: identificador de grupo de parametros (IGP) A special case of a parameter identifier, which indicates that the associated field consists entirely of a group of parameters, each identified by a parameter identifier. 5.1.5 parameter value (PV) F: valeur de parametre (VP) S: valor de parametro (VP) The information that represents the value of the parameter identified by either a PI or PGI. 5.1.6 field F: champ; domaine S: campo Either a group of one or more bits within a single octet or a group of one or more octets, used to represent a particular set of information. 5.2 Principles of coding 5.2.1 The coding of session commands, responses and parameters is independent of the coding of document commands, responses and parameters and vice versa. 5.2.2 Binary field encoding principles have been used to allo- cate bit patterns for the CI, RI, PGI and PI. 5.2.3 The first section of a session or document field con- sists of either a CI or an RI. Each CI or RI is always immediately followed by an LI. 5.2.4 Bits of an octet are numbered 8 to 1 where bit 1 is the low order bit and is transmitted first. Octets of a session or document field are consecutively numbered starting from 1 and transmitted in this order. 5.2.5 The value of an LI is a binary number that represents the total length of the immediately following parameter field(s) in octets. The value of the LI does not include either itself or any subsequent user information. 5.2.6 If a parameter field indicated by a PGI appears within a parameter field initiated by a PGI, the PV field of the nested PGI field may not extend beyond the end of the PV of the enclosing PGI field. 5.2.7 To decode CI, RI, PGI and PI, all the bits of the iden- tifier must be considered. 5.2.8 The format of a parameter field initiated by a PGI is the same as the format of such a field initiated by a PI except that the entire PV field consists of a sequence of one or more parameter fields, each of which is initiated by either PI or PGI. 5.2.9 The absence of non-mandatory PI or PGI indicates that no such functions are available. Therefore PIs or PGIs with LI set to zero should be avoided. 5.2.10 Figures 4/T.62, 5/T.62 and 6/T.62 illustrate the coding principles. Figure 4/T.62, p. Figure 5/T.62, p. Figure 6/T.62, p. 5.3 Coding of length indicators 5.3.1 The value of an LI is a binary number that represents the total length in octets of the immediately following CI, RI, PI and/or PGI fields. The value of the LI does not include either itself or any subsequent user information, as noted in S 5.2.5 above. 5.3.2 The basic LI consists of a single octet with a maximum value of 254 in decimal (i.e., a binary value of 11111110). 5.3.3 If the first octet of the LI is 255 decimal (i.e., a binary value of 11111111), this indicates that the value of the LI is contained in the next two following octets allowing a maximum value of 65 | 35 octets. 5.3.4 Within any octet, the highest order bit is bit 8 with the remaining bits assigned in descending order. Where the length value is represented in two octets, the first contains the higher order bits. 5.4 Coding of command and response identifiers for session elements 5.4.1 The coding of CI and RI for session commands and responses is shown in Table 4/T.62. 5.4.2 Apart from private use, the codes of the commands and responses in Table 4/T.62 are assigned in such a way that the bits may be interpreted as follows: Bit 1 1 = Command 0 = Response Bit 2 1 = Positive 0 = Negative (for responses) Bit 3 1 = Initiate 0 = Stop (for most commands) Bits 4, 5 11 Session 10 Session 01 Interaction 00 Session user Bits 6, 7, 8 Set to zero (except for private use) and reserved for extension. Note - If possible, this binary field coding structure should be followed in making future code assignments, but this is not man- datory if the number of available code combinations is insuffi- cient. Therefore, it is not intended as a guide for implementation. 5.4.3 One or more of the non-allocated values are to be reserved for future extension. The method of future extension is for further study. 5.5 Coding of command and response identifiers for document elements 5.5.1 The coding of command and response identifiers for docu- ment commands and responses is shown in Tables 5/T.62 and 6/T.62 respectively. 5.5.2 Apart from private use, the codes of the commands and responses in Tables 5/T.62 and 6/T.62 are assigned in such a way that the bits may be interpreted as follows: Bit 1 1 = Command 0 = Response Bit 2 1 = Positive 0 = Negative (for responses) Bit 3 1 = Initiate 0 = Stop (for most commands) Bits 4, 5, 6 111, 110, 101 Document 100 Reserved 011 Page 010 Reserved 001 Reserved for recovery unit 000 Text Bits 7, 8 Set to zero, and reserved for future extension. 5.5.3 With regard to future extension, see the note in S 5.4.2 and S 5.4.3 above. H.T. [T4.62] TABLE 4/T.62 Command and response identifiers for session elements lw(60p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) . rw(60p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) . { TABLE 5/T.62 Coding for document command identifiers } lw(60p) | lw(24p) sw(18p) sw(24p) sw(18p) sw(24p) sw(18p) sw(24p) sw(18p) , ^ | l | l | l | l | l | l | l | l. lw(60p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) . Table 4/T.61 [T4.62], p. H.T. [T5.62] TABLE 5/T.62 Coding for document command identifiers lw(60p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) . Table 5/T.61 [T5.62], p. H.T. [T6.62] TABLE 6/T.62 Coding for document response identifiers lw(60p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) . Table 6/T.61 [T6.62], p. 5.6 Coding of parameter group identifiers and parameter identifiers 5.6.1 The coding of PGIs and PIs for session commands and responses is shown in Table 7/T.62. The coding of the PGIs and PIs for document commands and responses is shown in Table 8/T.62. 5.6.2 Tables 9/T.62 and 10/T.62 list the PGIs and PIs for each command and response for the session and document elements of pro- cedure together with an indication of whether the PGIs and PIs con- cerned are mandatory or not. 5.6.3 Where a PI is allocated to a particular PGI this is shown in Table 7/T.62 or 8/T.62. Some PIs are not allocated to a PGI and are used as required. Some PIs may be used without preced- ing PGIs as defined in Tables 9/T.62 and 10/T.62. 5.6.4 The codes of these PGIs and PIs are assigned in such a way that the binary field consisting of bits 8, 7 and 6 may be interpreted as follows: Bits 876 000 Session related 001 Document related (These document related PGIs and PIs may possibly be of use to other services.) 010 Document related (for Teletex) 011 100 Reserved 101 110 User data 111 Private use The binary field consisting of bits 5 and 4 may be interpreted as follows: Bits 54 00 PGI 01 PI 10 PI 11 PI The binary field consisting of bits 3, 2 and 1 is used to extend the PGIs when set to 000. Note - If possible, this binary field coding structure should be followed in making future code assignments, but this is not man- datory if the number of available code combinations is insuffi- cient. Therefore, it is not intended as a guide for implementation. 5.6.5 PGIs and PIs within the same nesting level should be put in the order of increasing binary value. The coding order of PGIs and PIs included in each command or response is defined in Tables 9/T.62 and 10/T.6. 5.6.6 The following rules shall apply to the private use and presently not defined parameters: a) these parameters, if present in CSS or CDCL (or their corresponding responses), shall not lead to procedural errors; b) the use of these parameters in other commands or responses must be negotiated upon in advance by CSS or CDCL and their corresponding responses (see S 3.3.2.3); c) presence of these parameters "unexpectedly" in elements other than CSS, RSSP, CDCL or RDCLP may result in pro- cedural errors; d) the absence of a parameter of this kind in a response to CSS or CDCL must be interpreted as an indication that the terminal is not capable of handling any of these functions. 5.7 Parameter values 5.7.1 General 5.7.1.1 Unless otherwise specified the following rules apply to the fields containing parameter values (PV): a) Where a binary number is used to represent a value, the highest order bit of each octet is bit 8 with the remaining bits assigned in descending order. Where a binary value is represented by more than one octet, the first octet contains the highest order bits, with successive octets assigned in descending order; b) All bits reserved for future standardization shall be set to zero; c) Where a PV contains graphic characters that may be printed or displayed, they shall be in the intended printing/display sequence and shall be coded as defined in Recommendation T.61; d) For a PGI designated for extension, the PIs and/or PGIs included in the parameter field do not necessarily con- form to the following assignments of PI and PGI values. 5.7.1.2 Assignment of coding to the various parameter values is shown in the following paragraphs. 5.7.2 Session related parameters Note - The following paragaphs include either session related or both session and document related parameters. 5.7.2.1 Terminal identifier of the called terminal A sequence of graphic characters as defined in Recommendation F.200. 5.7.2.2 Terminal identifier of the calling terminal A sequence of graphic characters as defined in Recommendation F.200. 5.7.2.3 Date and time A sequence of graphic characters as defined in Recommendation F.200. 5.7.2.4 Additional session reference number A fixed length sequence of two decimal digits as coded in Recommendation T.61. H.T. [T7.62] TABLE 7/T.62 Coding of session PGIs and PIs lw(66p) | lw(48p) | lw(66p) | lw(48p) . Tableau 7/T.62 [T7.62], p.13 H.T. [1T8.62] TABLE 8/T.62 Coding of document PGIs and PIs lw(66p) | lw(48p) | lw(66p) | lw(48p) . Tableau 8/T.62 [1T8.62], p.14 H.T. [2T8.62] TABLE 8/T.62 (continued) lw(66p) | lw(48p) | lw(66p) | lw(48p) . Tableau 8/T.62 [2T8.62], p.15 H.T. [1T9.62] TABLE 9/T.62 PGIs and PIs for session elements of procedure lw(30p) | lw(72p) | lw(30p) | lw(66p) | lw(30p) . lw(30p) | lw(72p) | lw(30p) | lw(66p) | lw(30p) . Session control functions nm Tableau 9/T.62 [1T9.62], p.16 H.T. [2T9.62] TABLE 9/T.62 (continued) lw(228p) . Tableau 9/T.62 [2T9.62], p.17 H.T. [3T9.62] TABLE 9/T.62 (end) lw(30p) | lw(72p) | lw(30p) | lw(66p) | lw(30p) . Tableau 9/T.62 [3T9.62], p.18 H.T. [1T10.62] TABLE 10/T.62 PGIs and PIs for document elements of procedure lw(30p) | lw(72p) | lw(30p) | lw(66p) | lw(30p) , ^ | l | l | l | l ^ | l | l | l | l ^ | l | l | l | l ^ | ^ | ^ | l | l ^ | ^ | ^ | l | l ^ | ^ | ^ | l | l ^ | ^ | ^ | l | l ^ | ^ | ^ | l | l ^ | l | l | l | l ^ | l | l | l | l. Tableau 10/T.62 [1T10.62], p.19 H.T. [2T10.62] TABLE 10/T.62 (continued) lw(228p) . Tableau 10/T.62 [2T10.62], p.20 H.T. [3T10.62] TABLE 10/T.62 (continued) lw(30p) | lw(72p) | lw(30p) | lw(66p) | lw(30p) . Tableau 10/T.62 [3T10.62], p.21 H.T. [4T10.62] TABLE 10/T.62 (end) lw(30p) | lw(72p) | lw(30p) | lw(66p) | lw(30p) . Tableau 10/T.62 [4T10.62], p.22 5.7.2.5 Miscellaneous session capabilities Bit 1 of the first octet set to 1 indicates the terminal capa- bility for two-way simultaneous information transfer. Bit 2 of the first octet set to 1 indicates the terminal capa- bility for session suspension. Bit 3 of the first octet set to 1 indicates the terminal capa- bility for interactive operation. All other bit values are reserved for future standardization. 5.7.2.6 Window size A binary number of fixed length of one octet, with a minimum value of one and a maximum value of 255 in decimal (i.e., a binary value of 11111111). The default value is three in decimal (i.e., a binary value of 00000011). 5.7.2.7 Service identifier The coding for the service identifier is as follows: Bits 87654321 Service 00000001 Telematic All other encodings are for further study. 5.7.2.8 Session control functions When used with a response, i.e. either RSSP or RSUI, the fol- lowing bit assignments are defined in the first octet: a) bit 1 set to 1 indicates request control (as defined in this Recommendation); b) all other bits are reserved for future standard- ization. 5.7.2.9 Session termination parameter Bit 1 of the first octet set to 1 indicates that the transport connection shall be cleared (default value). When set to 0 it indi- cates that the connection should not be cleared. Bit 2 of the first octet set to 1 indicates a local terminal error. Bit 3 of the first octet set to 1 indicates an unrecoverable procedural error. Bit 4 of the first octet set to 1 indicates that no reason is given. All other bits are reserved for future standardization. The CSE command uses only bit 1; all other bits shall be set to 0. 5.7.2.10 Reason (session or document) A field indicating the reason for sending the associated com- mand or response. The value can either be given as a binary coded field or as plain text message. The absence of this parameter indi- cates that no reason is given. Bits 87654321 Reason 00000000 No specific reason stated (used for ses- sion or document reasons other than those listed); 00000001 Temporarily unable to enter into, or to continue, a session (e.g. due to memory full or out of recording paper); 00000010 Explicit text message only for use with RSSN (see Note 1); 00000011 Sequence error (Note 2); 00000101 Local terminal error (Note 2); 00000110 Unrecoverable procedural error (Note 2). Note 1 - For the basic Teletex service, the text follows immediately after the first byte of the value. Maximum of 69 char- acters (control characters included). Only characters convertible one-to-one to the telex alphabet (ITA2) shall be allowed. Teletex code shall be used. Note 2 - These parameter values are valid only in document commands and responses. 5.7.2.11 Inactivity timer a) Bits 8 and 7 indicate the unit of inactivity timer value and bits 6 to 1 indicate the binary value in the range of 1 to 63. Bits 87 Unit of timer 00 Second(s); 01 Minute(s); 10 Hour(s); 11 Reserved for extension. b) All bits of the first octet set to zero indi- cates the inactivity timer value is of infinity, i.e. the timer is disabled. 5.7.2.12 Session service functions The parameter value is indicated by a sequence of two octets. a) In octet 1: Bits 8-4 (Note 1) Reserved (set to 0). Bit 3 Set to 1 to indicate the typed data capability (for further study). Bit 2 (Note 2) Set to 1 to indicate the ability to send RDPBN. Bit 1 (Note 2) Set to 1 to indicate the ability to send/receive CDCL/RDCLP. b) In octet 2: Bits 8, 6, 5 and 3 (Note 1) Reserved (set to 0). Bit 7 (Note 2) Set to 1 to indicate the capability of document transfer. Bit 4 (Note 2) Set to 1 to indicate the capability of page synchronization [CDPB/RDPBP(N)]. Bits 2-1 (Note 3) Set to 0 1 to indicate "half duplex" Set to 1 0 to indicate "duplex" Note 1 - All bits reserved should be ignored when compar- ing capabilities indicated in CSS and RSSP. Note 2 - The indicated bits should be set (to 1 for docu- ment transfer and to 0 for no document transfer) as a unit. Note 3 - Half-duplex and duplex are for further study. The absence of this parameter should be interpreted as the following default values: Bits 87654321 Octet 1: 00000011 Octet 2: 01001001 5.7.2.13 Non-standardized capabilities The first octet represents the registered CCITT country code as specified in Recommendation T.35 to be used to identify non-standard capabilities. Additional octets, may be specified by each country's Administration. 5.7.2.14 Session user data Some parameters associated with this PGI are defined in the T.400 series of Recommendations. The maximum length of this user data field following the PGI and its LI is restricted to 512 octets. 5.7.2.15 Private use A set of PGI and PI values is designated as being for private use. Other than the PGIs designated for extensions and the permit- ted use of private parameters only with certain command and responses, the use of these parameters is not defined. 5.7.3 Document related parameters Note - The following paragraphs include parameters commonly used by basic Teletex and Group 4 facsimile services. 5.7.3.1 Service interworking identifier Bit 1 of the first octet set to 1 shall indicate that the associated document is suitable for forwarding via the telex ser- vice. All other bit values are reserved for future standardization. 5.7.3.2 Document reference number A sequence of decimal digits as defined in this Recommendation and coded in Recommendation T.61. 5.7.3.3 Checkpoint reference number A sequence of decimal digits as defined in this Recommendation and coded in Recommendation T.61. 5.7.3.4 Acceptance of CDCL parameters Bit 1 of the first octet set to 1 indicates acceptance of all non-basic terminal capabilities which are defined in this Recommen- dation and requested by a CDCL command. All other bit values are reserved for future standardization. Note - Bit 1 of the first octet set to 1 does not indicate accepance of non-basic terminal capabilities conveyed in the ses- sion under data of CDCL. 5.7.3.5 Storage capacity negotiation A fixed length sequence of two octets: a) Bit 1 of the first octet set to 1 indicates that a terminal has reserved the requested amount of storage. b) Bit 2 of the first octet set to 1 indicates that the binary field in the following octet contains a number indicat- ing storage capacity required/reserved in kilo-octets. c) Bit 5 of the first octet set to 1 indicates that the binary field in the following octet contains a number, which, when multiplied by 16, indicates storage capacity required/reserved in kilo-octets. d) Bit 6 of the first octet set to 1 indicates that the binary field in the following octet contains a number, which, when multiplied by 256, indicates storage capacity required/reserved in kilo-octets. e) Bit 3 of the first octet set to 1 indicates that a terminal cannot estimate its memory capacity. f ) Bit 4 of the first octet set to 1 indicates that a terminal cannot now reserve the requested amount of memory. g) In the first octet, only one of bits 2, 5 and 6 may be set to 1. For negotiation of storage capacity less than or equal to 255 kilo-octets, bit 2 shall be used. Note - Use of bit 5 or 6 for negotiation of a storage capacity greater than 65 kilo-octets but less than or equal to 255 kilo-octets is not to be interpreted as a procedural error by the receiver. h) Bits 7 and 8 of the first octet are reserved for future standardization. Octet 2 indicates the memory size available and/or reserved (the meaning is defined in the first octet). It shall be set to 11111111 if bit 3 and/or 4 in the first octet is set to 1. In cases a), e) and f ), the second octet may be ignored by the recipient of RDCLP. 5.7.3.6 Receiving ability jeopardized The first octet shall be encoded as follows: Bits 87654321 Meaning 00000000 Further traffic can be accepted. 00000001 Ability to receive further traffic is jeopardized. All other binary values are reserved for future standardiza- tion. 5.7.3.7 Document type identifier Absence of this parameter shall indicate a normal document. This parameter, if used, is a binary encoded field of fixed length of one octet identifying the document type as follows: Bits 87654321 Type of document 00000001 Operator document. 00000010 Control document. 00000011 Monitor document. All other encodings are reserved for future standardization. 5.7.3.8 Reflect parameter value This is an arbitrary length field that contains the bit pat- tern of the command or response up to and including the detected error. 5.7.4 Document related parameter for teletex Note - The following parameters may also be used by services other than teletex. 5.7.4.1 Control character sets (refer to Recommendations T.60 and T.61) A variable length field indicating the receiving capability for non-basic standardized control character sets. Each such con- trol character set shall be indicated by the sequence of characters used to designate that set, as defined in Recommendation T.61. Where more than one such character set are to be indicated, the ESC character fulfills the purpose of a separator between the character set indicators. 5.7.4.2 Graphic character sets (refer to Recommendations T.60 and T.61) 5.7.4.2.1 A variable length field indicating the receiving capa- bilities for non-basic standardized graphic character sets. Each such graphic character sets or DRCS (Dynamically redefinable char- acter set) for Japanese Kanji and Chinese ideogram characters shall be indicated by the sequence of characters used to designate that set, as defined in Recommendation T.61. Where more than one such character set are to be indicated, the ESC character fulfills the purpose of a separator between the character set indicators. 5.7.4.2.2 The following descriptions apply to the use of a DRCS set for Japanese Kanji and Chinese ideogram characters: a) if the DRCS set is indicated as a parameter value associated with a CDS or CDC command, this should be followed by combinations of a character code (CC) to be registered to the DRCS set and its character dot pattern (DP); b) the field length of a character code is defined by the DRCS set and that of a character dot pattern is indicated as parameter values of a character box height and a character box width. Note - The PV field of this parameter in either CDS or CDC will be as follows: DRCS CC1 DP1 CC2 DP2. | | CCi DPi 5.7.4.3 Teletex page formats (refer to Recommendations T.60 and T.61) The value of the first octet of the parameter value will indi- cate the capability of a page format, as defined in Table 11/T.62. If the terminal is capable of more than one format, these will be indicated in the first and subsequent octets, one octet per value (see Note 1 of Table 11/T.62). No separator between the values will be given. The length indicator of the parameter will indicate if more than one value is given. All parameter values shall be inserted in increasing order of their binary values. H.T. [T11.62] TABLE 11/T.62 __________________________________________________________________________________________________________________________________ { 0 0 0 0 0 0 0 1 (option) ISO A4, horizontal and vertical } { 0 0 0 0 0 0 1 0 (option) North American, horizontal and vertical } { 1 0 0 0 0 1 0 0 (option) ISO A4 extended (ISO standard 3535), vertical } { 0 1 0 0 0 1 0 0 (option) ISO A4 extended (ISO standard 3535), horizontal } { 1 0 0 0 1 0 0 0 (option) North American legal, vertical } { 0 1 0 0 1 0 0 0 (option) North American legal, horizontal } { 0 0 0 0 0 0 1 1 (option) ISO A4, horizontal and vertical (for use by Japanese Kanji and Chinese ideogram terminals) } { 0 0 0 1 0 0 0 0 (option) ISO B5, horizontal and vertical (for use by Japanese Kanji and Chinese ideogram terminals) } { 0 0 1 0 0 0 0 0 (option) ISO B4, horizontal and vertical (for use by Japanese Kanji and Chinese ideogram terminals) } __________________________________________________________________________________________________________________________________ | | | | | | | | | | | | Note 1 - The whole octet has to be considered when decoded, since the meaning is coded as a value, not as a single bit position within the octet. All other values are reserved, i.e. it is not allowed to "combine" the indication of several formats into the same octet by setting more than one bit to "one". Note 2 - The following rule is used for the coding of bits 7 and 8: Bits 8 7 Meaning 0 0 Vertical and horizontal 0 1 Horizontal only 1 0 Vertical only. Table 11/T.62 [T11.62], p. 5.7.4.4 Miscellaneous terminal capabilities (refer to Recommendation T.61) A variable length field indicating the receiving capabilities for non-basic standardized values of character spacing, line spac- ing and graphic renditions. Each parameter value of such a function shall be indicated by the control sequence (CSI PiIiF) as defined in Recommendation T.61. This applies to the functions Select Hor- izontal Spacing (SHS) for a character pitch, Select Vertical Spac- ing (SVS) for a line pitch and Select Graphic Rendition (SGR) for a graphic rendition. This also applies to the functions Graphic Size Modification (GSM) and Select Presentation Direction (SPD) for Japanese Kanji and Chinese ideogram capabilities, and to Select Character Orientation (SCO) for Chinese ideogram capabilities. When more than one such character sequence is to be indicated, a single space shall be inserted between them. Only one parameter value is allowed within a CSI sequence. 5.7.4.5 Character box height A variable length field indicating the receiving capabilities for the number of dots of the character box height. The number of dots shall be indicated by the numeric character as defined in T.61. Further study is required for indicating more than one value. 5.7.4.6 Character box width A variable length field indicating the receiving capabilities for the number of dots of the character box width. The number of dots shall be indicated by the numeric character as defined in T.61. Further study is required for indicating more than one value. MONTAGE: ANNEXE A SUR LE RESTE DE CETTE PAGE