home *** CD-ROM | disk | FTP | other *** search
Wrap
Text File | 1991-12-13 | 88.6 KB | 3,848 lines
.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .sp 2P .LP \fBRecommendation\ T.62\fR .RT .sp 2P .sp 1P .ce 1000 \fBCONTROL\ PROCEDURES\ FOR\ TELETEX\ AND\ GROUP\ 4\ FACSIMILE\ SERVICES\fR .EF '% Fascicle\ VII.3\ \(em\ Rec.\ T.62'' .OF '''Fascicle\ VII.3\ \(em\ Rec.\ T.62 %' .ce 0 .sp 1P .ce 1000 \fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .ce 1000 CONTENTS .ce 0 .sp 1P .sp 2P .LP 1 \fIGeneral\fR .sp 1P .RT .LP 1.1 Scope .LP 1.2 Fundamental principles .LP 1.3 Definitions .sp 1P .LP 2 \fIFunctions of the procedures\fR .sp 9p .RT .LP 2.1 General .LP 2.2 Background information .sp 1P .LP 3 \fIElements of procedure\fR .sp 9p .RT .LP 3.1 General .LP 3.2 Session commands, responses and parameters .LP 3.3 Session procedures .LP 3.4 Document commands, responses and parameters .LP 3.5 General rules for document elements of procedure .LP 3.6 Rules for document state diagrams in the basic Teletex service .sp 1P .LP 4 \fIError recovery\fR .sp 9p .RT .LP 4.1 General principles .LP 4.2 Rules for checkpointing .LP 4.3 Acknowledgement window .sp 1P .LP 5 \fICoding\fR .sp 9p .RT .LP 5.1 Definitions of terms used in coding .LP 5.2 Principles of coding .LP 5.3 Coding of length indicators .LP 5.4 Coding of command and response identifiers for session elements .LP 5.5 Coding of command and response identifiers for document elements .LP 5.6 Coding of parameter group identifiers and parameter identifiers .LP 5.7 Parameter values .sp 1P .LP \fIAnnex\ A\fR \(em Definitions .sp 9p .RT .LP \fIAnnex\ B\fR \(em Telematic modes of operation .LP \fIAnnex\ C\fR \(em Definition of valid/in valid session protocol data units .LP \fIAnnex\ D\fR \(em General description and rules of operation for state diagrams .LP \fIAnnex\ E\fR \(em Types of document .LP \fIAnnex\ F\fR \(em Interactive session protocol and typed data transfer for the telematic services .LP \fIAnnex\ G\fR \(em Detailed state transition diagrams for session/document procedures .LP \fIAnnex\ H\fR \(em State transition tables for session/document procedures .bp .LP \fB1\fR \fBGeneral\fR .sp 1P .RT .sp 2P .LP 1.1 \fIScope\fR .sp 1P .RT .PP 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. .sp 9p .RT .PP 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. .PP 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\(hymode operation,\ etc. .PP 1.1.4 Network\(hydependent communication procedures for call establishment and termination are defined in Recommendations\ T.60 and T.563 for the Teletex and Group\ 4 facsimile services, respectively. .PP 1.1.5 This Recommendation defines the end\(hyto\(hyend procedures to be used within the Teletex and Group\ 4 facsimile services. .PP 1.1.6 Specifically, this Recommendation concerns the end\(hyto\(hyend control procedures that are network\(hyindependent. The network\(hydependent procedures forming a network\(hyindependent transport service are specified in Recommendations\ T.70 and, as applicable, T.71. .PP 1.1.7 The procedure described in this Recommendation should also be used between a Teletex terminal and a Teletex/telex conversion 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). .PP 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. .PP 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. .PP 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. .sp 2P .LP 1.2 \fIFundamental principles\fR .sp 1P .RT .PP 1.2.1 The relationship between the control procedures in this Recommendation and the transport service shall respect the principle 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). .sp 9p .RT .PP 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. .sp 2P .LP 1.3 \fIDefinitions\fR .sp 1P .RT .PP 1.3.1 Terms and their definitions are listed in Annex\ A. Where appropriate, each definition mentions the control procedures to which it refers. .sp 9p .RT .PP 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. .bp .LP \fB2\fR \fBFunctions of the procedures\fR .sp 1P .RT .sp 2P .LP 2.1 \fIGeneral\fR .sp 1P .RT .PP 2.1.1 The broad functional categories provided to implement the control procedures are listed in Tables\ 1/T.62 and\ 2/T.62. .sp 9p .RT .ce \fBH.T. [T1.62]\fR .ce TABLE\ 1/T.62 .ce \fBSession commands and responses\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(84p) | lw(84p) | lw(30p) | lw(30p) . .TE .nr PS 9 .RT .ad r \fBTableau 1/T.62 [T1.62], p.1\fR .sp 1P .RT .ad b .RT .LP .rs .sp 9P .ad r BLANC .ad b .RT .LP .bp .ce \fBH.T. [T2.62]\fR .ce TABLE\ 2/T.62 .ce \fBDocument commands and responses\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(84p) | lw(84p) | lw(30p) | lw(30p) . .TE .nr PS 9 .RT .ad r \fBTableau 1/T.62 [T2.62], p.2\fR .sp 1P .RT .ad b .RT .LP .bp .PP 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 functions of the procedures. .sp 1P .LP 2.2 \fIBackground information\fR .sp 9p .RT .PP \fINote\fR \ \(em\ \(sc\ 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. .RT .sp 2P .LP 2.2.1 \fIExchange of service identification\fR .sp 1P .RT .PP 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. .sp 9p .RT .sp 2P .LP 2.2.2 \fINegotiation of optional capabilities\fR .sp 1P .RT .PP 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. .sp 9p .RT .sp 2P .LP 2.2.3 \fINegotiation of storage requirements\fR .sp 1P .RT .PP 2.2.3.1 Storage availability can be indicated in the following ways: .sp 9p .RT .LP 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. .LP 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 overflow 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. .LP 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. .LP d) The control procedure also provides the possibility to investigate the storage availability at the receiving terminal prior to the transmission of a document. .LP \fB3\fR \fBElements of procedure\fR .sp 1P .RT .sp 2P .LP 3.1 \fIGeneral\fR .sp 1P .RT .PP 3.1.1 The paragraphs below contain elements of procedure and rules of use which, when combined, define the control procedures. .sp 9p .RT .PP 3.1.2 Definitions applying to the elements of procedure may be found in Annexes\ A and\ B. .PP 3.1.3 Annex\ D describe the session suspension function, which is not applicable to the basic services. .sp 1P .LP 3.2 \fISession commands, responses and parameters\fR .sp 9p .RT .PP (For a summary of session commands and responses, see Table\ 1/T.62.) .RT .sp 2P .LP 3.2.1 \fICommand session start (CSS)\fR .sp 1P .RT .PP 3.2.1.1 The CSS initiates entry into a session. .bp .sp 9p .RT .PP 3.2.1.2 Command parameters are: .sp 9p .RT .LP a) \fIService identifier\fR \ \(em\ this mandatory parameter identifies whether the sender of this command intends to use the Telematic service . .LP b) \fITerminal identifier\fR \ \(em\ this mandatory parameter identifies the calling terminal in accordance with the terminal identification specified in Recommendation\ F.200. .LP c) \fIDate and time\fR \ \(em\ this mandatory parameter gives date and time information as specified in Recommendation\ F.200. .LP d) \fIAdditional session reference number\fR \ \(em\ 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 reference is not sufficient to uniquely identify the session and such unique identification is required. If the additional session reference number is not used, the parameter shall not be included. .LP e) \fINon\(hybasic terminal capabilities\fR \ \(em\ these parameters indicate which of the non\(hybasic 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 functions listed in these table. Absence of the parameter indicates that the specific function is not available. .LP f ) \fINon\(hybasic session capabilities\fR \ \(em\ if used, this non\(hymandatory parameter indicates which non\(hybasic session capabilities are available as receiving capabilities of the sender of this command. .LP \fINote\fR \ \(em\ Examples of the use of this parameter are session suspension (see Annex\ D) and negotiation of the window size for checkpoint (see \(sc\(sc\ 3.3.2.7 and\ 4.3). .LP g) \fIInactivity timer\fR \ \(em\ this non\(hymandatory parameter is used to negotiate the value of the inactivity timer (see \(sc\(sc\ 4.1.2 and\ 5.7.2.11). .LP h) \fISession service functions\fR \ \(em\ this non\(hymandatory 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). .LP \fINote\fR \ \(em\ Examples of the use of this parameter are for further study in association with Annex\ F. .LP i) \fISession user data\fR \ \(em\ this non\(hymandatory parameter 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. .LP j) \fINon\(hystandardized capabilities\fR \ \(em\ this non\(hymandatory parameter is used to ascertain compatibility regarding the use of non\(hystandardized terminal capabilities. .LP 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. .LP k) \fIPrivate use parameters\fR \ \(em\ these parameters are not mandatory. Their definition and use are not standardized. .sp 2P .LP 3.2.2 \fIResponse session start positive (RSSP)\fR .sp 1P .RT .PP 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. .sp 9p .RT .PP 3.2.2.2 Response parameters are: .sp 9p .RT .LP a) \fIService identifier\fR \ \(em\ this mandatory parameter identifies whether the sender of this response intends to use the Telematic service . .LP \fINote\ 1\fR \ \(em\ For the basic Teletex services, the service identifiers in RSSP and CSS must be identical. .LP \fINote\ 2\fR \ \(em\ In case of interconnections between the terminals of different services, the service identifiers in RSSP and CSS may not be identical. .LP b) \fITerminal identifier\fR \ \(em\ this mandatory parameter provides the terminal identification of the sender of the RSSP in accordance with the terminal identification specified in Recommendation\ F.200. .bp .LP c) \fIDate and time\fR \ \(em\ 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. .LP d) \fIAdditional session reference number\fR \ \(em\ 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. .LP e) \fINon\(hybasic terminal capabilities\fR (i.e. those available as receiving capabilities of the sender of the RSSP)\ \(em\ the same conditions apply as for \(sc\ 3.2.1.2\ e) above. .LP f ) \fINon\(hybasic session capabilities\fR \ \(em\ as for \(sc\ 3.2.1.2\ f ) above. .LP g) \fISession control functions\fR \ \(em\ this parameter is used to indicate \*Qrequest control\*U and \*Qrequest session suspension\*U as defined in this Recommendation. .LP h) \fIInactivity timer\fR \ \(em\ as for \(sc\ 3.2.1.2\ g) above. .LP i) \fISession service functions\fR \ \(em\ as for \(sc\ 3.2.1.2\ h) above. .LP j) \fISession user data\fR \ \(em\ as for \(sc\ 3.2.1.2\ i) above. .LP k) \fINon\(hystandardized capabilities\fR \(em as for \(sc\ 3.2.1.2\ j) above. .LP l) \fIPrivate use parameters\fR \ \(em\ as for \(sc\ 3.2.1.2\ k) above. .ce \fBH.T. [T3.62]\fR .ce TABLE\ 3/T.62 .ce \fBNon\(hybasic terminal capabilities included in CSS\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(78p) | lw(150p) . .TE .nr PS 9 .RT .ad r \fBTableau 3/T.62 [T3.62], p.3\fR .sp 1P .RT .ad b .RT .sp 2P .LP 3.2.3 \fIResponse session start negative (RSSN)\fR .sp 1P .RT .PP 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\(hymandatory private\(hyuse parameter may be used with this response. .sp 9p .RT .PP \fINote\fR \ \(em\ It should be noted that existing equipment may send an RSSN without any parameter fields. This shall not be regarded as an error. .bp .PP 3.2.3.2 Response parameters are: .sp 9p .RT .LP a) \fIService identifier\fR \ \(em\ this mandatory parameter identifies whether the sender of this response intends to use the telematic service. .LP \fINote\ 1\fR \ \(em\ For the basic services, the service identifiers in RSSN and CSS must be identical. .LP \fINote\ 2\fR \ \(em\ In case of interconnections between the terminals of different services, the service identifiers in RSSN and CSS may not be identical. .LP b) \fITerminal identifier\fR \ \(em\ this mandatory parameter provides the terminal identification of the sender of the RSSN in accordance with the terminal identification specified in Recommendation\ F.200. .LP c) \fIDate and time\fR \ \(em\ 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. .LP d) \fIAdditional session reference number\fR \ \(em\ 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. .LP e) \fINon\(hybasic terminal capabilities\fR (i.e. those available as receiving capabilities of the sender of the RSSN)\ \(em\ the same conditions apply as for \(sc\ 3.2.1.2\ e) above. .LP f ) \fINon\(hybasic session capabilities\fR \ \(em\ as for \(sc\ 3.2.1.2\ f ) above. .LP g) \fIReason for sending the negative response\fR \ \(em\ 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: .LP \(em no reason given; .LP \(em temporarily unable to enter the session. Shall be used e.g. in the case of memory full; .LP \(em text message of maximum 69 characters. It may be possible for the operator to enter this message from the keyboard. .LP h) \fISession service functions:\fR as for \(sc\ 3.2.1.2\ h) above. .LP i) \fISession user data:\fR as for \(sc\ 3.2.1.2\ i) above. .LP j) \fIPrivate use parameters:\fR as for \(sc\ 3.2.1.2\ k) above. .sp 2P .LP 3.2.4 \fICommand session end (CSE)\fR .sp 1P .RT .PP 3.2.4.1 The CSE is used for normal (or error\(hyfree) termination of a session. .sp 9p .RT .PP \fINote\fR \ \(em\ A parameter is reserved to indicate whether the transport connection is to be cleared. Absence of this parameter will cause the transport connection to be cleared. .sp 2P .LP 3.2.5 \fIResponse session end positive (RSEP)\fR .sp 1P .RT .PP 3.2.5.1 The RSEP indicates to the calling terminal that the called terminal has entered the idle state in an orderly manner. .sp 9p .RT .sp 2P .LP 3.2.6 \fICommand session abort (CSA)\fR .sp 1P .RT .PP 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. .sp 9p .RT .PP 3.2.6.2 One of the following reasons for the abnormal termination of the session must be given as a CSA parameter: .sp 9p .RT .LP a) local terminal error; .LP b) unrecoverable procedural error; .LP c) reason not defined. .PP \fINote\fR \ \(em\ One value is reserved to indicate whether the transport connection is to be cleared. .sp 2P .LP 3.2.7 \fIResponse session abort positive (RSAP)\fR .sp 1P .RT .PP 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. .bp .sp 9p .RT .sp 2P .LP 3.2.8 \fICommand session user information (CSUI)\fR .sp 1P .RT .PP 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. .sp 9p .RT .PP 3.2.8.2 CSUI does not call for a response. There is no relationship between this command and the response RSUI. .sp 2P .LP 3.2.9 \fIResponse session user information (RSUI)\fR .sp 1P .RT .PP 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\(hymandatory parameter, session control function, may be used with this response. .sp 9p .RT .PP 3.2.9.2 This RSUI response is not related to any CSUI command. .PP 3.2.9.3 The parameter, session control functions , is sent with RSUI in conjunction with document response. Use of this parameter with RSUI but without an associated document response is permitted 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. .sp 2P .LP 3.2.10 \fICommand session change control (CSCC)\fR .sp 1P .RT .sp 1P .LP 3.2.10.1\ \ In the two\(hyway alternate (TWA) mode CSCC changes the source/sink relationship between the two terminals. .sp 9p .RT .PP \fINote\fR \ \(em\ 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 terminal receiving this signal is not required to take any action if this signal is detected. .sp 2P .LP 3.2.11 \fIResponse session change control positive (RSCCP)\fR .sp 1P .RT .sp 1P .LP 3.2.11.1\ \ The RSCCP indicates to the sender of the CSCC that the sink terminal intends to enter the session sending state. .sp 9p .RT .LP 3.3 \fISession procedures\fR .sp 1P .RT .sp 2P .LP 3.3.1 \fISession modes of operation\fR .sp 1P .RT .PP 3.3.1.1 The following provisions concern the TWA mode of session operation: .sp 9p .RT .LP a) the basic protocol provides the capability of the TWA mode; .LP 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; .LP c) the CSCC exchanges the source/sink relationship between the two terminals. The CSCC command should only be invoked outside document boundaries. .LP d) only the terminal that is currently the source terminal may send the CSCC; .LP e) there is no requirement for sending text information prior to sending a CSCC; .LP f ) when the called terminal has finished transmitting text, it shall hand back the right of sending text to the calling terminal. Only the calling terminal is allowed to send CSE. .PP 3.3.1.2 The following provisions concern the one\(hyway communication (OWC) mode of session operation: .sp 9p .RT .LP a) the OWC mode is achieved by the CSS sender not issuing a CSCC; .LP b) there is no requirement to send text information. .LP c) this mode is a subset of TWA. .bp .sp 2P .LP 3.3.2 \fIRules for session elements of procedure\fR .sp 1P .RT .PP 3.3.2.1 Only the terminal that has established the transport connection (the calling terminal) shall send CSS. .sp 9p .RT .PP 3.3.2.2 It is the responsibility of the sender of CSS to examine 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). .PP 3.3.2.3 In continuing the session, neither terminal is permitted 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\(hybasic session and terminal capabilities parameters of the CSS/RSSP exchange at session initiation and/or by the parameters of CDCL/RDCLP exchange. .PP 3.3.2.4 In the TWA or OWC mode, only the sender of CSS may send CSE when he is the current source. .PP 3.3.2.5 In the TWA mode, the recipient of both CSS and CSCC must terminate his period as source by sending CSCC. .PP 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 session abort procedure : .sp 9p .RT .LP a) the session abort procedure is in general completed when the sender of a CSA command receives an RSAP response; .LP 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\(hyout (e.g.\ T\ =\ 4\ seconds), the terminal that send the CSA clears the transport connection. .LP \fINote\fR \ \(em\ In all cases the transport connection must be cleared when the CSA timer has expired. .PP 3.3.2.7 The following rules should apply to the use of window size : .sp 9p .RT .LP a) the indication of the window size parameter is not .LP 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; .LP b) all the Teletex terminals should support a window 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\(hymode capability) and all Group\ 4 facsimile terminals may require other window sizes; .LP 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); .LP 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. .PP 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 \*Qa)\*U 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. .sp 9p .RT .PP 3.3.2.9 In a session where the use of the RSUI with request control is permitted (as specified in \(sc\ 3.2.9.3), the following will apply: .sp 9p .RT .LP a) an RSUI requesting control may be received after giving control and before receiving any valid session protocol element. This shall not be regarded as a procedural error and shall be discarded; .LP 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. .bp .LP .rs .sp 47P .ad r \fBFigure\ 1/T.62, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 3.4 \fIDocument commands, responses and parameters\fR .sp 9p .RT .PP (For summary of document commands and responses, see Table\ 2/T.62.) .RT .sp 2P .LP 3.4.1 \fICommand document start (CDS)\fR .sp 1P .RT .PP 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. .sp 9p .RT .PP 3.4.1.2 Command parameters are: .sp 9p .RT .LP a) \fIService interworking identifier\fR \ \(em\ not a mandatory field (see \(sc\ 3.5.2). .LP \fINote\fR \ \(em\ When communicating with a conversion facility , an identifier may be required for: .LP i) Teletex/telex interworking \(em 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; .LP ii) Teletex/Videotex interworking \(em for further study; .LP iii) Teletex/facsimile interworking \(em for further study. .LP b) \fIDocument type identifier\fR \ \(em\ 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). .LP c) \fIDocument reference number\fR \ \(em\ (see \(sc\ 4.2.9). .LP d) \fIIndication of required terminal capability\fR (standardized or private use)\ \(em\ not a mandatory field, however, this parameter must be used if standardized optional terminal capabilities are required for the document. .LP e) \fISession user data\fR \ \(em\ this non\(hymandatory parameter 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. .LP f ) \fIPrivate use parameters\fR (not mandatory)\ \(em\ definition of such parameters is not standardized. .PP 3.4.1.3 There is no response to CDS except in the case of an error, for which RDGR is used. .sp 9p .RT .sp 2P .LP 3.4.2 \fIResponse document general reject (RDGR)\fR .sp 1P .RT .PP 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 resynchronization 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. .sp 9p .RT .PP 3.4.2.2 The response parameter is the bit pattern required by \(sc\ 3.4.2.1. .PP 3.4.2.3 It is the responsibility of the terminal receiving an RDGR response to take appropriate action. .PP \fINote\fR \ \(em\ Use of RDGR for other kinds of error is for further study. .sp 2P .LP 3.4.3 \fICommand document continue (CDC)\fR .sp 1P .RT .PP 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. .sp 9p .RT .PP 3.4.3.2 Command parameters are: .sp 9p .RT .LP a) \fIDocument linking information\fR , in order to identify the previous transmission of the partial document, including: .LP \(em the checkpoint reference number (see \(sc\ 4.2.7) from which the transmission is being continued; .LP \(em the document reference number, which shall be the same as the document reference number in the CDS; .LP \(em the session reference information identifying the session in which the first part of the document was sent. .bp .LP \fINote\ 1\fR \ \(em\ If several continuations are required to complete transmission of a document, all are linked to the partial transmission in which the CDS was used. The sequence of checkpoint reference numbers is then used to identify the correct sequencing for linking and all such continuations shall be transmitted in this sequence. .LP \fINote\ 2\fR \ \(em\ It is the responsibility of the receiving terminal to discard any text information that has been duplicated in the process of continuation of an interrupted transmission. .LP \fINote\ 3\fR \ \(em\ The checkpoint reference number appearing in CDC is the last checkpoint reference number for which a positive acknowledgement has been received. .LP b) \fIService interworking identifier\fR \ \(em\ not a mandatory field (see the note under \(sc\ 3.4.1.2\ a) for CDS). .LP c) \fIDocument type identifier\fR \ \(em\ 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 inclusion of this field is obligatory (for a description of types of document, see Annex\ E). .LP d) \fIDocument reference number\fR (of the current session): see \(sc\ 4.2.9. .LP 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 capabilities 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. .LP f ) \fISession user data\fR \ \(em\ this non\(hymandatory parameter 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. .PP 3.4.3.3 There is no response to CDC except in the case of an error, for which RDGR is used. .sp 9p .RT .sp 2P .LP 3.4.4 \fICommand document capability list (CDCL)\fR .sp 1P .RT .PP 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 capabilities that may be needed at the receiver by the sender of this command. .sp 9p .RT .PP 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\(hyoctets) is indicated in a parameter of the command in this case. .PP 3.4.4.3 Command parameters are the list of receiving capabilities and the required amount of storage. .PP 3.4.4.4 The CDCL command should only be invoked outside document boundaries. .PP 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. .PP 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 protocol parameters defined in the T.400 series of Recommendations is contained in this parameter field. .PP 3.4.4.7 The CDCL command may be used to ascertain compatibility regarding the use of non\(hystandardized capabilities. .sp 2P .LP 3.4.5 \fIResponse document capability list positive (RDCLP)\fR .sp 1P .RT .PP 3.4.5.1 The RDCLP response is sent by the receiver of a CDCL command as a positive acknowledgement of the command. .bp .sp 9p .RT .PP 3.4.5.2 If the CDCL command includes the information to check the non\(hybasic Teletex terminal capabilities, the corresponding RDCLP response has to contain one of the following: .sp 9p .RT .LP a) confirmation that all the requested capabilities are available at the receiver by use of \*Qacceptance of CDCL parameters\*U; .LP b) a list of capabilities available at the receiver by use of the \*Qnon\(hybasic Teletex terminal capabilities\*U parameter. This will indicate one of the following: .LP \(em the complete list of all the capabilities requested in the CDCL; .LP \(em a list of the requested capabilities that are available at the receiver. Absence of parameters associated with non\(hybasic capabilities indicated that the requested capabilities are not available at the receiver; .LP \(em a complete list of non\(hybasic receiving capabilities, irrespective of the requested ones. .PP 3.4.5.3 If the CDCL is used for memory negotiation, one of the following shall be included in the RDCLP: .sp 9p .RT .LP a) confirmation that the amount of memory requested is available and has been reserved; .LP b) indication of the available (and reserved) amount of memory (in kilo\(hyoctets); .LP c) indication the requested memory capacity cannot now be reserved; .LP 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). .LP \fINote\ 1\fR \ \(em\ Storage that has been reserved by the CDCL command can be released after session termination or when a new CDCL with storage requirement indication is received. .LP \fINote\ 2\fR \ \(em\ 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. .PP 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. .sp 9p .RT .PP 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 protocol parameters defined in the T.400 Series of Recommendations is contained in this parameter field. .sp 9p .RT .PP 3.4.5.6 The RDCLP response may be used to ascertain compatibility regarding the use of the non\(hystandardized and private use capabilities. .sp 9p .RT .sp 2P .LP 3.4.6 \fICommand document end (CDE)\fR .sp 1P .RT .PP 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. .sp 9p .RT .PP 3.4.6.2 The command parameter is the checkpoint reference number. .PP 3.4.6.3 The RDPBN shall be used as the negative response to the checkpoint in CDE. .sp 2P .LP 3.4.7 \fIResponse document end positive (RDEP)\fR .sp 1P .RT .PP 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. .bp .sp 9p .RT .PP 3.4.7.2 The RDEP shall also indicate that the receiver: .sp 9p .RT .LP a) has not detected any error; .LP b) accepts responsibility for the received document; and .LP c) is ready to receive a new CDS or CDC. .PP 3.4.7.3 The RDEP shall include as a parameter the checkpoint reference number of the CDE. .sp 9p .RT .PP 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. .sp 9p .RT .sp 2P .LP 3.4.8 \fICommand document discard (CDD)\fR .sp 1P .RT .PP 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. .sp 9p .RT .PP \fINote\ 1\fR \ \(em\ CDD is an invitation to discard the whole of the document and not merely the part of the document transmitted since the last CDC. .PP \fINote\ 2\fR \ \(em\ 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. .PP \fINote\ 3\fR \ \(em\ The implementation of this function for Group\ 4 facsimile is for further study. .RT .PP 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: .sp 9p .RT .LP a) unable to continue a session (e.g. due to memory full, out of recording paper); .LP b) sequence error; .LP c) local terminal error; .LP d) unrecoverable procedural error; .LP e) no specific reason stated (used for reasons other than those listed). .PP 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 \(sc\ 4.3.2). .sp 9p .RT .PP 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. .sp 9p .RT .PP 3.4.8.5 \fR No negative response to CDD is allowed except for error conditions where RDGR applies. .sp 9p .RT .sp 2P .LP 3.4.9 \fIResponse document discard positive (RDDP)\fR .sp 1P .RT .PP 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. .sp 9p .RT .sp 2P .LP 3.4.10 \fICommand document resynchronize (CDR)\fR .sp 1P .RT .sp 1P .LP 3.4.10.1\ \ The CDR shall be used by the source to indicate to the sink the point of resynchronization . If used within a document it shall abnormally end that document. .bp .sp 9p .RT .sp 1P .LP 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 reasons may be given: .sp 9p .RT .LP a) unable to continue a session (e.g.\ due to memory full, out of recording paper); .LP b) sequence error; .LP c) local terminal error; .LP d) unrecoverable procedural error; .LP e) no specific reason stated (used for reasons other than those listed). .sp 1P .LP 3.4.10.3\ \ No negative response to CDR is allowed except for error conditions where RDGR applies. .sp 9p .RT .sp 2P .LP 3.4.11 \fIResponse document resynchronize positive (RDRP)\fR .sp 1P .RT .sp 1P .LP 3.4.11.1\ \ The RDRP is sent by the receiver of a CDR as a positive acknowledgement of the command. .sp 9p .RT .LP 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. .LP 3.4.11.3\ \ The control procedures provide a means for resuming transmission of an interrupted document. .LP 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. .sp 2P .LP 3.4.12 \fICommand document user information (CDUI)\fR .sp 1P .RT .sp 1P .LP 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. .sp 9p .RT .LP 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 information field is for further study. .LP 3.4.12.3\ \ Several CDUIs may be used to transfer the contents of one page. .sp 2P .LP 3.4.13 \fICommand document page boundary (CDPB)\fR .sp 1P .RT .sp 1P .LP 3.4.13.1\ \ The CDPB indicates to the receiver the boundary between pages. It also indicates a checkpoint for error recovery purposes (see \(sc\ 4). CDPB invites the sink to accept responsibility for the previously received page. .sp 9p .RT .LP 3.4.13.2\ \ The CDPB command parameter is the checkpoint reference number, which, in the basic services, is the page reference number. .LP 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. .sp 2P .LP 3.4.14 \fIResponse document page boundary positive (RDPBP)\fR .sp 1P .RT .sp 1P .LP 3.4.14.1\ \ This response shall be used to indicate that the receiver accepts responsibility for that page. .sp 9p .RT .sp 1P .LP 3.4.14.2\ \ Response parameters are: .sp 9p .RT .LP a) a mandatory parameter giving the checkpoint reference number (see \(sc\ 3.4.13.2 above); .LP 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). .bp .sp 2P .LP 3.4.15 \fIResponse document page boundary negative (RDPBN)\fR .sp 1P .RT .sp 1P .LP 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. .sp 9p .RT .PP \fINote\fR \ \(em\ This response may also be returned at any point within the document boundary after the receipt of CDS. .sp 1P .LP 3.4.15.2\ \ The value of the mandatory parameter giving the reason for a negative response should be one of the following: .sp 9p .RT .LP a) unable to continue a session (e.g. due to memory full, out of recording paper); .LP b) sequence error; .LP c) local terminal error; .LP d) unrecoverable procedural error; .LP e) no specific reason stated (used for reasons other than those listed). .sp 2P .LP 3.5 \fIGeneral rules for\fR \fIdocument elements of procedure\fR .sp 1P .RT .PP 3.5.1 When a document has been either started by CDS or continued by CDC, it must be terminated by either CDE, CDR or CDD prior to sending the next CDS or CDC. .sp 9p .RT .PP 3.5.2 The following rules relate to the CDS and CDC parameters: .sp 9p .RT .LP a) the service interworking parameter may be used to indicate that the document is suitable for interworking; however, use of this parameter is mandatory in the case of service interworking; .LP b) absence of the document type identifier indicates that the associated document is a normal document. .PP 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 document. No negative response may be sent to any document commands once the checkpoint associated with those commands has been positively acknowledged. .sp 9p .RT .PP 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. .sp 9p .RT .PP 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. .sp 9p .RT .LP a) In the case that a document transmission is initiated by a CDS and no checkpoint is positively acknowledged during that document transmission: .LP \(em the receiving terminal shall treat the failure as if a CDD had been received and an RDDP had been sent; .LP \(em the sending terminal shall treat the failure as if a CDD had been sent and an RDDP had been received. .LP b) In other cases: .LP \(em the receiving terminal shall treat the failure as if a CDR had been received and an RDRP had been sent; .LP \(em the sending terminal shall treat the failure as if a CDR had been sent and an RDRP had been received. .bp .PP 3.5.6 If, during the transmission of a document, an abnormal condition except those described in \(sc\ 3.5.5 takes place, the following rules apply: .sp 9p .RT .LP a) in the case that a document transmission is initiated 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; .LP b) in other cases, a CDD or CDR should be used. .PP 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: .sp 9p .RT .LP a) if the source subsequently receives an RDPBP with the RAJ parameter set to 0, it will be able to continue transmission; .LP b) if the source subsequently receives an RDPBN indicating \*Qmemory overflow\*U, the document transmission should be terminated abnormally; e.g. exchange of either CDD/RDDP or CDR/RDRP. .PP \fINote\fR \ \(em\ 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. .PP 3.5.8 When a sink terminal sends an RDPBP with the receiving ability jeopardized parameter set to 1, and subsequent memory overflow results in sending RDPBN, the reason code \*Qunable to continue the session\*U has to be indicated. .sp 9p .RT .LP 3.6 \fIRules for document state diagrams\fR .sp 1P .RT .sp 2P .LP 3.6.1 \fIGeneral\fR .sp 1P .RT .PP 3.6.1.1 The rules common to all state diagrams are given in Annex\ D. .sp 9p .RT .PP 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. .sp 2P .LP 3.6.2 \fIRules for the sending protocol\fR (see Figure 2/T.62) .sp 1P .RT .PP 3.6.2.1 Any command or response received in state 1 shall cause an abnormal end of the session and sending of CSA. .sp 9p .RT .PP 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 \(sc\ 3.5.6. .PP 3.6.2.3 Reception of any command or response except RDCLP in state 14 shall cause CDR to be sent. .PP 3.6.2.4 In state 13 receipt of RDRP or RDDP will cause a transition to state 1. Any other command or response will be discarded. .PP 3.6.2.5 The demand response timer started when state 13 is entered is only reset when a valid response is received. .sp 2P .LP 3.6.3 \fIRules for the receiving protocol\fR (see Figure 3/T.62) .sp 1P .RT .PP 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. .sp 9p .RT .PP 3.6.3.2 In state 12 receipt of CDR or CDD will cause a transition to state 13. Any other command or response received will be discarded. .PP 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. .PP 3.6.3.4 The inactivity timer started when state 12 is entered is only reset when a valid command is received. .bp .LP .rs .sp 47P .ad r \fBFigure 2/T.62, p.5\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 3/T.62, p.5\fR .sp 1P .RT .ad b .RT .LP .bp .LP \fB4\fR \fBError recovery\fR .sp 1P .RT .sp 2P .LP 4.1 \fIGeneral principles\fR .sp 1P .RT .PP 4.1.1 During a session, each partner is responsible for monitoring for the correct operation of the following: .sp 9p .RT .LP a) maintenance of the currently agreed source/sink relationship; .LP b) proper use of the command/response procedural sequences as described in the state diagrams and rules for operation (see \(sc\ 3.6); .LP c) detection of any period of inactivity in excess of the inactivity timer value as determined by negotiation (indicating, for example, a failure or other inability to continue productive use of the session); .LP 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. .LP \fINote\fR \ \(em\ Negotiation of the demand response timer value is for further study. .PP 4.1.2 The following rules apply to the negotiation of the value of the inactivity timer; .sp 9p .RT .LP a) an inactivity timer value different from 60 seconds will apply only if this parameter is indicated by both terminals, i.e. negotiation, at session establishment (via CSS/RSSP) or document boundaries (via CDCL/RDCLP); .LP 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: .LP i) The smaller of the two values applies when both values are greater than or equal to 60 seconds. .LP ii) The larger of the two values applies when both values are less than 60 seconds. .LP iii) A timer value of 60 seconds applies if one value is above and one is below 60 seconds. .PP 4.1.3 Upon detection of any failure to maintain proper operation as described in \(sc\ 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. .sp 9p .RT .sp 2P .LP 4.2 \fIRules for checkpointing\fR .sp 1P .RT .PP 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. .sp 9p .RT .PP 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: .sp 9p .RT .LP a) the reference for the interrupted session; .LP b) the document reference number; and .LP c) the checkpoint reference number. .PP 4.2.3 In the basic services a checkpoint must be inserted at each page boundary using CDPB. .PP 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. .PP 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. .PP 4.2.6 No other checkpointing is permitted in the basic service. .bp .PP 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. .PP 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. .PP 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 successive document. DRNs shall be assigned to all documents in a session, 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. .PP \fINote\fR \ \(em\ 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. .PP 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. .sp 2P .LP 4.3 \fIAcknowledgement window\fR .sp 1P .RT .PP 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 \(sc\ 5.7.2.6). .sp 9p .RT .PP 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 \(sc\(sc\ 3.3.2.7 and\ 5.7.2.6). .sp 9p .RT .PP 4.3.3 There are two ways that the sender is permitted to recover from an interrupted transmission: .sp 9p .RT .LP a) a cancellation is achieved by the subsequent use of CDC and CDD commands and the transmission will be resumed by the CDS command; .LP 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. .PP 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. .PP 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 problems without affecting the continuous transmission. .sp 9p .RT .PP \fINote\fR \ \(em\ For efficiency reasons, the receiving terminal will transmit the response to acknowledge outstanding checkpoint(s) as soon as possible. .PP 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 service requirements in Recommendations\ F.200 and F.161. .sp 9p .RT .PP 4.3.6 If transmission flow control is needed, it shall be provided by the transport service. .bp .sp 9p .RT .LP \fB5\fR \fBCoding\fR .sp 1P .RT .sp 2P .LP 5.1 \fIDefinition of terms used in coding\fR .sp 1P .RT .sp 1P .LP 5.1.1 \fBcommand identifier (CI) or response identifier (RI)\fR .sp 9p .RT .LP \fIF:\ identificateur de commande (IC) ou de r\*'eponse (IR)\fR .LP \fIS:\ identificador de instrucci\*'on (II) o identificador de\fR \fIrespuesta (IR)\fR .PP The heading information that identifies the command or response concerned. .RT .sp 1P .LP 5.1.2 \fBlength indicator (LI)\fR .sp 9p .RT .LP \fIF:\ indicateur de longueur (IL)\fR .LP \fIS:\ indicador de longitud (IL)\fR .PP Represents the length in octets of an associated field or group of fields. .RT .sp 1P .LP 5.1.3 \fBparameter identifier (PI)\fR .sp 9p .RT .LP \fIF:\ identificateur de param\*`etre (IP)\fR .LP \fIS:\ identificador de par\*'ametro (IP)\fR .PP Indicates the type of information contained in an associated field or group of fields. .RT .sp 1P .LP 5.1.4 \fBparameter group identifier (PGI)\fR .sp 9p .RT .LP \fIF:\ identificateur de groupe de param\*`etres (IGP)\fR .LP \fIS:\ identificador de grupo de par\*'ametros (IGP)\fR .PP 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. .RT .sp 1P .LP 5.1.5 \fBparameter value (PV)\fR .sp 9p .RT .LP \fIF:\ valeur de param\*`etre (VP)\fR .LP \fIS:\ valor de par\*'ametro (VP)\fR .PP The information that represents the value of the parameter identified by either a PI or PGI. .RT .sp 1P .LP 5.1.6 \fBfield\fR .sp 9p .RT .LP \fIF:\ champ; domaine\fR .LP \fIS:\ campo\fR .PP 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. .RT .sp 2P .LP 5.2 \fIPrinciples of coding\fR .sp 1P .RT .PP 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. .sp 9p .RT .PP 5.2.2 Binary field encoding principles have been used to allocate bit patterns for the CI, RI, PGI and PI. .PP 5.2.3 The first section of a session or document field consists of either a CI or an RI. Each CI or RI is always immediately followed by an LI. .bp .PP 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. .PP 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. .PP 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. .PP 5.2.7 To decode CI, RI, PGI and PI, all the bits of the identifier must be considered. .PP 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. .PP 5.2.9 The absence of non\(hymandatory PI or PGI indicates that no such functions are available. Therefore PIs or PGIs with LI set to zero should be avoided. .PP 5.2.10 Figures 4/T.62, 5/T.62 and 6/T.62 illustrate the coding principles. .LP .rs .sp 32P .ad r \fBFigure 4/T.62, p. .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 30P .ad r \fBFigure 5/T.62, p. .sp 1P .RT .ad b .RT .LP .rs .sp 21P .ad r \fBFigure 6/T.62, p. .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP 5.3 \fICoding of\fR \fIlength indicators\fR .sp 1P .RT .PP 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 \(sc\ 5.2.5 above. .sp 9p .RT .PP 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). .PP 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. .PP 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. .sp 2P .LP 5.4 \fICoding of command and response identifiers for session\fR \fIelements\fR .sp 1P .RT .PP 5.4.1 The coding of CI and RI for session commands and responses is shown in Table\ 4/T.62. .sp 9p .RT .PP 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: .sp 9p .RT .LP Bit 1 1\ =\ Command 0\ =\ Response .LP Bit 2 1\ =\ Positive 0\ =\ Negative (for responses) .LP Bit 3 1\ =\ Initiate 0\ =\ Stop (for most commands) .LP Bits 4,\ 5 11\ Session .LP 10\ Session .LP 01\ Interaction .LP 00\ Session user .LP Bits 6,\ 7,\ 8 Set to zero (except for private use) and reserved for extension. .PP \fINote\fR \ \(em\ If possible, this binary field coding structure should be followed in making future code assignments, but this is not mandatory if the number of available code combinations is insufficient. Therefore, it is not intended as a guide for implementation. .PP 5.4.3 One or more of the non\(hyallocated values are to be reserved for future extension. The method of future extension is for further study. .sp 9p .RT .sp 2P .LP 5.5 \fICoding of command and response identifiers for document\fR \fIelements\fR .sp 1P .RT .PP 5.5.1 The coding of command and response identifiers for document commands and responses is shown in Tables\ 5/T.62 and\ 6/T.62 respectively. .sp 9p .RT .PP 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: .sp 9p .RT .LP Bit 1 1\ =\ Command 0\ =\ Response .LP Bit 2 1\ =\ Positive 0\ =\ Negative (for responses) .LP Bit 3 1\ =\ Initiate 0\ =\ Stop (for most commands) .LP Bits 4,\ 5,\ 6 111,\ 110,\ 101 Document .LP 100 Reserved .LP 011 Page .LP 010 Reserved .LP 001 Reserved for recovery unit .LP 000 Text .LP Bits 7,\ 8 Set to zero, and reserved for future extension. .PP 5.5.3 With regard to future extension, see the note in \(sc\ 5.4.2 and \(sc 5.4.3 above. .bp .sp 9p .RT .ce \fBH.T. [T4.62]\fR .ce TABLE\ 4/T.62 .ce \fBCommand and response identifiers for session elements\fR .T& lw(60p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) . .T& rw(60p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) . { TABLE\ 5/T.62 \fBCoding for document command identifiers\fR } .T& 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. .T& lw(60p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) . .TE .nr PS 9 .RT .ad r \fBTable 4/T.61 [T4.62], p.\fR .sp 1P .RT .ad b .RT .ce \fBH.T. [T5.62]\fR .ce TABLE\ 5/T.62 .ce \fBCoding for document command identifiers\fR .T& lw(60p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) . .TE .nr PS 9 .RT .ad r \fBTable 5/T.61 [T5.62], p.\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [T6.62]\fR .ce TABLE\ 6/T.62 .ce \fBCoding for document response identifiers\fR .T& lw(60p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) . .TE .nr PS 9 .RT .ad r \fBTable 6/T.61 [T6.62], p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 5.6 \fICoding of\fR \fIparameter group identifiers\fR \fIand\fR \fIparameter identifiers\fR .sp 1P .RT .PP 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. .sp 9p .RT .PP 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 procedure together with an indication of whether the PGIs and PIs concerned are mandatory or not. .PP 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 preceding PGIs as defined in Tables\ 9/T.62 and 10/T.62. .PP 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: .sp 9p .RT .LP Bits 876 .LP 000 Session related .LP 001 Document related (These document related PGIs and PIs may possibly .LP be of use to other services.) .LP 010 Document related (for Teletex) .LP 011 .LP 100 Reserved .LP 101 .LP 110 User data .LP 111 Private use .PP The binary field consisting of bits 5 and 4 may be interpreted as follows: .LP Bits 54 .LP 00\ PGI .LP 01\ PI .LP 10\ PI .LP 11\ PI .PP The binary field consisting of bits 3, 2 and 1 is used to extend the PGIs when set to 000. .bp .PP \fINote\fR \ \(em\ If possible, this binary field coding structure should be followed in making future code assignments, but this is not mandatory if the number of available code combinations is insufficient. Therefore, it is not intended as a guide for implementation. .RT .PP 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. .sp 9p .RT .PP 5.6.6 The following rules shall apply to the private use and presently not defined parameters: .sp 9p .RT .LP a) these parameters, if present in CSS or CDCL (or their corresponding responses), shall not lead to procedural errors; .LP 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 \(sc\ 3.3.2.3); .LP c) presence of these parameters \*Qunexpectedly\*U in elements other than CSS, RSSP, CDCL or RDCLP may result in procedural errors; .LP 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. .LP 5.7 \fIParameter values\fR .sp 1P .RT .sp 2P .LP 5.7.1 \fIGeneral\fR .sp 1P .RT .PP 5.7.1.1 Unless otherwise specified the following rules apply to the fields containing parameter values (PV): .sp 9p .RT .LP 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; .LP b) All bits reserved for future standardization shall be set to zero; .LP 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; .LP d) For a PGI designated for extension, the PIs and/or PGIs included in the parameter field do not necessarily conform to the following assignments of PI and PGI values. .PP 5.7.1.2 Assignment of coding to the various parameter values is shown in the following paragraphs. .sp 9p .RT .sp 1P .LP 5.7.2 \fISession related parameters\fR .sp 9p .RT .PP \fINote\fR \ \(em\ The following paragaphs include either session related or both session and document related parameters. .RT .sp 1P .LP 5.7.2.1 \fITerminal identifier of the called terminal\fR .sp 9p .RT .PP A sequence of graphic characters as defined in Recommendation\ F.200. .RT .sp 1P .LP 5.7.2.2 \fITerminal identifier of the calling terminal\fR .sp 9p .RT .PP A sequence of graphic characters as defined in Recommendation\ F.200. .RT .sp 1P .LP 5.7.2.3 \fIDate and time\fR .sp 9p .RT .PP A sequence of graphic characters as defined in Recommendation\ F.200. .RT .sp 1P .LP 5.7.2.4 \fIAdditional session reference number\fR .sp 9p .RT .PP A fixed length sequence of two decimal digits as coded in Recommendation\ T.61. .bp .RT .ce \fBH.T. [T7.62]\fR .ce TABLE\ 7/T.62 .ce \fBCoding of session PGIs and PIs\fR .T& lw(66p) | lw(48p) | lw(66p) | lw(48p) . .TE .nr PS 9 .RT .ad r \fBTableau 7/T.62 [T7.62], p.13\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [1T8.62]\fR .ce .ce TABLE\ 8/T.62 .ce \fBCoding of document PGIs and PIs\fR .T& lw(66p) | lw(48p) | lw(66p) | lw(48p) . .TE .nr PS 9 .RT .ad r \fBTableau 8/T.62 [1T8.62], p.14\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [2T8.62]\fR .ce TABLE\ 8/T.62 \fI(continued)\fR .T& lw(66p) | lw(48p) | lw(66p) | lw(48p) . .TE .nr PS 9 .RT .ad r \fBTableau 8/T.62 [2T8.62], p.15\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [1T9.62]\fR .ce TABLE\ 9/T.62 .ce \fBPGIs and PIs for session elements of procedure\fR .T& lw(30p) | lw(72p) | lw(30p) | lw(66p) | lw(30p) . .T& lw(30p) | lw(72p) | lw(30p) | lw(66p) | lw(30p) . Session control functions nm .TE .nr PS 9 .RT .ad r \fBTableau 9/T.62 [1T9.62], p.16\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [2T9.62]\fR .ce TABLE\ 9/T.62 \fI(continued)\fR .T& lw(228p) . .TE .nr PS 9 .RT .ad r \fBTableau 9/T.62 [2T9.62], p.17\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [3T9.62]\fR .ce TABLE\ 9/T.62 \fI(end)\fR .T& lw(30p) | lw(72p) | lw(30p) | lw(66p) | lw(30p) . .TE .nr PS 9 .RT .ad r \fBTableau 9/T.62 [3T9.62], p.18\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [1T10.62]\fR .ce TABLE\ 10/T.62 .ce \fBPGIs and PIs for document elements of procedure\fR .T& 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. .TE .nr PS 9 .RT .ad r \fBTableau 10/T.62 [1T10.62], p.19\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [2T10.62]\fR .ce TABLE\ 10/T.62 \fI(continued)\fR .T& lw(228p) . .TE .nr PS 9 .RT .ad r \fBTableau 10/T.62 [2T10.62], p.20\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [3T10.62]\fR .ce TABLE\ 10/T.62 \fI(continued)\fR .T& lw(30p) | lw(72p) | lw(30p) | lw(66p) | lw(30p) . .TE .nr PS 9 .RT .ad r \fBTableau 10/T.62 [3T10.62], p.21\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [4T10.62]\fR .ce .ce TABLE\ 10/T.62 \fI(end)\fR .T& lw(30p) | lw(72p) | lw(30p) | lw(66p) | lw(30p) . .TE .nr PS 9 .RT .ad r \fBTableau 10/T.62 [4T10.62], p.22\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 5.7.2.5 \fIMiscellaneous session capabilities\fR .sp 9p .RT .PP Bit 1 of the first octet set to 1 indicates the terminal capability for two\(hyway simultaneous information transfer. .PP Bit 2 of the first octet set to 1 indicates the terminal capability for session suspension. .PP Bit 3 of the first octet set to 1 indicates the terminal capability for interactive operation. .PP All other bit values are reserved for future standardization. .RT .sp 1P .LP 5.7.2.6 \fIWindow size\fR .sp 9p .RT .PP 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). .RT .sp 1P .LP 5.7.2.7 \fIService identifier\fR .sp 9p .RT .PP The coding for the service identifier is as follows: .RT .LP Bits 87654321 Service .LP 00000001 Telematic .PP All other encodings are for further study. .sp 1P .LP 5.7.2.8 \fISession control functions\fR .sp 9p .RT .PP When used with a response, i.e. either RSSP or RSUI, the following bit assignments are defined in the first octet: .RT .LP a) bit 1 set to 1 indicates request control (as defined in this Recommendation); .LP b) all other bits are reserved for future standardization. .sp 1P .LP 5.7.2.9 \fISession termination parameter\fR .sp 9p .RT .PP Bit 1 of the first octet set to 1 indicates that the transport connection shall be cleared (default value). When set to 0 it indicates that the connection should not be cleared. .PP Bit 2 of the first octet set to 1 indicates a local terminal error. .PP Bit 3 of the first octet set to 1 indicates an unrecoverable procedural error. .PP Bit 4 of the first octet set to 1 indicates that no reason is given. .PP All other bits are reserved for future standardization. The CSE command uses only bit\ 1; all other bits shall be set to\ 0. .RT .sp 1P .LP 5.7.2.10 \fIReason (session or document)\fR .sp 9p .RT .PP A field indicating the reason for sending the associated command or response. The value can either be given as a binary coded field or as plain text message. The absence of this parameter indicates that no reason is given. .RT .LP Bits 87654321 \fIReason\fR .LP 00000000 No specific reason stated (used for session or document reasons other than those listed); .LP 00000001 Temporarily unable to enter into, or to continue, a session (e.g. due to memory full or out of recording paper); .LP 00000010 Explicit text message only for use with RSSN (see Note\ 1); .LP 00000011 Sequence error (Note 2); .LP 00000101 Local terminal error (Note 2); .LP 00000110 Unrecoverable procedural error (Note\ 2). .LP \fINote\ 1\fR \ \(em\ For the basic Teletex service, the text follows immediately after the first byte of the value. Maximum of 69 characters (control characters included). Only characters convertible one\(hyto\(hyone to the telex alphabet (ITA2) shall be allowed. Teletex code shall be used. .LP \fINote\ 2\fR \ \(em\ These parameter values are valid only in document commands and responses. .bp .sp 1P .LP 5.7.2.11 \fIInactivity timer\fR \v'3p' .sp 9p .RT .LP 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. .LP Bits 87 \fIUnit of timer\fR .LP 00 Second(s); .LP 01 Minute(s); .LP 10 Hour(s); .LP 11 Reserved for extension. .LP b) All bits of the first octet set to zero indicates the inactivity timer value is of infinity, i.e. the timer is disabled. .sp 1P .LP 5.7.2.12 \fISession service functions\fR .sp 9p .RT .PP The parameter value is indicated by a sequence of two octets. .RT .LP a) In octet 1: .LP Bits 8\(hy4\ (Note\ 1) Reserved (set to 0). .LP Bit 3 Set to 1 to indicate the typed data capability (for further study). .LP Bit 2\ (Note\ 2) Set to 1 to indicate the ability to send RDPBN. .LP Bit 1\ (Note\ 2) Set to 1 to indicate the ability to send/receive CDCL/RDCLP. .LP b) In octet 2: .LP Bits 8,\ 6,\ 5\ and\ 3\ (Note\ 1) Reserved (set to 0). .LP Bit 7\ (Note\ 2) Set to 1 to indicate the capability of document transfer. .LP Bit 4\ (Note\ 2) Set to 1 to indicate the capability of page synchronization [CDPB/RDPBP(N)]. .LP Bits 2\(hy1\ (Note\ 3) Set to 0 1 to indicate \*Qhalf duplex\*U .LP Set to 1 0 to indicate \*Qduplex\*U .LP \fINote\ 1\fR \ \(em\ All bits reserved should be ignored when comparing capabilities indicated in CSS and RSSP. .LP \fINote\ 2\fR \ \(em\ The indicated bits should be set (to 1 for document transfer and to 0 for no document transfer) as a unit. .LP \fINote\ 3\fR \ \(em\ Half\(hyduplex and duplex are for further study. .PP The absence of this parameter should be interpreted as the following default values: .LP Bits 87654321 .LP Octet\ 1: 00000011 .LP Octet\ 2: 01001001 .sp 1P .LP 5.7.2.13 \fINon\(hystandardized capabilities\fR .sp 9p .RT .PP The first octet represents the registered CCITT country code as specified in Recommendation\ T.35 to be used to identify non\(hystandard capabilities. Additional octets, may be specified by each country's Administration. .RT .sp 1P .LP 5.7.2.14 \fISession user data\fR .sp 9p .RT .PP 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. .bp .RT .sp 1P .LP 5.7.2.15 \fIPrivate use\fR .sp 9p .RT .PP A set of PGI and PI values is designated as being for private use. Other than the PGIs designated for extensions and the permitted use of private parameters only with certain command and responses, the use of these parameters is not defined. .RT .sp 1P .LP 5.7.3 \fIDocument related parameters\fR .sp 9p .RT .PP \fINote\fR \ \(em\ The following paragraphs include parameters commonly used by basic Teletex and Group\ 4 facsimile services. .RT .sp 1P .LP 5.7.3.1 \fIService interworking identifier\fR .sp 9p .RT .PP Bit 1 of the first octet set to 1 shall indicate that the associated document is suitable for forwarding via the telex service. .PP All other bit values are reserved for future standardization. .RT .sp 1P .LP 5.7.3.2 \fIDocument reference number\fR .sp 9p .RT .PP A sequence of decimal digits as defined in this Recommendation and coded in Recommendation\ T.61. .RT .LP .sp 1P .LP 5.7.3.3 \fICheckpoint reference number\fR .sp 9p .RT .PP A sequence of decimal digits as defined in this Recommendation and coded in Recommendation\ T.61. .RT .sp 1P .LP 5.7.3.4 \fIAcceptance of CDCL parameters\fR .sp 9p .RT .PP Bit 1 of the first octet set to 1 indicates acceptance of all non\(hybasic terminal capabilities which are defined in this Recommendation and requested by a CDCL command. .PP All other bit values are reserved for future standardization. .PP \fINote\fR \ \(em\ Bit 1 of the first octet set to 1 does not indicate accepance of non\(hybasic terminal capabilities conveyed in the session under data of CDCL. .RT .sp 1P .LP 5.7.3.5 \fIStorage capacity negotiation\fR .sp 9p .RT .PP A fixed length sequence of two octets: .RT .LP a) Bit 1 of the first octet set to 1 indicates that a terminal has reserved the requested amount of storage. .LP b) Bit 2 of the first octet set to 1 indicates that the binary field in the following octet contains a number indicating storage capacity required/reserved in kilo\(hyoctets. .LP 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\(hyoctets. .LP 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\(hyoctets. .LP e) Bit 3 of the first octet set to 1 indicates that a terminal cannot estimate its memory capacity. .LP f ) Bit 4 of the first octet set to 1 indicates that a terminal cannot now reserve the requested amount of memory. .LP 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\(hyoctets, bit\ 2 shall be used. .LP \fINote\fR \ \(em\ Use of bit 5 or 6 for negotiation of a storage capacity greater than 65\ kilo\(hyoctets but less than or equal to 255\ kilo\(hyoctets is not to be interpreted as a procedural error by the receiver. .LP h) Bits 7 and 8 of the first octet are reserved for future standardization. .PP 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. .PP In cases a), e) and f ), the second octet may be ignored by the recipient of RDCLP. .bp .RT .sp 1P .LP 5.7.3.6 \fIReceiving ability jeopardized\fR .sp 9p .RT .PP The first octet shall be encoded as follows: .RT .LP Bits 87654321 \fIMeaning\fR .LP 00000000 Further traffic can be accepted. .LP 00000001 Ability to receive further traffic is jeopardized. .PP All other binary values are reserved for future standardization. .sp 1P .LP 5.7.3.7 \fIDocument type identifier\fR .sp 9p .RT .PP 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: .RT .LP Bits 87654321 \fIType of document\fR .LP 00000001 Operator document. .LP 00000010 Control document. .LP 00000011 Monitor document. .PP All other encodings are reserved for future standardization. .sp 1P .LP 5.7.3.8 \fIReflect parameter value\fR .sp 9p .RT .PP This is an arbitrary length field that contains the bit pattern of the command or response up to and including the detected error. .RT .sp 1P .LP 5.7.4 \fIDocument related parameter for teletex\fR .sp 9p .RT .PP \fINote\fR \ \(em\ The following parameters may also be used by services other than teletex. .RT .sp 1P .LP 5.7.4.1 \fIControl character sets\fR (refer to Recommendations T.60 and T.61) .sp 9p .RT .PP A variable length field indicating the receiving capability for non\(hybasic standardized control character sets. Each such control 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. .RT .sp 2P .LP 5.7.4.2 \fIGraphic character sets\fR (refer to Recommendations T.60 and\ T.61) .sp 1P .RT .sp 1P .LP 5.7.4.2.1\ \ A variable length field indicating the receiving capabilities for non\(hybasic standardized graphic character sets. Each such graphic character sets or DRCS (Dynamically redefinable character 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. .sp 9p .RT .sp 1P .LP 5.7.4.2.2\ \ The following descriptions apply to the use of a DRCS set for Japanese Kanji and Chinese ideogram characters: .sp 9p .RT .LP 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); .LP 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. .PP \fINote\fR \ \(em\ The PV field of this parameter in either CDS or CDC will be as follows: \v'6p' .sp 1P .ce 1000 DRCS\ CC\d1\u\ DP\d1\u\ CC\d2\u\ DP\d2\u. | | CC\fI\fI\d\fIi\fR\u\ DP\fI\fI\d\fIi\fR\u .ce 0 .sp 1P .LP .sp 1 .bp .sp 1P .LP 5.7.4.3 \fITeletex page formats\fR (refer to Recommendations T.60 and T.61) .sp 9p .RT .PP The value of the first octet of the parameter value will indicate 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. .RT .LP .ce \fBH.T. [T11.62]\fR .ce TABLE\ 11/T.62 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(24p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(42p) | lw(114p) . .T& lw(24p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(42p) | lw(114p) . { 0 0 0 0 0 0 0 1 (option) ISO A4, horizontal and vertical } .T& lw(24p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(42p) | lw(114p) . { 0 0 0 0 0 0 1 0 (option) North American, horizontal and vertical } .T& lw(24p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(42p) | lw(114p) . { 1 0 0 0 0 1 0 0 (option) ISO A4 extended (ISO standard 3535), vertical } .T& lw(24p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(42p) | lw(114p) . { 0 1 0 0 0 1 0 0 (option) ISO A4 extended (ISO standard 3535), horizontal } .T& lw(24p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(42p) | lw(114p) . { 1 0 0 0 1 0 0 0 (option) North American legal, vertical } .T& lw(24p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(42p) | lw(114p) . { 0 1 0 0 1 0 0 0 (option) North American legal, horizontal } .T& lw(24p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(42p) | lw(114p) . { 0 0 0 0 0 0 1 1 (option) ISO A4, horizontal and vertical (for use by Japanese Kanji and Chinese ideogram terminals) } .T& lw(24p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(42p) | lw(114p) . { 0 0 0 1 0 0 0 0 (option) ISO B5, horizontal and vertical (for use by Japanese Kanji and Chinese ideogram terminals) } .T& lw(24p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(6p) | lw(42p) | lw(114p) . { 0 0 1 0 0 0 0 0 (option) ISO B4, horizontal and vertical (for use by Japanese Kanji and Chinese ideogram terminals) } .TE .LP \fINote\ 1\fR \ \(em\ 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 \*Qcombine\*U the indication of several formats into the same octet by setting more than one bit to \*Qone\*U. .LP \fINote\ 2\fR \ \(em\ The following rule is used for the coding of bits 7 and 8: .LP Bits 8\ 7 \fIMeaning\fR .LP 0\ 0 Vertical and horizontal 0\ 1 Horizontal only 1\ 0 Vertical only. .RT .ad r \fBTable 11/T.62 [T11.62], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 5.7.4.4 \fIMiscellaneous terminal capabilities\fR (refer to Recommendation\ T.61) .sp 9p .RT .PP A variable length field indicating the receiving capabilities for non\(hybasic standardized values of character spacing, line spacing and graphic renditions. Each parameter value of such a function shall be indicated by the control sequence (CSI P\fI\fI\d\fIi\fR\uI\fI\fI\d\fIi\fR\uF) as defined in Recommendation\ T.61. This applies to the functions Select Horizontal Spacing\ (SHS) for a character pitch, Select Vertical Spacing (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. .bp .RT .sp 1P .LP 5.7.4.5 \fICharacter box height\fR .sp 9p .RT .PP 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. .PP Further study is required for indicating more than one value. .RT .sp 1P .LP 5.7.4.6 \fICharacter box width\fR .sp 9p .RT .PP 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. .PP Further study is required for indicating more than one value. .RT .LP .rs .sp 43P .sp 2P .LP \fBMONTAGE:\ \fR ANNEXE A SUR LE RESTE DE CETTE PAGE .sp 1P .RT .LP .bp