5i' Recommendation T.62 | fIbis CONTROL PROCEDURES FOR TELETEX AND G4 FACSIMILE SERVICES BASED ON RECOMMENDATIONS X.215 AND X.225 CONTENTS 0 Introduction 1 Scope and field of application 2 References 3 Actions for performing the control procedures for Teletex and Group 4 facsimile 3.1 General 3.2 Session connection extablishment phase 3.3 Session termination phase 3.4 Document management 3.5 Miscellaneous 4 Usage of the session service 4.1 General 4.2 Session connection establishment 4.3 Session termination phase 4.4 Data transfer phase 5 Recommendations for implementing the session layer 5.1 Additional parameters 5.2 Implementation choices ANNEX A ANNEX B ANNEX C ANNEX D 0 Introduction 0.1 This Recommendation is related to other Recommendations. In particular it is related to certain Recommendations as defined by the Reference Model for Open Systems Interconnection (X.200). This Recommendation is based on the description of the session service (X.215) and the session protocol (X.225) as shown in Figure 1/T.62 | fIbis Figure 1/T.62 | is [T16.62] (a traiter comme tableau), p. Note 1 - Only the services and protocol elements relevant to Recommendation T.62 procedures are used (see Table 1/T.62 | fIbis in S 4.1). Note 2 - The session protocol described in Recommendation X.225 is based on the services provided by the transport layer as described in Recommendations X.214 and X.224. For compatibility with Teletex and Group 4 facsimile addi- tional rules (in accordance with Recommendation T.70, S 5, includ- ing Annexes A and B) must be applied when using the transport ser- vice and protocol (Recommendations X.214 and X.224, class 0). 0.2 The control procedure for Teletex and Group 4 facsimile are currently described in Recommendation T.62. Recommendation T.62 may be superseded by this Recommendation and the appropriate session layer service and protocol described in the Recommendations X.215 and X.225. When using either Recommendation T.62 | fIbis (based on the X-Series Recommendations) or Recommendation T.62 (based on Recommendation T.70) it is intended that the externally visible protocols are equal. It is the intention that Recommendations X.215 and X.225 together with this Recommendation do have tha same level of detail and accuracy as Recommendation T.62 already has. However, for the time being Recommendation T.62 will be kept and in cases of discrepancy and/or incompatibility, Recommendation T.62 will take precedence over Recommendations X.215 and X.225 together with the application rules described in this Recommendation. This Recommendation covers all of Recommendation T.62 includ- ing the Annexes. 1 Scope and field of application This Recommendation defines: 1) A set of rules for using the OSI Session Ser- vice. 2) The additional requirements for the implementa- tion to conform to the control procedures for Teletex and Group 4 facsimile services. The set of rules consists of: - The actions to be taken by the session user for performing the control procedures. - The description of the use of the session ser- vice primitives and their parameters. - The encoding of parameters not covered by the session layer (for these parameters see also S 5.2). These parame- ters are described as additional parameters for each primitive and each SPDU where appropriate. The length and value of these parame- ters are provided by the SS-user and no checking is made by the session layer itself. 2 References Recommendations F.161, F.200, X.215, X.225, T.563, T.503, T.521, T.6, T.35, T.60, T.61, T.62, T.400-Series, T.390 and X.200. 3 Actions for performing the control procedures for Teletex and Group 4 facsimile This section describes the Teletex application protocol in terms of actions involving the session service primitives. 3.1 General The control procedures for Teletex and Group 4 facsimile are designed to allow data to be transferred and managed between termi- nals in the form of documents. The present Recommendation only pro- vides for the transfer of documents. As a consequence, no transfer of data can take place outside a document. - A document is composed of one or more pages . - Pages are sent sequentially and each page has to be individually acknowledged . However, several pages may be sent without waiting for the acknowledgement and the number of pages which can be sent in this manner is called the window-size . - The transfer of a document is executed from the source to the sink (see SS 3.2.3 and 3.4). For the purpose of the description, in the remainder of the text, the source is also called the sender and the sink is also called the receiver . 3.2 Session connection establishment phase 3.2.1 The calling SS-user initiates the connection by issuing the S-CONNECT request primitive. The called SS-user may accept or refuse the connection by issuing the S-CONNECT response primitive. It is the responsibility of the initiator of the connection to examine the parameters sent by the remote terminal at session ini- tiation and to determine whether the session should continue. If it is not to be continued, the session shall be ended normally. 3.2.2 A session connection is identified by means of: a) the basic session reference (mandatory parame- ter) composed of: - terminal identifier of the called terminal; - terminal identifier of the calling terminal; - date and time; b) an optional additional session reference number, to uniquely identify the session connection. 3.2.3 At session connection establishment, the data, minor synchronize and major/activity tokens shall be available and assigned to the initiator side. Thus at session initiation the ini- tiator is defined as being the current source of text information and is therefore the source terminal. 3.2.4 When accepting the connection the called SS-user may request the session control by issuing the primitive S-TOKEN-PLEASE request. 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-basic session and terminal capabili- ties parameters of the S-CONNECT primitives at session initiation and/or by the parameters of S-CAPABILITY-DATA primitives. 3.2.5 The following rules shall apply to the private use and presently not defined parameters: a) The use of these parameters in other primitives than S-CONNECT and S-CAPABILITY-DATA must be negotiated upon in advance by S-CONNECT or S-CAPABILITY-DATA. Presence of these param- eters unexpectedly in other primitives may result in procedural errors. b) The absence of a parameter of this kind in a response to S-CONNECT or S-CAPABILITY-DATA must be interpreted as an indication that the terminal is not capable of handling any of these functions. 3.3 Session termination phase The session connection is terminated by means of the S-RELEASE services for normal (or error-free) termination. The S-U-ABORT/S-P-ABORT services 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 success- fully. S-U-ABORT/S-P-ABORT shall only used when there is no other suitable way of ending the session. In the two-way alternate or one way communication mode, only the sender of the S-CONNECT request may send the S-RELEASE request when he is the current source. Note - The transport connection may be reused as a local implementation choice and this may depend on an application deci- sion which may be passed across the session service interface. 3.4 Document management The document concept, as defined in Recommendation T.62, is mapped onto the activity concept of the session protocol. Consequently, the document number corresponds to the activity iden- tifier. The transfer of a document is delimited by a start and an end. A document is sent by the source (sender) to the sink (receiver) and this transfer may only take place when the source owns all the available tokens. When the sink wants to send a document it may express this requirement by issuing a S-TOKEN-PLEASE primitive. When the transfer of a document is terminated, the sender may give the con- trol to the receiver by issuing a S-CONTROL-GIVE primitive. But there is no requirement for sending text information prior to issu- ing a S-CONTROL-GIVE primitive. When the protocol element exchange corresponding to this primitive is executed, all the tokens are assigned to the receiver; consequently it becomes the source (or sender) and the former source becomes the sink (or receiver). A document transfer may then be started from the new source to the new sink. 3.4.1 Start of document The S-ACTIVITY-START service indicates the start of a docu- ment. It also indicates the start of the first page. 3.4.2 Page boundaries 3.4.2.1 The S-SYNC-MINOR service indicates the boundary between pages. It also indicates a checkpoint for error recovery purposes and invites the sink to accept responsibility for the pre- viously received page. In the basic services a checkpoint must be inserted at each page boundary using S-MINOR-SYNC request. Each checkpoint must be explicitly ack- nowledged in the right sequence, by using S-SYNC-MINOR response. Consequently the checkpoint reference number corresponds to the minor synchronization point serial number. The S-SYNC-MINOR response shall be used to indicate that the receiver accepts responsibility for that page. If the receiver does not accept the responsibility for the page he shall use the S-U-EXCEPTION-REPORT service. In this case the transmission must be interrupted by the sender using the S-ACTIVITY-INTERRUPT or DISCARD services. The receiver may reject reception for a detected error, but he is not obliged to check the document for errors. Once a page has been positively acknowledged, any error recovery for the subsequent detection of an error is beyond the scope of these control pro- cedures. 3.4.2.2 When a source terminal receives an S-SYNC-MINOR confirmation with the receiving ability jeopardized (RAJ) parameter set to 1 (see S 4.4.6) during a document transmission, it may con- tinue 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 S-SYNC-MINOR confirmation with the RAJ parameter set to 0 (see S 4.4.6), it will be able to continue transmission; b) if the source subsequently receives an S-U-EXCEPTION-REPORT with a parameter value "SS-user receiving ability jeopardized" (indicating "memory overflow"), the document transmission should be terminated abnormally. The source shall issue either a S-ACTIVITY-DISCARD request or a S-ACTIVITY-INTERRUPT request. 3.4.2.3 When a sink terminal sends an S-SYNC-MINOR response with the receiving ability jeopardized parameter set to 1, and sub- sequent memory overflow results in sending S-U-EXCEPTION-REPORT, the value of the reason code will be "SS-user receiving ability jeopardized" (indicating "unable to continue the session"). 3.4.3 End of document 3.4.3.1 The S-ACTIVITY-END service shall be used to indicate the end of a document. It also indicates the end of the final page and as such represents the final checkpoint. The S-ACTIVITY-END response gives a positive acknowledgement to the last checkpoint. In the basic services this is the last page reference number. When confirming this service, the receiver shall indicate that: a) he has not detected an error; b) he accepts responsibility for the received docu- ment; c) he is ready to receive a new S-ACTIVITY-START or S-ACTIVITY-RESUME request. To refuse the checkpoint indicated in S-ACTIVITY-END indica- tion, the SS-user shall use the S-U-EXCEPTION-REPORT service. 3.4.3.2 Only if the sink terminal has sent an S-ACTIVITY-END response and received a valid S-ACTIVITY-START, S-ACTIVITY-RESUME, S-ACTIVITY-DATA, S-DISCONNECT or S-CONTROL-GIVE indication, it is certain that the source terminal will not use error recovery pro- cedures regarding the preceding document. In all other cases it can happen that after sending an S-ACTIVITY-END response a repetition of pages takes place and the duplications may be deleted by the sink terminal. 3.4.4 Interruption of a document Documents may be interrupted or discarded by using the S-ACTIVITY-INTERRUPT or S-ACTIVITY-DISCARD services. 3.4.4.1 The S-ACTIVITY-INTERRUPT service shall be used to indicate the abnormal ending of a document but the part of the document received so far should not be discarded. When the receiver of a document sends a S-ACTIVITY-INTERRUPT response, this means that he has already accepted the responsibility for the received document (up to the last checkpoint for which a positive ack- nowledgement has been sent). It does not indicate that he will be able to perform the linking of the followig parts of the inter- rupted document. 3.4.4.2 The S-ACTIVITY-DISCARD service shall be used to indi- cate the abnormal ending of a document and that the receiver of the document is not held responsible for the part of the document received so far. Therefore, as a local function outside these con- trol procedures, the receiver can delete the part of the text received. Note 1 - The S-ACTIVITY-DISCARD service is an invitation to discad the whole of the document and not merely the part of the document transmitted since the last S-ACTIVITY-RESUME. Note 2 - The receiving terminal may discard the document from its memory (but has no obligation to do so) and/or indicate to the operator that this part of the document has no value. If the text is not deleted, the operator shall be informed. Note 3 - The use of the S-ACTIVITY-DISCARD service for Group 4 facsimile is for further study. 3.4.4.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 the S-ACTIVITY-RESUME and S-ACTIVITY-DISCARD services and the transmission will be resumed by the S-ACTIVITY-START service; b) the sender may resume by use of the S-ACTIVITY-RESUME service, starting at that point in the document corresponding to the last checkpoint for which an acknowledgement was received. 3.4.4.4 If, during document transmission, an abnormal condi- tion occurs, with the exception of the one described in S 3.4.4.5, the following rules apply: a) In the case that a document transmission was initiated by S-ACTIVITY-START request and no minor synchronization point has been positively acknowledged, either the S-ACTIVITY-DISCARD or INTERRUPT service should be used. If the S-ACTIVITY-INTERRUPT service is used it should be interpreted as an S-ACTIVITY-DISCARD. In this case, however, it is necessary to reply with an S-ACTIVITY-INTERRUPT response to the S-ACTIVITY-INTERRUPT indication as required by the session service definition. It is only a matter of different semantic interpretation of the service by the session service user. b) In all other cases S-ACTIVITY-INTERRUPT or DIS- CARD service should be used. 3.4.4.5 The following rules apply if the session is aborted during document transmission: a) If document transmission was initiated by S-ACTIVITY-START request and no minor synchronization point has been positively acknowledged during that transmission, both sending and receiving entities shall treat the failure as if the S-ACTIVITY-DISCARD service had been correctly initiated and com- pleted. b) In other cases, both sending and receiving enti- ties shall treat the failure as if the S-ACTIVITY-INTERRUPT service had been correctly initiated and completed. 3.4.5 Resumption of a document The S-ACTIVITY-RESUME service indicates the continuation of a document that has previously been partially transmitted. The linking of the parts of an interrupted document is a local operation at the receiver and is therefore not within the responsi- bility of the control procedures. Thus these procedures cannot guarantee that this linking of parts of a document will be effected. Note 1 - The checkpoint reference number appearing in the primitive S-ACTIVITY-RESUME is the last checkpoint reference number for which a positive acknowledgement has been received. It should be noted that positive acknowledgement may have been sent by the sink terminal but not received by the source terminal. Note 2 - If several continuations are required to complete transmission of a document, they are all linked to the partial transmission in which the activity start service was used. The sequence of checkpoint reference numbers is then used to identify the correct sequencing of parts to be linked, this sequence and all such continuations must be transmitted in this order. Note 3 - It is the responsibility of the receiver to discard any text information that has been duplicated in the process of continuation of an interrupted transmission. 3.4.6 Exchange of terminal capabilities Outside document transfer (outside activities) the S-CAPABILITY-DATA service may be used to exchange information to enable a check of the terminal capabilities (both standardized and private use) and to investigate the storage capability of the remote terminal. The primitive shall include a parameter with a list of receiv- ing capabilities that may be needed at the receiver by the sender of this primitive. Storage that has been reserved by the S-CAPABILITY-DATA ser- vice can be released after session termination or when a new S-CAPABILITY-DATA indication with storage requirement indication is received. 3.4.7 Exception conditions 3.4.7.1 Detection of a protocol error may cause the SS-provider to issue a S-P-EXCEPTION-REPORT indication. On receipt of a S-P-EXCEPTION-REPORT indication, the SS-user shall use the S-ACTIVITY-INTERRUPT or S-ACTIVITY-DISCARD service (subject to the tokens restrictions); it may also use the S-U-ABORT service. 3.4.7.2 The receiver of a document may issue an S-U-EXCEPTION-REPORT request at any time after having received an S-ACTIVITY-START or S-ACTIVITY-RESUME indication. It may issue an S-U-EXCEPTION-REPORT request after having received an S-SYNC-MINOR indication, or an S-ACTIVITY-END indication instead of giving the confirmation. When receiving an S-U-EXCEPTION-REPORT indication, the SS-user shall use either the S-ACTIVITY-INTERRUPT or S-ACTIVITY-DISCARD service; it may also use the S-U-ABORT service. 3.5 Miscellaneous 3.5.1 Acknowledgement window 3.5.1.1 The window mechanism has been introduced in order to allow continuous transmission of pages. It may also be used by the receiving terminal to resolve local time problems without affecting the continuous transmission. Note - For efficiency reasons, the receiving terminal will transmit the response to acknowledge outstanding checkpoing(s) as soon as possible. The design of the 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. In the basic Teletex service, the sender is prohibited from exceeding an acknowledgement window size of three. The maximum win- dow size may be negotiated during session establishment. 3.5.1.2 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 (in the S-CONNECT request and response). It may have a value in the range of 1 to 255. The absence of this parameter in S-CONNECT request or response must be interpreted as the default value of three for the Teletex service. b) All 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-mode capabil- ity) and all Group 4 facsimile terminals may require other window sizes. c) The source terminal is free to use any window size that does not exceed the window size indicated by the sink terminal (in S-CONNECT request or response). d) If the sender of S-CONNECT request or 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.5.2 Negotiation of optional capabilities Two methods are provided. The first is used at session initia- tion to exchange a limited list of capabilities (S-CONNECT ser- vice). The second method may be used when required, after session initiation, to indicate the sender's requirements for extended capabilities (S-CAPABILITY-DATA, S-ACTIVITY-START, S-ACTIVITY-RESUME services). 3.5.3 Negotiation of storage requirements 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 con- tinued 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 esta- blished, it can only be assumed that the called terminal has ade- quate 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. Hav- ing 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. 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 S-CAPABILITY-DATA service also provides the possibility to investigate the storage availability at the receiv- ing terminal prior to the transmission of a document. 3.5.4 Timer handling The timer handling is based on the occurrence of certain events. These events may be protocol elements or service primi- tives and it is assumed that there is no time delay between the occurrence of a session service primitive and the related protocol element and vice versa. Two types of timer are defined: - inactivity timer; - demand-response timer. 3.5.5 Inactivity timer 3.5.5.1 During the lifetime of a session correction each partner is responsible for detection of any period of inactivity in excess of inactivity timer value determined by negotiation (indi- cating, for example, a failure or another inability to continue productive use of the session). 3.5.5.2 The inactivity timer is used by the sink terminal to detect any period during which no protocol element is exchanged. Such period must be detected whenever the transport connection exists. This timer is started or restarted on reception or sending of each event by the sink terminal when further action is expected from the source terminal. This timer is stopped on reception of an event by the sink terminal when no further action is expected from the source termi- nal. When the timer expires, the S-ABORT service shall be used. Further information can also be found in Figure B-1/T.62 | fIbis . 3.5.5.3 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 S-CONNECT) or document boundaries (via S-CAPABILITY-DATA). 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. 3.5.6 Demand response timer 3.5.6.1 This timer is responsible for detection of any period of time during which the sink terminal has failed to send a response/acknowledgement. The value of that timer is 60 seconds. Negotiation of the demand response timer value is for further study. 3.5.6.2 In general, this timer has to be started for each event which is issued by the source terminal towards the sink ter- minal and for which a response/acknowledgement is expected. It is stopped when a response is received. When the timer expires, the S-ABORT service shall be used. 3.5.6.3 In the following special cases, specific actions are required: - on the occurrence of an abort primitive/SPDU (sent or received), the demand response timer is stopped if it has been started; - reception of an exception-report indication (or associated SPDU) shall be considered as the response to the primi- tive (SPDU) sent previously. Consequently the associated action is to stop the timer. Further information can also be found in Figures B-1/T.62 | fIbis and B-2/T.62 | fIbis . 3.5.7 Document reference number 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 S-ACTIVITY-START or S-ACTIVITY-RESUME is used as the initiating primitive. The number does not necessarily have to comprise 3 digits and leading zeros do not necessarily have to be transmit- ted. In all cases the leading zeros 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 Usage of the session service (Recommendation X.215) 4.1 General The rules given hereinafter indicate how the session service must be used by the higher layer entity. It is assumed that where a parameter is non mandatory in the protocol, it is also non mandatory in the corresponding primitive. When a default value applies in the protocol, the same default value applies at the service interface. The services which are used are indicated in Table 1/T.62 | fIbis with the corresponding functional units. The data, synchronization minor and major/activity tokens must be available. The release token is not available. The term "additional parameter" as used in this Recommendation applies to parameters which are not included in the session service described by Recommendation X.215 but which are nevertheless essential to describe interaction between the session service user and the session layer itself, when it is to be used in a form com- patible with control procedures for Teletex and Group 4 facsimile (consequently they have to be taken into account when implementing the session layer for such use). These parameters contain informa- tion carried by the session protocol elements independently of the "user data" parameter contained in the session protocol elements which are described in S 3 of this document. 4.2 Session connection establishment The following service primitive is used: S-CONNECT. 4.2.1 The parameters of the S-CONNECT are used as follows 4.2.1.1 Session connection identifier a) The calling SS-user reference shall only con- tain the calling terminal identifier. This mandatory parameter (request and indication primitives) identifies the calling termi- nal. This is a sequence of graphic characters as defined in Recommendation F.200. b) The called SS-user reference shall only contain the called terminal identifier. This mandatory parameter (response and confirm primitives) provides the terminal identification of the sender of the S-CONNECT response primitive. This is a sequence of graphic characters as defined in Recommendation F.200. c) The common reference shall only contain the date and time. This parameter is both mandatory and identical on all primitives. It gives the date and time and it is a sequence of graphic characters as defined in Recommendation F.200. It is used in conjunction with the terminal identifications of both terminals in a session as a reference to that session. d) The additional reference information shall only contain the additional session reference number. If it is used by the initiator and by the responder, it shall have the same value in the response as in the request. If it is not used by the initiator it shall not be included in the request. If it is not used by the responder it shall not be included in the response. This number shall be used in addition to the basic session reference (calling and called terminal identifiers, date and time) when this basic session reference is not sufficient to uniquely identify the ses- sion and such unique identification is required. In this case it shall also be used together with the basic session reference, when referring to this session in an S-ACTIVITY-RESUME primitive. The reference number is a fixed length of two decimal digits as coded in Recommendation T.61. H.T. [T17.62] TABLE 1/T.62 bis _______________________________________________ Functional units Service primitives _______________________________________________ Kernel { S-CONNECT S-RELEASE S-U-ABORT S-P-ABORT S-DATA } _______________________________________________ Half duplex S-TOKEN-PLEASE _______________________________________________ Minor synchronisation S-SYNC-MINOR. _______________________________________________ Activity management { S-ACTIVITY-START S-ACTIVITY-RESUME S-ACTIVITY-INTERRUPT S-ACTIVITY-DISCARD S-ACTIVITY-END S-CONTROL-GIVE } _______________________________________________ Capability data exchange S-CAPABILITY-DATA _______________________________________________ Exceptions { S-P-EXCEPTION-REPORT S-U-EXCEPTION-REPORT } _______________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 1/T.62 | is [T17.62], p. 2 4.2.1.2 Calling and called SSAP addresses The session layer addressing is not used in Teletex and Group 4 facsimile services (these parameters are not used). 4.2.1.3 Quality of service This parameter must be set so as not to use expedited data (transport expedited is not available in Teletex) and in such a way that extended concatenation is not selected. 4.2.1.4 Session requirements This parameter may be omitted and in this case the default value applies. The following functional units shall be selected: - minor synchronization, - activity management, - capability data exchange, - half-duplex, - exceptions. 4.2.1.5 Initial synchronization point serial number This parameter is not used in Teletex and Group 4 facsimile services. 4.2.1.6 Initial assignment of tokens This parameter may be omitted and in that case, the default value applies. All available tokens are assigned to the calling entity. 4.2.1.7 Result (only in response and confirmation) This parameter is used to accept or refuse the session connec- tion. In case of refusal, this parameter may also convey up to 69 characters. Only characters convertible one-to-one to the telex alphabet (ITA2) shall be allowed and Teletex code shall be used. 4.2.1.8 User data This non-mandatory parameter is used to convey data of the presentation and/or application protocol(s). All information neces- sary to negotiate the document interchange protocol parameters defined in the T.400-Series of Recommendations is contained in this parameter field. 4.2.2 Additional parameters The following parameters may also be included: 4.2.2.1 Non-basic session capabilities If used, this non-mandatory parameter indicates which non-basic session capabilities are available as receiving capabili- ties of the sender of this primitive. H.T. [T18.62] TABLE 2/T.62 bis _______________________________________________________________________ Parameter Function Encoding _______________________________________________________________________ { Miscellaneous session capabilities } nm { - Session suspension - Interactive operation } 4.2.3.1 _______________________________________________________________________ Window size nm { - Negotiation of window size } 4.2.3.2 _______________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 2/T.62 | is [T18.62], p. 4.2.2.2 Service identifier This mandatory parameter indicates whether the sender of this primitive intends to use the Telematic services. Note 1 - For the basic Teletex services, the service identif- iers in the S-CONNECT request and response must be identical. Note 2 - In case of interconnections between the terminals of different services, the service identifiers in the S-CONNECT request and response may not be identical. 4.2.2.3 Inactivity timer This non-mandatory parameter is used to negotiate the value of the inactivity timer. 4.2.2.4 Non-basic terminal capabilities These parameters indicate which of the non-basic capabilities listed in the table below for the Teletex service, are available as receiving capabilities of the sender of this request. These parameters are mandatory if the equipment is capable of any of the specific functions listed in the table below. Absence of the param- eter indicates that the specific function is not available. H.T. [T19.62] TABLE 3/T.62 bis _____________________________________________________________________________________ Parameter Function Encoding _____________________________________________________________________________________ Control character sets nm Reverse line feed 4.2.3.5 _____________________________________________________________________________________ Page formats nm { ISO A4 vertical and horizontal orientation } 4.2.3.7 _____________________________________________________________________________________ { Miscellaneous terminal capabilities } nm { Character spacing of 2.12 mm (12 characters per 25.4 mm) Character spacing of 1.69 mm (15 characters per 24.4 mm) Line feed parameter value of one spacing of 3.175 mm Line feed parameter value of one spacing of 0.5, 1.0, 1.5 and two spacings of 5 mm } 4.2.3.8 _____________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 3/T.62 | is [T19.62], p. Note - The definitions of these presentation capabilities may be found in Recommendation T.60. Future extensions and private-use capabilities are to be accommodated with the capability data exchange service. 4.2.2.5 Private use parameters These parameters are not mandatory. Their definition and use are not standardized (see S 3.2). 4.2.2.6 Non-standardized capabilities This non-mandatory parameter is used to ascertain compatibil- ity regarding the use of non-standardized terminal capabilities. 4.2.3 Encoding of the S-CONNECT additional parameters value 4.2.3.1 Miscellaneous session capabilities This PV field shall indicate possible modes of operation. The encoding of the first octet shall be: a) bit 1: reserved b) bit 2: reserved (for session suspension) c) bit 3 set to 1 indicates the terminal capability for interactive operation (data transfer outside activity boun- daries). All other bits are reserved for future standardization. 4.2.3.2 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). 4.2.3.3 Service identifier The coding for the service identifier is as follows: Bits 87654321 Service 00000001 Telematic All other encodings are for further study. 4.2.3.4 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. 4.2.3.5 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. 4.2.3.6 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 Administration. 4.2.3.7 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 4/T.62 | fIbis . 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 4/T.62 | fIbis ). 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. [T20.62] TABLE 4/T.62 bis ________________________________________________________________________________________________________________________________________________________________________________________________ Bits 8 7 6 5 4 3 2 1 Format ________________________________________________________________________________________________________________________________________________________________________________________________ 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, as 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 <> the indication of several formats into the same octet by setting more than one bit to <>. Note 2 - The following rule is used for the coding of bits 7 and 8: Bits 8 7 Meaning Bits 0 0 Vertical and horizontal Bits 0 1 Horizontal only Bits 1 0 Vertical only. Table 4/T.62 | is [T20.62], p. 4.2.3.8 Miscellaneous terminal capabilities 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, PI LI F) as defined in Recommendation T.61. This applies to the function select horizonal 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 character orientation function (COF) 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. 4.3 Session termination phase The following service primitives are used: S-RELEASE S-U-ABORT S-P-ABORT 4.3.1 The parameters of the S-RELEASE are used as follows Result | this parameter will indicate "affirmative" (only in confirmation and response). SS-user-data | this parameter is not used in Teletex and Group 4 facsimile services. 4.3.2 S-U-ABORT Using this primitive will be interpreted as "local terminal error". SS-user-data | this parameter is not used in Teletex and Group 4 facsimile services. 4.3.3 S-P-ABORT Receipt of this primitive is defined in Recommendations X.215 and X.225. 4.4 Data transfer phase The following service primitives are used: S-ACTIVITY-START S-ACTIVITY-RESUME S-ACTIVITY-INTERPRET S-ACTIVITY-DISCARD S-ACTIVITY-END S-SYNC-MINOR S-U-EXCEPTION-REPORT S-P-EXCEPTION-REPORT S-CONTROL-GIVE S-TOKEN-PLEASE S-CAPABILITY-DATA S-DATA 4.4.1 S-ACTIVITY-START 4.4.1.1 The parameters of S-ACTIVITY-START are used as fol- lows - Activity identifier: This mandatory parameter shall contain the document reference number (see S 3.5.6). - SS-user-data: This non-mandatory 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. 4.4.1.2 Additional parameters The following parameters may also be included: a) 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. (Description of types of document are in Annex A.) b) Service interworking identifier : Not a manda- tory field. This parameter may be used to indicate that the docu- ment is suitable for interworking; however use of this parameter is mandatory in the case of service interworking. 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. c) Indication of required terminal capability (standardized or private use): Not a mandatory field, however, this parameter must be used if standardized optional terminal capabili- ties are required for the document. d) Private use parameters: Non mandatory. Defini- tion of such parameters is not standardized (see S 3.2). 4.4.1.3 Encoding of the S-ACTIVITY-START additional parame- ters value a) Document type identifier Absence of this parameter shall indicate a normal docu- ment. This parameter, if used, is a binary encoded field of fixed length of one octet identifying the documnent type as follows: Bits 87654321 Type of document 00000001 Operator document 00000010 Control document 00000011 Monitor document All other encodings are reserved for future standardiza- tion. b) 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 standardiza- tion. c) Indication of required terminal capability (non-basic Teletex terminal capabilities) - Graphic character sets (refer to Recommendations T.60 and T.61) A variable length field indicating the receiving capabili- ties for non-basic 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 charac- ter set are to be indicated, the ESC character fulfills the purpose of a separator between the character set indicators. The following descriptions apply to the use of a DRCS set for Japanese Kanji and Chinese ideogram characters: i) if the DRCS set is indicated as a parameter value associated with a S-ACTIVITY-START or S-ACTIVITY-RESUME, this should be followed by combinations of a character code (CC) to be registered to the DRCS set and its character dot pattern (DP); ii) 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 parameters. Note - The value of this parameter in either S-ACTIVITY-START or S-ACTIVITY-RESUME will be as follows: DRCS CC1 DP1 CC2 DP2 | | | CCi DPi - Control character sets (see S 4.2.3.5) - Teletex page format (see S 4.2.3.7) - Miscellaneous Teletex terminal capabilities (see S 4.2.3.8) - Character box height A variable length field indicating the receiving capabili- ties for the number of dots of the character box height. The number of dots shall be indicated by the numeric parameter as defined in Recommendation T.61. Further study is required for indicating more than one value. - Character box width A variable length field indicating the receiving capabili- ties for the number of dots of the character box height. The number of dots shall be indicated by the numeric parameter as defined in Recommendation T.61. Further study is required for indicating more than one value. 4.4.2 S-ACTIVITY-RESUME 4.4.2.1 The parameters of S-ACTIVITY-RESUME are used as follows - Old session connection identifier (mandatory only if linking is attempted on a new session connection): this non-mandatory parameter shall contain the old session connection identifier, identifying the session in which the first part of the document was sent. a) calling SS-user-reference (mandatory) see S 4.2.1; b) called SS-user-reference (mandatory) see S 4.2.1; c) common reference (mandatory) see S 4.2.1; d) additional reference information (non-mandatory) see S 4.2.1. - Old activity identifier | this mandatory param- eter shall contain the activity identifier (document reference number) of the corresponding S-ACTIVITY-START. - Synchronization point serial number | this man- datory parameter shall contain the synchronization point serial number (checkpoint reference number) from which the transmission is being continued. - Activity identifier | the new activity identif- ier shall contain the document reference number as defined in S 3.5.7. - SS-user-data | this non-mandatory 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. 4.4.2.2 Additional parameters The following parameters may also be included: a) Document type identifier [see S 4.4.1.2 | )]. b) Service interworking identifier [see S 4.4.1.2 | )]. c) Optionally, any other parameter field that appears in the S-ACTIVITY-START at the start of the document may be repeated in the S-ACTIVITY-RESUME. Indication of required terminal capability is mandatory if standardized optional terminal capabili- ties are required for the document. A terminal receiving a S-ACTIVITY-RESUME that does not contain all of the terminal capa- bilities should not reject the continuation of the document. 4.4.2.3 Encoding of the S-ACTIVITY-RESUME additional param- eters a) Document type identifier [see S 4.4.1.3 | )]. b) Service interworking identifier [see S 4.4.1.3 | )]. c) Indication of required terminal capability (see S 4.4.1.3 | )]. 4.4.3 S-ACTIVITY-INTERRUPT The parameters of S-ACTIVITY-INTERRUPT are used as follows: Reason | if used, this non-mandatory parameter shall con- tain only one of the following reasons: a) unable to continue the 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). 4.4.4 S-ACTIVITY-DISCARD The parameters of S-ACTIVITY-DISCARD are used as follows: Reason | if used, this non-mandatory parameter shall con- tain only one of the following reasons: a) unable to continue the 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). 4.4.5 S-ACTIVITY-END The parameters of S-ACTIVITY-END used as follows: - Synchronization point serial number : this man- datory parameter represents the synchronization point serial number (final checkpoint reference number) to which a response shall be made. - SS-user-data | this parameter is not used, in Teletex and Group 4 facsimile services. 4.4.6 S-SYNC-MINOR The parameters of S-SYNC-MINOR are used as follows: - Type: this mandatory parameter (only in request and indication) will indicate "explicit". - Synchronization point serial number: this manda- tory parameter is the checkpoint reference number, which, in the basic services, is the page reference number. - SS-user-data: this parameter is not used in the request/indication. In the response/confirmation it represents the parameter "receiving ability jeopardized". This mandatory parameter (in response and confirmation) indicates whether or not the ability of the receiving terminal to continue to accept the traffic is jeopardized. The SS-user shall ensure that the first octet is 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 standardi- zation. 4.4.7 S-U-EXCEPTION-REPORT The parameters of S-U-EXCEPTION-REPORT are used as follows: - Reason: the value of this mandatory parameter should be one of the following: a) unable to continue the session (e.g. due to memory full, out of recording paper). This value corresponds to the value "SS-user receiving ability jeopardized"; b) sequence error; c) local terminal error; d) unrecoverable procedural error; e) no specific reason stated (used for reasons other than those listed. - SS-user-data: this parameter is not used in Teletex and Group 4 facsimile services. 4.4.8 S-P-EXCEPTION-REPORT 4.4.8.1 The parameters of S-P-EXCEPTION-REPORT are used as follows Reason: this mandatory parameter will indicate "protocol error". 4.4.8.2 Additional parameters Reflect parameter value: this mandatory parameter shall con- tain the bit pattern of the SPDU in error, up to and including the detected error. 4.4.9 S-CONTROL-GIVE Use of these primitives are defined in Recommendations X.215 and X.225. 4.4.10 S-TOKEN-PLEASE The parameters of S-TOKEN-PLEASE are used as follows: - Token: this mandatory parameter shall contain the session control function parameter and will indicate "data token". - SS-user-data: this parameter is not used in Teletex and Group 4 facsimile services. 4.4.11 S-CAPABILITY-DATA 4.4.11.1 The parameters of S-CAPABILITY-DATA are used as follows SS-user-data: This non-mandatory parameter is used to convey data of the presentation and/or application protocol(s). All infor- mation necessary to negotiate the document interchange protocol parameters, defined in the T.400-Series of Recommendations, is con- tained in this parameter field. 4.4.11.2 Additional parameters The following parameters may also be included: a) Inactivity timer: this non-mandatory parameter is used to negotiate the value of the inactivity timer. b) Storage capacity negotiation: this non-mandatory parameter is used to negotiate the available memory of the remote terminal. c) Private use parameters: these parameters are not mandatory. Their definition and use are not standardized. d) Non-standardized capabilities: this non-mandatory parameter is used to ascertain compatibility regard- ing the use of non-standardized terminal capabilities. And either e) Acceptance of S-CAPABILITY-DATA parameter: this non-mandatory parameter is used to confirm that all the requested non-basic Teletex terminal capabilities are available at the receiver (only in response and confirmation). f ) Non-basic Teletex terminal capabilities [see S 4.4.1.3 | )]: this non-mandatory parameter indicates 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 indicates that the requested capabilities are not available at the receiver; - a complete list of non-basic receiving capabili- ties irrespective of the requested ones. 4.4.11.3 Encoding of S-CAPABILITY-DATA additional parame- ters a) Inactivity timer (see S 4.2.3.4); b) Non-basic Teletex terminal capabilities [see S 4.4.1.3 | )]; c) Acceptance of S-CAPABILITY-DATA parameter . Bit 1 of the first octet set to 1 indicates acceptance of all non-basic terminal capabilities requested by a S-CAPABILITY-DATA request (except those indicated in the SS-user-data). All other bit values are reserved for future stan- dardization. d) Storage capacity negotiation A fixed sequence of two octets to indicate the required amount of storage: 1) Bit 1 of the first octet set to 1 indicates that a terminal has recerved the requested amount of storage. 2) 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-octets. 3) 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. 4) 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. 5) Bit 3 of the first octet set to 1 indicates that a terminal cannot estimate its memory capacity. 6) Bit 4 of the first octet set to 1 indicates that a terminal cannot now reserve the requested amount of memory. 7) In the first octet, only one of bit 2, 5 and 6 may be set to one. For negotiation of storage capacity less than or equal to 255 kilo-octets, bit 2 shall be used. Note - Use of bit 5 for negotiation of a storage capacity greater than 65 kilo-octets but less or equal to 255 kilo-octets is not to be interpreted as a procedural error by the receiver. 8) 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 1), 5) and 6), the second octet may be ignored by the recipient of the S-CAPABILITY-DATA confirmation. e) 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. 4.4.12 D-DATA Uses of these primitives are defined in Recommendations X.215 and X.225. 5 Recommendations for implementing the session layer To support the control procedures the following specifications apply in addition to Recommendation X.225. 5.1 Additional parameters To conform with the control procedures for Teletex and Group 4 facsimile, the implementation must be able to generate and decode the additional parameters in the SPDUs. Note - The session layer is only concerned with the coding of these parameters and their incorporation in the SPDUs, it is not concerned with the parameter values. This means that the specifica- tion of maximum length and parameter value encoding is part of the application layer specification. 5.1.1 Connect SPDU H.T. [T21.62] TABLE 5/T.62 bis ________________________________________________________________________________________________________________________________________________________ PIG n/nm Code (dec.) Code (hex.) PI o/nm Code (dec.) Code (hex.) ________________________________________________________________________________________________________________________________________________________ { Non-basic session capabilities } nm 2 2 { Miscellaneous session capabilities } nm 13 D | | | | | | | | | | | | | | | | | | | | | | | | ________________________________________________________________________________________________________________________________________________________ Window size nm 14 E ________________________________________________________________________________________________________________________________________________________ Service identifier m 8 8 ________________________________________________________________________________________________________________________________________________________ Inactivity timer nm 18 12 ________________________________________________________________________________________________________________________________________________________ Control character sets nm 73 49 Teletex page formats nm 74 4A { ________________________________________________________________________________________________________________________________________________________ Private use nm 224 to 231 E0 to E7 Private use nm 232 to 255 E8 to FF ________________________________________________________________________________________________________________________________________________________ Non standardized capabilities nm 232 E8 ________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 5/T.62 | is [T21.62], p. 5.1.2 Accept SPDU H.T. [T22.62] TABLE 6/T.62 bis ______________________________________________________________________________________________________________________________________ PGI n/nm Code (dec.) Code (hex.) PI m/nm Code (dec.) Code (hex.) ______________________________________________________________________________________________________________________________________ { { Window size | | | | | | | | | nm | | | | | | | | | 14 | | | | | | | | | E ______________________________________________________________________________________________________________________________________ Service identifier m 8 8 ______________________________________________________________________________________________________________________________________ Inactivity timer nm 18 12 ______________________________________________________________________________________________________________________________________ Control character sets nm 73 49 Teletex page formats nm 74 4A { ______________________________________________________________________________________________________________________________________ Private use nm 224 to 231 E0 to E7 Private use nm 232 to 255 E8 to FF ______________________________________________________________________________________________________________________________________ Non standardized capabilities nm 232 E8 ______________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 6/T.62 | is [T22.62], p. 5.1.3 Refuse SPDU H.T. [T23.62] TABLE 7/T.62 bis ______________________________________________________________________________________________________________________________ PIG m/nm Code (dec.) Code (hex.) PI m/nm Code (dec.) Code (hex.) ______________________________________________________________________________________________________________________________ { { Window size | | | | | | | | | nm | | | | | | | | | 14 | | | | | | | | | E ______________________________________________________________________________________________________________________________ Service identifier m 8 8 ______________________________________________________________________________________________________________________________ Control character sets nm 73 49 Teletex page formats nm 74 4A { ______________________________________________________________________________________________________________________________ Private use nm 224 to 231 E0 to E7 Private use nm 232 to 255 E8 to FF ______________________________________________________________________________________________________________________________ User data nm 193 C1 ______________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 7/T.62 | is [T23.62], p. 5.1.4 ACTIVITY-START SPDU/ACTIVITY-RESUME SPDU H.T. [T24.62] TABLE 8/T.62 bis _______________________________________________________________________________________________________________________________________________________ PGI m/nm Code (dec.) Code (hex.) PI | m/nm| Code (dec.)| Code (hex.) _______________________________________________________________________________________________________________________________________________________ { Service interworking identifier } nm 40 28 _______________________________________________________________________________________________________________________________________________________ Document type identifier nm 48 30 _______________________________________________________________________________________________________________________________________________________ Graphic character set nm 72 48 Control character set nm 73 49 { Character box height nm 77 4D _______________________________________________________________________________________________________________________________________________________ Private use nm 224 to 231 E0 to E7 Private use nm 232 to 255 E8 to FF _______________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 8/T.62 | is [T24.62], p. 5.1.5 CAPABILITY-DATA SPDU H.T. [T25.62] TABLE 9/T.62 bis _______________________________________________________________________________________________________________________________________________ PGI m/nm Code (dec.) Code (hex.) PI | m/nm| Code (dec.)| Code (hex.) _______________________________________________________________________________________________________________________________________________ Inactivity timer nm 18 12 _______________________________________________________________________________________________________________________________________________ Storage capacity negotiation nm 45 2D _______________________________________________________________________________________________________________________________________________ Graphic character set nm 72 48 Control character set nm 73 49 { Character box height nm 77 4D _______________________________________________________________________________________________________________________________________________ Private use nm 224 to 231 E0 to E7 Private use nm 232 to 255 E8 to FF _______________________________________________________________________________________________________________________________________________ Non standardized capabilities nm 232 E8 _______________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 9/T.62 | is [T25.62], p. 5.1.6 CAPABILITY-DATA-ACK SPDU H.T. [T26.62] TABLE 10/T.62 bis ______________________________________________________________________________________________________________________________________________________ PGI n/nm Code (dec.) Code (hex.) PI | m/nm| Code (dec.)| Code (hex.) ______________________________________________________________________________________________________________________________________________________ Inactivity timer nm 18 12 ______________________________________________________________________________________________________________________________________________________ { Acceptance of CAPABILITY-DATA parameters } nm 44 2C ______________________________________________________________________________________________________________________________________________________ { Storage capability negotiation } nm 45 2D ______________________________________________________________________________________________________________________________________________________ Graphic character set no 72 48 Control character set nm 73 49 { Character box height nm 77 4D ______________________________________________________________________________________________________________________________________________________ Private use nm 224 to 231 E0 to E7 Private use nm 232 to 255 E8 to FF ______________________________________________________________________________________________________________________________________________________ Non standardized capabilities nm 232 E8 ______________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 10/T.62 | is [T26.62], p. 5.2 Implementation choices The choices for implementing the OSI session layer are indi- cated below in order to allow interworking with Teletex and Group 4 facsimile equipment. 5.2.1 The S-TOKEN-PLEASE service must be implemented so that, in Teletex and Group 4 facsimile services mode of operations: - the PT SPDU is in principle concatenated with a category 2 SPDU. The way this service is implemented for modes of operations different from Teletex and Group 4 facsimile services is a local matter; - when the session is intentionally left inactive for a period of time, the PT SPDU can be sent without being con- catenated. For the Teletex and Group 4 facsimile service this requires a preceding negotiation of the inactivity timer to a dif- ferent value from the default value. Note - The SPDU GIVE TOKENs (GT) may never be transmitted alone nor may include a "token item" parameter because the use of the S-GIVE-TOKEN service is not permitted in basic Teletex and Group 4 facsimile. 5.2.2 When sending one of the following SPDUs the whole param- eter must be absent (i.e. PI, LI, PV fields) when the PV field has to be absent (i.e. when LI = 0): token item parameter in PT and GT SPDUs, user data in FN, DN, AB, ED, AE, AEA, AS and AR SPDUs, enclosure item in DT SPDU and sync type item in MIP SPDU. 5.2.3 The sum of the numbers of digits contained in the check- point reference number (synchronization point serial number) and the document reference number (activity identifier) 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. 5.2.4 The reception of a length indicator with a value lower than 255 in a 3 octets field must not lead to a protocol error. 5.2.5 When receiving an AB SPDU the AA SPDU must be sent back even if the transport connection is not to be kept (X.225 allows the user to choose between disconnecting the transport or sending the SPDU AA when AB is received). The telematic services do not use the "reflect parameter values" parameter in the AB SPDU. 5.2.6 When receiving the CN, AC, CD or CDA SPDUs the non-standardized parameter codes or the parameters which are not part of these SPDU encoding, must be ignored. 5.2.7 The TIM timer value must be 4 seconds. 5.2.8 The PGI "connect/accept" (code 5) and the PI "session requirements" (code 20) must not be transmitted in the CN or AC SPDU, if their values are the same as their default values. The parameters version number (code 22) and transport disconnect (code 17) must not be transmitted in the RF SPDU. The RF SPDU may also contain an additional user data parameter. 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 When a PV conains 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. 5.2.11 Segmentation is not used. 5.2.12 Definition of valid/invalid session protocol data units In addition to the rules expressed in X.225, the following applies. 5.2.12.1 Invalid PDUs (definitions and rules) If the PDUs do not meet the following conditions, such PDUs are invalid: a) the sum of LIs of PGIs and freestanding PIs is equal to the overall LI; b) the sum of the LIs of PIs embedded within recognized PGIs is equal to the PGIs LI; c) for all mandatory parameters, the PGIs or PIs are present and the LIs are not equal to zero. Note 1 - In the case of AB, AA and RF PDUs, the same checking rules may be applied. However, it is recognized that no externally visible procedure is provided to react to the detection of such invalid PDUs. Note 2 - Invalid ED or ER can either be rejected or processed normally to start error recovery. Note 3 - When receiving an invalid CN it is recommended that the connection be refused by sending a RF with the appropriate parameters and not to release the transport connection. Note 4 - An equipment is not required to make any checking at all on parameters it does not support. In such cases it may also omit the checking of the overall LI. In particular, it should be noted that no recognized parameters, e.g. new parameters, may appear either between supported parameters or after the complete set of supported parameters. 5.2.12.2 Valid PDUs (rules for mandatory acceptance of PDUs) An SPDU shall not be rejected if it does not meet the rejec- tion conditions described in S C.2. They must not be rejected for any of the following conditions: a) the presence of a non-mandatory PI or PGI having an LI = 0; b) the presence of any 3-octet LI, the coding of which follows the rules described in this Recommendation and in Recommendation X.225; c) the presence of any correctly formed PV for which future values can be assigned; d) the presence of one or more undefined PIs or PGIs in CN or CD and their corresponding responses; e) the presence of a T.61 coded hyphen ("-") instead of a colon (":") as the parameter between the hours and minutes of the date and time PV in CN; f ) the length of the synchronization point serial number in MIA greater or less than the length of the synchroniza- tion point serial number in the corresponding MIP (with more or less preceding zeros); g) more PV in AC or RF than in CN. Note - The scope of these rules is restricted to the determi- nation of protocol element validity (formal validity) and they do not impact on rejection or protocol elements due to the functions they invoke. ANNEX A (to Recommendation T.62 | fIbis ) Definitions Note - 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. A.1 General A.1.1 Teletex terminal A device that is capable of transmitting and receiving Teletex documents in accordance with the basic requirements of Recommendation T.60. A.1.2 calling terminal The terminal that initiates the procedures to establish a con- nection. A.1.3 called terminal A terminal with whom a calling terminal wants to estabish a connection. A.1.4 Group 4 facsimile apparatus A device that is capable of transmitting and receiving fac- simile documents in accordance with the basic requirements of Recommendation T.563. A.1.5 service interworking The facility of sending and receiving information between a Teletex terminal and a terminal of another service, e.g. telex. A.2 Session layer mode of communication For the session layer, three different modes of communication are identified: A.2.1 one-way communication (OWC) User information is transferred in one direction only during the session, i.e. only one of the terminals will have the right to be the source. A.2.2 two-way alternate (TWA) User information is transferre in both directions, but only in one direction at a time, i.e. the source/sink relation will be changed one or more times during the session. This is also called the half-duplex mode. A.2.3 two-way simultaneous (TWS) User information is transferred in both directions simultane- ously, i.e. both terminals are simultaneously a source as well as a sink. This is also called the duplex mode. A.3 Terms specific to document A.3.1 document A document is a sequence of one or more pages intended by the originator to be delivered to the address(es) as a single entity in the original page sequence. A.3.2 page The basic element of office correspondence in the telematic service. One A4 (or A4L, North American standard or North American legal) page or the information that may be presented on it. A.3.3 checkpoint A checkpoint is a numbered mark inserted by the sender in the text stream to provide a reference point for error recovery. A.3.4 acknowledgement window The maximum number of checkpoints that a sender can transmit without receiving an acknowledgement from the receiver. ANNEX B (to Recommendation T.62 | fIbis ) B.1 Each state diagram is in only one state at any time. B.2 Each state is represented as an ellipse, which contains a number for reference and a descriptive name. B.3 Permissible transitions from one state to another are shown as connecting lines with an arrow indicating the permitted direction of the state transition and labelled with the event or events that cause that transition. B.4 Where a transition may originate from any of several states, it may be indicated by a broad arrow terminating on the destination state and labelled with the permissible states of ori- ginating and with the event or events that cause that entry into the destination state. B.5 An event is either the sending (S-) or reception (R-) of a request or a response or an indicated local operation. B.6 Each state diagram has a state named "idle" and numbered zero. This is the initial or reset state when that state diagram is inactive. B.7 Upon sending any request that causes entry into a state named "demand response", the sending of any additional requests is not permitted until a response is received. A demand response timer is started, and if a response is not received prior to expiration of that time-out, session terminating is mandatory. B.8 The effect of each event that causes a state transition must be completed prior to consideration of a subsequent event. B.9 During a session, each session partner has a responsibil- ity for monitoring for proper operation as follows: a) maintenance of the currently agreed source/sink relationship, b) proper use of request/response procedural sequences as described in the state diagrams and the rules of their operation, c) monitoring of a period of inactivity (e.g. indi- cating a failure or other inability to continue productive use of the session). Upon detection of a failure to maintain proper operation as described above, use of the error recovery procedures defined for each state diagram is mandatory, or where such error recorvery pro- cedures are not specifically defined, session termination (abnormal end) is mandatory. This is necessary in order to avoid unproductive use of telematic facilities, incurring unnecessary charges where the service is not being used effectively, and causing degradation of the service. B.10 The purpose of the state diagrams is to assist in defin- ing proper use of the elements of procedure, and not to define any particular implementation. Blanc Figure B-1/T.62 | is, p. Figure B-2/T.62 | is, p. ANNEX C (to Recommendation T.62 | fIbis ) C.1 General C.1.1 An indication of the type of document that is transferred shall be given at the start of the document; if not, the normal type of document is used. C.1.2 A document type indication will indicate to the operat- ing system of the receiving terminal that a special action is required (the action is defined for each type of document). C.1.3 No additional procedure elements or changes in state transition diagrams are required. C.2 Normal document C.2.1 This is the normal type of document to be used to transfer text in the telematic services. Upon reception the docu- ment may be immediately printed (in the case of Group 4 facsimile Class 1) or be immediately stored (all other terminals). C.2.2 From the procedures point of view, every Teletex termi- nal must be able to handle this type of document. Note - Where appropriate the rules for the usage of optional functions have to be followed. C.3 Operator document (optional) The operator document represents a type of priority message. It can be used in the conventional mode of operation. It is intended to be presented immediately to the operator (although the decision to present it is left to the receving opera- tor). It may therefore be immediately indicated to the operator that a new operator document has been received. The operator docu- ment shall conform to the same presentation control functions and be treated in the procedure as a normal document. The length of an operator document is arbitrary but, preferably (due to the applica- tion), it shall not exceed one page. Note that a terminal that does not have a special dialogue mode can handle an operator document as a normal document. C.4 Control document C.4.1 The control document can be used in communication with intermediate store-and-forward equipment; e.g. interworking with the telex service, in standardized options and national applica- tions. C.4.2 The addressing information (and other control informa- tion required) can be included as text within such a document. The control document shall, except for the document type indication, follow the same rules (in the procedures) as a normal document. The use of the control document is outside the scope of this Recommen- dation. C.4.3 Teletex terminals shall be able to support the control documents defined in Recommendation T.90 for interworking with the telex service. C.5 Monitor document (optional) C.5.1 The monitor document will not be made available to the user. It is intended to be available for purposes that can be defined by each Administration, e.g. for maintenance purposes. C.5.2 The monitor document will be handled by the operating system of the terminal and not displayed to the operator. The moni- tor document shall, except for the document type indication, con- form to the same rules (in the procedure) as a normal document. ANNEX D (to Recommendation T.62 | fIbis ) Protocols for interactive applications These protocols are under study. Recommendation T.63 PROVISIONS FOR VERIFICATION OF TELETEX TERMINAL COMPLIANCE (Malaga-Torremolinos, 1984; modified at Melbourne, 1988) The CCITT, considering , (a) that Administrations planning to offer the Teletex service will require provisions to facilitate the verification of compli- ance of Teletex terminals; (b) that Recommendation F.200 fixes the rules to be followed in the automatic international Teletex service; (c) that Recommendation T.60 defines the requirements for ter- minal equipment used in the international Teletex service; (d) that Recommendation T.61 defines the character repertoire and coded character sets for the international Teletex service; (e) that Recommendation T.62 defines the control procedures for the Teletex service; (f ) that a standardized " test text " could provide a means to facilitate the verification of the presentation capabilities of Teletex terminals, unanimously declares the following: 1 Introduction 1.1 Objective This Recommendation contains a reference test text and associ- ated encoding of characters to facilitate Administrations' verification of the text presentation capabilities of Teletex ter- minals. 1.2 Scope 1.2.1 The reference test text contained herein is based on Recommendations F.200, T.60, T.61 and T.62, and contains only the basic Teletex repertoire of graphic characters and control func- tions. 1.2.2 The reference test text is intended to assist verifica- tion and does not necessarily guarantee the compliance of Teletex terminals subjected to it. 1.2.3 The reference test text does not supersede Recommendations F.200, T.60, T.61 or T.62 which continue to be the definitive specifications for the Teletex character repertoire, its associated coding representation and control procedures. 1.2.4 Additional provisions to facilitate the verification of Teletex terminals are required and are for further study. 2 General 2.1 General description of test text The test text consists of a document of two pages, the first presented in the horizontal format (see Annex A) and the second in the vertical format (see Annex B). 2.2 Description of page 1 (Annex A) The first page begins with the control functions PFS, IGS, SHS, FF and CR. Note - The IGS function has been included for completeness of control functions. However, its parameter values have not been defined and require further study. Terminals may ignore the IGS function but must be capable of receiving it. The control functions are followed by a framing line to test the required capability of printing 100 characters beginning at the home position. The sequence 1234567890 should appear exactly 10 times. One group of ten digits is superscripted to demonstrate the availability of the upper extreme of the printing area. This is followed by the "diacritical mark" test, in which every required combination of letters and diacritical marks is pro- duced. This section is single-spaced [SVS(0)] and occupies lines 3 to 28 inclusive. Midway through line 28, an SVS(1) sequence (9/11 3/1 2/0 4/12) is sent; this results in 1.5 line spacing beginning with the next LF function (line 29). Immediately following the CR LF sequence terminating line 30, five BS characters (0/8) are sent followed by two Xs (5/8). This tests for the existence of five character positions to the left of the home position, and the ability to print in them, as well as correct functioning of the BS format effector. A CR (0/13) is then sent to return to the home position - a rightward movement of the active position - and the line number. The centre of line 31 exercises the ability to combine diacritical marks with letters and nonspacing underline. At line 32, an SVS(2) activates a line spacing of 2. Finally, line 34 completes the framing, illustrating that we can print in all extreme character positions (line 34 is actually the 38th single-spaced line on the page and therefore the last required). One group of digits is subscripted and underlined to further demonstrate the availability of the extremes of the print- ing area. 2.3 Description of page two (Annex B) The start of page 2 is indicated by a protocol element (as defined in Recommendation T.62) which resets all control functions to a default state in accordance with Recommendation T.61, S 3.3. For this page no presentation control functions are sent prior to the carriage return (CR) form feed (FF) sequence that introduces the text of the page. Therefore, the terminal should revert to the default control function values [PFS(0) and SVS(0)], resulting in a vertical page format and single line spacing. This is followed by a framing line to demonstrate the capabil- ity of printing 72 positions starting at the home position. One group of ten digits is superscripted to demonstrate the availabil- ity of the upper extreme of the printing area. A complete character set test follows, in row and column form. All characters in both the primary and supplementary sets are displayed on lines 12 to 30 inclusive. Lines 1 to 18 are printed with single line spacing. Line 19 contains an SVS(1) sequence, resulting in 1.5 line spacing begin- ning with line 20. Line 21 contains the control function SHS without parameter value (default value for horizontal spacing). This function will have no effect on the presentation of the page, but the receiving terminal should accept the coding. Line 33 contains the control function "SUB" which may have a graphical representation ( in this document). The graphical representation of this control function (SUB) in Annex B and Annex D is only one of several presentation possibilities as defined in Recommendation T.61, S 3.3.5. Terminals receiving a substitute character may either represent it with a spacing charac- ter or ignore it. Line 32 contains an SVS(2), resulting in double spacing from line 32. Line 34 contains twice SGR(4), resulting in the underlining of the first three words after which underlining is stopped; it starts again under the fourth word. Note that underlining between the third and fourth word must be absent. Comment: The sequence of first a SGR(0) without the default parameters code and second a SGR(0) with the parameter is chosen so to avoid the rest of the text of the page from being underlined totally in the case that the omission of the default parameter is not recog- nized. Immediately after the new line sequence at the end of line 34, five BS (0/8) are sent, followed by two Xs, a CR (0/13) and the line number (35), which should appear in the home position. This again demonstrates the backspace function, the existence of five print positions to the left of the home position in the vertical format, and CR causing a rightward movement of the active position to the home position. Line 35 exhibits the combination of the nonspacing underline character (12/12) with various graphic characters. Line 36 exercises PLU (8/12) and PLD (8/11), alone and in com- bination with the nonspacing underline. In the middle group, the nonspacing underline precedes the "start super/subscript" command, and in the last group it follows the super/subscript command. Line 37 combines PLU and PLD with the SGR(4) presentation function. In the first group, SGR(4) precedes the first character and remains effective for all characters, while in the second group it is sent prior to the first character and also after each "start super/subscript" command. Also on this line, an X followed by an LF (0/10) is sent without the CR. This results in the next line number 38 being printed beneath and one position to the right of the X. Note that in lines 36 and 37 underlining may be suppressed in those character positions where it causes overprinting (Recommendation T.61, S 3.1.7). Line 39 contains a SVS(0) sequence in which the default param- eter (for one spacing) is omitted, resulting in one line spacing, beginning with line 40. Finally, line 41 completes the framing, demonstrating the capability of printing in all extreme positions (line 41 corresponds to 55 single spaced lines). A group of ten digits is subscripted and underlined to illustrate complete capability in the extremes. 3 Reference test text Annexes A and B graphically represent the test text, whereas Annexes C and D represent the applicable coding to realize the test. Blanc ANNEX A (to Recommendation T.63) Table, p. ANNEX B (to Recommendation T.63) H.T. [T27.62] _________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 1 | | | | | | | | | 1 | | | | | | | | | 1 | | | | | | | | | 1 | | | | | | | | | 1 | | | | | | | | | 1 | | | | | | | | | { 1 | | | | | | | | | | 12 } 2 | | | | | | | | | | | | | | | | | | | | 3 Presentation Test Text Page 2 4 | | | | | | | 5 { No parameters were specified for this new page. Therefore, by default, line spacing } 6 { should be `1` [SVS(0)], and page format should be vertical [PFS(0)]. } 7 8 9 Character Set Test 10 _________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | ____________________________________________________________________________________________________________________________________________________________ 11 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 12 0 0 P p _ K 13 1 ! 1 A Q a q ! _ a 14 2 " 2 B R b r c 2 a D d 15 3 ## 3 C S c s - 3 | a ` 16 4 O 4 D T d t $ x ~ H h 17 5 % 5 E U e u u - i 18 6 | | | | | | | | | | | | | | | | & | | | | | | | | 6 | | | | | | | | F | | | | | | | | V | | | | | | | | f| | | | | | | | v | | | | | | | | | | | | | | | | | | | | | | | | ##| | | | | | | | | | | | | | | | e | | | | | | | | | | | | | | | | IJ | | | | | | | | ij 19 { 1 | | | | | | | | | | fR 19 } | | | | | | | | | | | | 20 { Here the line spacing is set to `1-1/2` [SVS(1)]. } 21 ____________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ____________________________________________________________________________________________________________________________________________________ 22 7 ' 7 G W g w S . . L l 23 8 ( 8 H X h x O - e L l 24 9 ) 9 I Y i y / / 25 10 * : J Z j z OE oe 26 11 + ; K [ k << >> c o | 27 12 , < L l | 1/4 - P b 28 13 - ____ M ] m 1/2 " T b 29 14 . > N n 3/4 . 30 15 | | | | | | | | | | | | | | | | | | / | | | | | | | | | ? | | | | | | | | | O | | | | | | | | | - | | | | | | | | | o| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ? | | | | | | | | | e | | | | | | | | | | | | | | | | | | 'n | | | | | | | | | 31 { 1 | | | | | | | | | | fR 31 } | | | | | | | | | | | | | 32 { Here the line spacing is set to `2` [SVS(2)]. } 33 ____________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _______________________________________________________________________________________________________________ 34 Format Effector Tests [SGR(4)] XX 35 non spacing underline 36 E i = M ic2 E i = M ic2 { E c } 37 E i = M ic2 { E c } X 38 | | | | | | | | | | | | | | | | | | | | | | | | | 39 { Here the line spacing is set to `1` [SVS]. } 40 _______________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ___________________________________________________________________________________________________________________________________________________________________________________________________ 41 3 | | | | | | | 1 | | | | | | | | | 1 | | | | | | | | | 1 | | | | | | | | | 1 | | | | | | | | | 1 | | | | | | | | | { 1 | | | | | | | | | | 12 } ___________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T27.62], p. ANNEX C (to Recommendation T.63) Teletex presentation test text coding Table p. Tableau p. Tableau p. Tableau p. Tableau p. Tableau p. Tableau p. Tableau p. ANNEX D (to Recommendation T.63) Table p. Tableau p. Tableau p. Tableau p. Tableau p. Tableau p. Tableau p.