.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .sp 1P .ce 1000 \v'12P' \s12FASCICLE\ VII.5 \v'4P' .RT .ce 0 .sp 1P .ce 1000 \fBRecommendations T.65\(hyT.101, T.150\(hyT.390\fR \v'2P' .ce 0 .sp 1P .ce 1000 \fBTERMINAL\ EQUIPMENT\ AND\ PROTOCOLS\fR .EF '% \ \ \ ^'' .OF ''' \ \ \ ^ %' .ce 0 .sp 1P .ce 1000 \fBFOR\ TELEMATIC\ SERVICES\fR .ce 0 .sp 1P .LP .rs .sp 29P .ad r BLANC .EF '% \ \ \ ^'' .OF ''' \ \ \ ^ %' .ad b .RT .LP .bp .LP \fBMONTAGE:\fR p. 2 = PAGE BLANCHE .sp 1P .RT .LP .bp .sp 2P .LP \fBRecommendation\ T.65\fR .RT .sp 2P .ce 1000 \fBAPPLICABILITY\ OF\ TELEMATIC\ PROTOCOLS\ AND\ TERMINAL\ CHARACTERISTICS\fR .EF '% Fascicle\ VII.5\ \(em\ Rec.\ T.65'' .OF '''Fascicle\ VII.5\ \(em\ Rec.\ T.65 %' .ce 0 .sp 1P .ce 1000 \fBTO\ \fR \fBCOMPUTERIZED\ COMMUNICATION\ TERMINALS\ (CCTs)\fR .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP The\ CCITT, .sp 1P .RT .sp 1P .LP \fIconsidering\fR .sp 9p .RT .PP (a) that there is an increasingly growing base of computerized communication terminals, such as communicating personal computers; .PP (b) that Administrations will require provisions to enable these devices to access CCITT\(hydefined services, such as telematic services; .PP (c) that communication of these devices with each other may use provisions specified for communication within telematic services; .PP (d) that such devices may, due to their adaptive nature, require, in some areas, different protocols and terminal characteristics than existing telematic terminals; .PP (e) that the various telematic services are defined in the F\(hySeries of Recommendations; .PP ( f ) that the reference model for open systems interconnection is defined in the X\(hy200\(hySeries of Recommendations; .PP (g) that the various telematic protocols and terminal characteristics are defined in the T\(hySeries of Recommendations; .PP (h) that there is a requirement to assess the applicability of the protocols and terminal characteristics defined in the CCITT telematic recommendations to computerized communication terminals; .sp 1P .LP \fIunanimously declares the view\fR .sp 9p .RT .PP that the following technical provisions determine the applicability of protocols and terminal characteristics specified in CCITT Telematic Recommendations to Computerized Communication Terminals. \v'1P' .sp 1P .ce 1000 CONTENTS .ce 0 .sp 1P .sp 2P .LP 1 \fIScope\fR .sp 1P .RT .sp 1P .LP 2 \fICharacteristics and model\fR .sp 9p .RT .LP 2.1 Definition .LP 2.2 Characteristics .LP 2.3 General model .LP 2.4 Minimum capability .sp 1P .LP 3 \fIAccess to the Teletex service\fR .sp 9p .RT .LP 3.1 General .LP 3.2 Characteristics .LP 3.3 Applicability of the relevant CCITT Recommendations .LP 3.4 Access methods .bp .sp 1P .LP 4 \fIAccess to the Group 3 facsimile service\fR .sp 9p .RT .LP 4.1 General .LP 4.2 Characteristics .LP 4.3 Applicability of the relevant CCITT Recommendations .sp 1P .LP 5 \fIAccess to the Group 4 facsimile service\fR .sp 9p .RT .sp 1P .LP 6 \fIAccess to the mixed\(hymode option of the Teletex service\fR .sp 9p .RT .sp 1P .LP 7 \fIAccess to the videotex service\fR .sp 9p .RT .LP 7.1 General .LP 7.2 Characteristics .LP 7.3 Applicability of the relevant CCITT Recommendations .sp 1P .LP 8 \fIAccess to MHS\fR .sp 9p .RT .LP 8.1 General .LP 8.2 Characteristics .LP 8.3 Applicability of the relevant CCITT Recommendations .sp 1P .LP 9 \fIAccess to the directory service\fR .sp 9p .RT .LP 9.1 General .LP 9.2 Characteristics .LP 9.3 Applicability of the relevant CCITT Recommendations \v'6p' .sp 2P .LP \fB1\fR \fBScope\fR .sp 1P .RT .PP 1.1 This Recommendation addresses the applicability of the protocol and terminal characteristics specified in CCITT\(hydefined Recommendations to Computerized Communication Terminals (CCTs). It should be observed that the \*Qadaptive\*U (as opposed to dedicated) nature of CCTs calls for, in certain areas, more flexibility, but without undue degradation of capabilities. The issues of flexibility versus degradation of capabilities strongly influenced the proposals made in this Recommendation. .sp 9p .RT .PP 1.2 This Recommendation specifies how the various telematic Recommendations may be used, and any additional requirements, to enable computerized communication terminals to access the various telematic services. It is noted that while this Recommendation is applicable to CCTs only when accessing telematic services, consideration may be given to the use of the technical aspects of this Recommendation if CCTs communicate with each other utilizing the telematic protocols. .PP 1.3 Section 2 describes the characteristics of computerized communication terminals. The remaining sections define how the relevant telematic Recommendations may be used to enable CCTs to access the telematic services. .PP 1.4 Figure 1/T.65 shows various methods for CCTs to access the telematic services which are described in \(sc\(sc\ 3 to\ 9. .PP Three methods are proposed: .LP i) access to and from a telematic service via service access facility (SAF) (see \(sc\ 3.4.2, for example); .LP ii) direct access from and to a telematic service; .LP iii) direct access from a CCT to a telematic service, reverse access via SAF (see \(sc\ 3.4.3, for example). .sp 2P .LP \fB2\fR \fBCharacteristics and model\fR .sp 1P .RT .sp 1P .LP 2.1 \fIDefinition\fR .sp 9p .RT .PP The term Computerized Communication Terminal (CCT) refers to a device or equipment, which may be portable, with a processor and communication facility, typically a user work station, which permits entry of various applications and which can access CCITT\(hydefined services, such as telematics, as prescribed in this Recommendation. .bp .RT .LP .rs .sp 31P .ad r \fBFigure 1/T.65, p.1\fR .sp 1P .RT .ad b .RT .sp 1P .LP 2.2 \fICharacteristics\fR .sp 9p .RT .PP Computerized communication terminals differ in certain characteristics from telematic terminals. The following subsections identify the characteristics of CCTs. Characteristics specific to each case of the access to telematic services are given in \(sc\(sc\ 3 to\ 9. .RT .sp 1P .LP 2.2.1 \fICapability\fR .sp 9p .RT .PP A CCT maybe used to access the telematic services. The provisions in this Recommendation provide a basic level of compatibility between CCTs and the telematic services. .RT .sp 1P .LP 2.2.2 \fIProtocols\fR .sp 9p .RT .PP In general, CCTs will use OSI protocols defined in the X.200\(hySeries of Recommendations, but configured to meet the requirements defined in the relevant T\(hySeries of Recommendations. Exceptions include the cases of access to the non\(hyOSI\(hybased telematic services, where the relevant T\(hySeries of Recommendations apply. .RT .sp 1P .LP 2.2.3 \fITerminal requirements\fR .sp 9p .RT .PP In general, the relevant T\(hySeries Recommendations for terminal requirements apply. The details specified to each access to telematic services, and any additional (or relaxed) requirements are specified in \(sc\(sc\ 3 to\ 9. .bp .RT .sp 1P .LP 2.3 \fIGeneral model\fR .sp 9p .RT .PP A model for CCTs accessing telematic services based on OSI is given in Figure\ 2/T.65. The model identifies the relevant Recommendations applicable to each level in the OSI layers, for each case of access to telematic services. In particular, two sets of protocols are identified for access to OSI\(hybased telematic services: .RT .LP a) A set of OSI protocols common to most accesses to telematic services is identified for the lower layers up to and including the session kernel in the session layer. The corresponding CCITT Recommendations required are identified. .LP b) Above the common set of protocols, additional session layer functional units based on Recommendations\ X.215/X.225 are identified, together with any Recommendations required for each of the cases of the access to telematic services. .PP There are telematic services which require the use of non\(hyOSI\(hybased protocols. In these cases, the common set of protocols may not be applicable and the relevant T\(hySeries Recommendations must be used. .LP .rs .sp 39P .ad r \fBFigure 2/T.65, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 2.4 \fIMinimum capability\fR .sp 9p .RT .PP For a CCT to access an OSI\(hybased telematic service it must support all the following capabilities, and any additional capability required for each case of access to telematic service as prescribed in \(sc\(sc\ 3, 5, 6, 7, 8 and\ 9: .RT .LP a) The appropriate network capability as prescribed in \(sc 3 of Recommendation\ T.70. .LP b) X.214/X.224 Class 0 Transport procedure. .LP c) X.215/X.225 Kernel; together with half\(hyduplex, or full\(hyduplex functional units. .PP \fINote\fR \ \(em\ The applicability of the minimum capability to videotex access requires further study. .sp 2P .LP \fB3\fR \fBAccess to the Teletex service\fR .sp 1P .RT .sp 1P .LP 3.1 \fIGeneral\fR .sp 9p .RT .PP The access of CCTs to the Teletex service is a common case of communication with an OSI\(hybased telematic service due to the well defined nature of Teletex. The following sections describe the characteristics of such an access and specify how the various Teletex\(hyrelated Recommendations may be used. .RT .sp 1P .LP 3.2 \fICharacteristics\fR .sp 9p .RT .PP 3.2.1 From the technical point of view, CCTs will be able to establish communications directly with a Teletex device and exchange documents on a real\(hytime, end\(hyto\(hyend basis without the use of conversion facilities. .sp 9p .RT .PP 3.2.2 As far as possible, CCT access to the Teletex service should be done via message handling systems. The technical implementation is a national matter. .PP 3.2.3 CCTs may not necessarily be available continuously to receive incoming calls. However, when a CCT is available it will be technically able to receive calls directly from and exchange documents with other Teletex devices. .PP 3.2.4 CCTs may technically use the Teletex protocol and terminal characteristics as prescribed in \(sc\ 3.3 of this Recommendation to exchange Teletex documents with each other. .PP 3.2.5 If a Teletex device communicates with a CCT, it must be made aware of that fact. How this information is conveyed within the Teletex terminal identification with a specific value for Part\ 3 is described in \(sc\ 3.4. .sp 2P .LP 3.3 \fIApplicability of the relevant CCITT Recommendations\fR .sp 1P .RT .sp 1P .LP 3.3.1 \fIProtocols\fR .sp 9p .RT .LP a) The network capabilities are in accordance with \(sc 3 of Recommendation\ T.70. .LP b) The transport procedure is in accordance with either: .LP \(em Class 0 of the OSI transport protocol, as specified in Recommendations\ X.214/X.224, together with application rules to be compatible with and conform to the \(sc\ 5 and Annexes of Recommendation\ T.70; or .LP \(em Paragraph 5 and annexes of Recommendation T.70. .LP c) The session layer procedure is in accordance with either: .LP \(em Kernel with the functional units minor sync, half\(hyduplex, capability data, activity management, and exceptions specified in Recommendations\ X.215/X.225 together with application rules to be compatible with and conform to Recommendation\ T.62; or .LP \(em Recommendation T.62. .LP d) The applicability of higher\(hylayer Recommendations, such as T.300 and T.400, requires further study. .sp 1P .LP 3.3.2 \fITerminal requirements and character repertoire\fR .sp 9p .RT .PP The terminal requirements and character repertoire specified in Recommendations\ T.60 and\ T.61 will apply except for the following: .RT .LP a) A CCT may or may not support full automatic operation. .LP b) A CCT must be able to receive and store all characters belonging to the basic Teletex character repertoire. However, only those graphic characters which form the primary character set of the basic Teletex character set as defined in Recommendation\ T.61 need to be presented. .bp .LP c) A CCT may require a different terminal identification from that of a Teletex terminal. The format of this identification is defined in \(sc\ 3.4.3.1. .LP d) Other items require further study. .sp 2P .LP 3.4 \fIAccess methods\fR .sp 1P .RT .sp 1P .LP 3.4.1 \fIIntroduction\fR .sp 9p .RT .PP This paragraph describes a technical method for CCT access to and from the Teletex service. This access method is based on the assumption that CCTs should enjoy a maximum flexibility and that the service characteristics of Teletex should not be degraded. .PP These prerequisites imply that the CCT must be supported by a service access facility (SAF) which emulates the Teletex service characteristics and provide for the handling of messages. .RT .sp 1P .LP 3.4.2 \fIDescription of the access method\fR .sp 9p .RT .PP A CCT may establish a connection to the SAF at any time, from any network and from any access point within these networks. If a CCT wants to transmit a message but does not wish to receive a message, it need not be identified. The message will be received by the SAF and forwarded immediately to the Teletex destination. The SAF must add information which will indicate to the Teletex destination that this message was originated by an unidentified CCT. .PP If a CCT is to receive an answer to its previously transmitted message, it should be able to register itself temporarily using a password. The password will be provided by the CCT user. The message from the CCT will be forwarded immediately to the Teletex destination including information that the answer may be placed in the SAF under the given password. Provisions to allow positive or negative acknowledgements to the Teletex source and to allow control of the status of messages sent by the Teletex source are technically feasible. .PP In the following, the functions of the SAF are described which are needed to support CCTs for access to/from the Teletex service. .RT .sp 1P .LP 3.4.3 \fIModel\fR (see Figure 3/T.65) .sp 9p .RT .LP .rs .sp 11P .ad r \fBFigure 3/T.65, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 3.4.3.1 \fICCT to Teletex\fR .sp 9p .RT .PP The following functions will be provided by the SAF in order to enable a CCT to access the Teletex service: .RT .LP a) insertion of an appropriate information from which the Teletex subscribes can identify that the message is being sent from a CCT (e.g.,\ the letters \*QCCT\*U into Part\ 3 of the Teletex\(hyTID); .LP b) temporary registration on an optional basis (to allow messages to be sent back to the CCT by a Teletex terminal, see \(sc\ 3.4.3.2). .bp .sp 1P .LP 3.4.3.2 \fITeletex to CCT\fR .sp 9p .RT .PP The following functions will be provided by the SAF in order to enable a Teletex terminal to send documents to a CCT: .RT .LP a) memory for storing messages sent by the Teletex terminal; .LP b) allocation of stored messages to registration numbers to allow their retrieval by the CCT; .LP c) means for a delivery notification call to the Teletex terminal to indicate that the CCT has retrieved the message; .LP d) a time\(hyout mechanism for deleting a message if not retrieved within a certain period of time; .LP e) additional notification calls (e.g., status of stored messages) are for further study. .sp 2P .LP \fB4\fR \fBAccess to the Group 3 facsimile service\fR .sp 1P .RT .sp 1P .LP 4.1 \fIGeneral\fR .sp 9p .RT .PP A CCT may be used to access the Group 3 facsimile service. .RT .sp 1P .LP 4.2 \fICharacteristics\fR .sp 9p .RT .PP A CCT accessing the Group 3 facsimile service will operate in accordance with the CCITT Recommendations\ T.4 and\ T.30. .RT .sp 2P .LP 4.3 \fIApplicability of the relevant CCITT Recommendations\fR .sp 1P .RT .sp 1P .LP 4.3.1 \fIProtocols\fR .sp 9p .RT .PP The requirements defined in the CCITT Recommendation T.30 apply. .RT .sp 1P .LP 4.3.2 \fIModulation systems\fR .sp 9p .RT .PP The requirements defined in the CCITT Recommendation T.4 apply. .RT .sp 2P .LP \fB5\fR \fBAccess to the Group 4 facsimile service\fR .sp 1P .RT .PP (For further study.) .RT .sp 2P .LP \fB6\fR \fBAccess to the mixed\(hymode option of the Teletex service\fR .sp 1P .RT .PP (For further study.) .RT .sp 2P .LP \fB7\fR \fBAccess to the videotex service\fR .sp 1P .RT .sp 1P .LP 7.1 \fIGeneral\fR .sp 9p .RT .PP A CCT may be used to access the videotex service. Since a videotex service will not distinguish between what type of terminal is connected to it, there are no special requirements for CCTs above those which apply to dedicated videotex terminals. .RT .sp 1P .LP 7.2 \fICharacteristics\fR .sp 9p .RT .PP 7.2.1 CCTs accessing the videotex service should emulate videotex terminal characteristics. In the emulation, attention should be given to the profiles, ranks or service reference modes of the videotex terminals concerned as used in the various videotex services. Where insufficient display capabilities are available, a CCT should provide fall\(hyback by graceful degradation of capabilities so that the integrity of the information content is preserved. For example, a wide range of colours may fall back to fewer related colours, or to grey scales, or an accented character may fall back to a character without accent. .sp 9p .RT .PP 7.2.2 Videotex services are interactive and CCTs should be able to transmit and receive data interactively. .bp .sp 2P .LP 7.3 \fIApplicability of the relevant CCITT Recommendations\fR .sp 1P .RT .sp 1P .LP 7.3.1 \fIProtocols\fR .sp 9p .RT .PP To be defined. .RT .sp 1P .LP 7.3.2 \fIData syntax and terminal requirements\fR .sp 9p .RT .PP The requirements defined in CCITT Recommendation T.101 (Annexes B, C and D) apply. .RT .sp 2P .LP \fB8\fR \fBAccess to MHS\fR .sp 1P .RT .sp 1P .LP 8.1 \fIGeneral\fR .sp 9p .RT .PP This paragraph describes the characteristics of CCTs to access MHS and specifies how the various related Recommendations may be used. .RT .sp 1P .LP 8.2 \fICharacteristics\fR .sp 9p .RT .PP In its present form, the message handling system has as its fundamental component the message transfer system (MTS), which comprises a number of message transfer agents (MTAs). A CCT can then access MHS in two ways as described in Figure\ 4/T.65 and the text below. .RT .LP .rs .sp 7P .ad r \fBFigure 4/T.65, p.\fR .sp 1P .RT .ad b .RT .LP i) The CCT can access MHS through a telematic interworking facility (TIF) as defined in Recommendations\ T.300\(hySeries. .LP ii) The CCT can support the MHS user agent functions to access the MTS directly. .sp 1P .LP 8.3 \fIApplicability of the relevant CCITT Recommendations\fR .sp 9p .RT .PP When a CCT does not support the MHS user agent functions it shall access MHS through a TIF, which provides for interworking between Telematic services and MHS. In this case the relevant sections of Recommendations\ T.300\(hySeries and\ T.65 apply, depending on the choice of protocols and terminal characteristics. .PP When a CCT supports the MHS user agent functions in addition to the Telematic protocols and terminal characteristics, it will use the relevant sections in the series of Recommendations\ X.400. .RT .sp 2P .LP \fB9\fR \fBAccess to the directory service\fR .sp 1P .RT .sp 1P .LP 9.1 \fIGeneral\fR .sp 9p .RT .PP The access of CCTs to the directory service will often precede the other CCITT\(hydefined services such as MHS, Teletex, or telephony, in order to determine or ascertain the address of a user or service. This section describes the characteristics of such an access and specifies how the various related Recommendations may be used. .bp .RT .sp 1P .LP 9.2 \fICharacteristics\fR .sp 9p .RT .PP In its present form, the directory system has two fundamental components: the directory user agent (DUA) and the directory (see Figure\ 5/T.65). .RT .LP .rs .sp 10P .ad r \fBFigure 5/T.65, p.\fR .sp 1P .RT .ad b .RT .PP In terms of this model two ways of CCT access are possible: .LP i) The CCT can access the DUA using suitable telematic protocols and terminal characteristics defined in the T\(hySeries of Recommendations. .LP ii) The CCT can support DUA functions to access the directory directly. .PP It should be noted that directory access is essentially an interactive application. Therefore, this interactive nature influences the protocol and terminal requirements. .sp 1P .LP 9.3 \fIApplicability of the relevant CCITT Recommendations\fR .sp 9p .RT .PP When a CCT does not support DUA functions, it shall access the directory through a DUA. In this case the relevant sections of the Recommendations\ X.500 and\ T.65 apply, depending on the choice of protocols and terminal characteristics. .PP When a CCT supports DUA functions in addition to the Telematic protocols and terminal characteristics it will use the relevant sections in the series of Recommendations\ X.500. \v'1P' .RT .sp 2P .LP \fBRecommendation\ T.70\fR .RT .sp 2P .sp 1P .ce 1000 \fBNETWORK\(hyINDEPENDENT\ BASIC\ TRANSPORT\ SERVICE\fR | \fBFOR\ THE\ TELEMATIC\ SERVICES\fR .EF '% Fascicle\ VII.5\ \(em\ Rec.\ T.70'' .OF '''Fascicle\ VII.5\ \(em\ Rec.\ T.70 %' .ce 0 .sp 1P .ce 1000 \fI(Geneva, 1980, amended at Malaga\(hyTorremolinos, 1984,\fR .sp 9p .RT .ce 0 .sp 1P .ce 1000 \fIand Melbourne, 1988)\fR .ce 0 .sp 1P .LP The\ CCITT, .sp 1P .RT .sp 1P .LP \fIconsidering\fR .sp 9p .RT .PP (a) that the Teletex service will be introduced in different types of network, i.e.\ circuit\(hyswitched public data networks (CSPDN), packet\(hyswitched public data networks (PSPDN) and the public switched telephone network\ (PSTN); .PP (b) that there is a need for international interworking \ between terminals belonging to the same or different types of Telematic services ; .bp .LP \fIunanimously declares the following view\fR .sp 1P .RT .sp 2P .LP \fB1\fR \fBScope\fR .sp 1P .RT .PP 1.1 This Recommendation defines the \fInetwork\(hyindependent basic\fR \fItransport service\fR applicable to Teletex and Group\ 4 facsimile terminals connected to the types of network mentioned in\ (a) above in terms of: .sp 9p .RT .LP a) the transport services provided to the higher layer [the transport services are provided by the transport layer (layer\ 4) in association with the underlying services provided by the supporting layers\ 1 to\ 3]; .LP b) the transport layer procedure (see \(sc\ 5 below). .PP 1.2 Paragraph 2 describes the transport service. Paragraph\ 3 describes the transport service implementation for different types of networks. Paragraph\ 4 outlines the guidelines for interworking between networks. Paragraph\ 5 specifies the transport layer procedure, and Annexes\ A and\ B provide associated state transition diagrams and tables respectively. .LP \fB2\fR \fBTransport service\fR .sp 1P .RT .sp 2P .LP 2.1 \fITransport service objectives\fR .sp 1P .RT .PP 2.1.1 The purpose of the transport service is to provide two communicating session entities within two terminals with transport services, i.e.\ the means for transparent and reliable end\(hyto\(hyend transfer of data between them irrespective of the particular type of network used. .sp 9p .RT .PP 2.1.2 The main requirements of the transport service to be provided by a transport entity to the local transport user, i.e.\ the session entity, are: .LP a) \fINetwork independence\fR . The transport service shall be homogeneous, while allowing a suitable wide variety of underlying communications media, protocols and mechanisms. .LP b) \fIEnd\(hyto\(hyend significance\fR . The transport service shall have end\(hyto\(hyend significance, connecting the end users irrespective of the number of individual communication links used. .LP c) \fITransparency\fR . The transport service shall be octet transparent, i.e.\ not restrict the content, format or coding of the information (data or control) received from or delivered to the transport user. .LP d) \fIError\(hyfree delivery\fR . The transport service shall assure error\(hyfree delivery. Non\(hyrecoverable errors are to be visible to the transport service user. .LP e) \fICost efficiency\fR . The transport service shall optimize the use of the available communication resources to provide the performance required by each communicating transport user at maximum efficiency. .sp 2P .LP 2.2 \fIGeneral structure of the transport service\fR .sp 1P .RT .PP 2.2.1 The general structure of the transport service is shown in Figure\ 1/T.70. .sp 9p .RT .sp 2P .LP \fB3\fR \fBTransport service implementation for different types of\fR \fBnetworks\fR .sp 1P .RT .PP \fINote\fR \ \(em\ The transport layer procedure on all types of networks is defined in \(sc\ 5. The network dependent control procedures of the underlying layers are described in the following. .RT .sp 2P .LP 3.1 \fITerminals connected to a PSPDN\fR .sp 1P .RT .sp 1P .LP 3.1.1 \fIPhysical layer\fR \fIDTE/DCE interface characteristics\fR .sp 9p .RT .PP The physical layer of Recommendation\ X.25 applies. .RT .sp 1P .LP 3.1.2 \fILink layer procedure\fR .sp 9p .RT .PP The link layer procedure shall, unless otherwise specified, be the symmetrical procedures as specified in Recommendation\ X.25, LAPB (Link Access Procedure\ B). .bp .RT .LP .rs .sp 47P .ad r \fBFigure 1/T.70 TO803680\(hy89, p.6\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 3.1.3 \fINetwork layer procedure\fR .sp 9p .RT .PP Recommendation X.25 Virtual Call procedures apply. However the following points should be noted when using this transport protocol : .RT .LP a) The qualifier bit in data packets should always be set to 0. .LP b) The delivery confirmation bits in all packets should be set to\ 0. .LP c) The terminal should not send an \fIinterrupt request\fR packet. .LP d) Normal X.25 reset procedures will apply. .LP e) Each control block or data block of the transport layer shall be carried in a complete data packet sequence. .LP f ) The terminal should not send a \fIDTE\ REJ packet\fR . .LP g) Terminals shall use a specific protocol identifier within call request/incoming call packets for the Teletex service and Group\ 4 facsimile apparatus. This identifier is represented by the first octet of the call user data field (remaining octets, if any, should be ignored) as shown below: .LP bit 87654321 .LP octet\ 1 00000010 .LP In the case of CSPDN/PSPDN interworking the functional mapping of this protocol identifier requires further study. .LP h) Terminals shall not use the fast select facility. .sp 2P .LP 3.2 \fITerminals connected to the PSTN\fR .sp 1P .RT .sp 1P .LP 3.2.1 \fIPhysical layer DTE/DCE interface characteristics\fR .sp 9p .RT .PP The DTE/DCE physical layer element shall be in accordance with existing Series\ V Recommendations. The physical layer may provide for half\(hyduplex or full\(hyduplex transmission depending on the modem standard. .PP \fINote\fR \ \(em\ The PSTN modem standards are discussed in Study Group\ XVII. Furthermore, in the case of a modem integrated in the terminal, the interface may only be functionally equivalent to a Series\ V Recommendation. This is also for further consideration in Study Group\ XVII. .RT .sp 2P .LP 3.2.2 \fILink layer procedure\fR .sp 1P .RT .PP 3.2.2.1 Depending on the service provided by the physical layer, the link layer procedures over a single physical circuit between two terminals have to cater for a half\(hyduplex or full\(hyduplex transmission facility to provide a full\(hyduplex service to the network layer. For full\(hyduplex physical layer service, the link layer procedure shall conform to the Link Access Procedure described in Recommendation\ X.75, for single link operation. For addressing assignments and the system parameters see \(sc\(sc\ 3.2.2.2 and\ 3.2.2.3 respectively. For half\(hyduplex physical layer service the link layer procedure is as defined in Recommendation\ T.71. This is a half\(hyduplex Link Access Procedure , based on Recommendation\ X.75 for single link operation. .sp 9p .RT .PP 3.2.2.2 The following describes the application of the link addressing procedure of Recommendation\ X.75. Link addresses (A\ and\ B) shall be assigned dynamically or on a per\(hycall basis according to the following rules: .LP a) the calling terminal shall take Address\ A; .LP b) the called terminal shall take Address\ B; .LP c) commands and responses shall be transferred as shown in Figure\ 2/T.70; .LP d) A and B addresses are coded as follows: .LP Address 12345678 .LP \ \ A 11000000 .LP \ \ B 10000000 .PP \fINote\fR \ \(em\ The terminal will discard all frames received with an address other than\ A and\ B. .bp .LP .rs .sp 9P .ad r \fBFigure 2/T.70 p.\fR .sp 1P .RT .ad b .RT .PP 3.2.2.3 System parameters are: .LP a) timer, T1; .LP b) maximum number of retransmissions, N2; .LP c) maximum number of bits in an I frame, N1; .LP d) maximum number of outstanding I frames, \fIk\fR . .PP The above system parameters are to be specified by the Administration. However, the possible range of values that may be attributed to each parameter is to be standardized. Such values are for further study. .sp 2P .LP 3.2.3 \fINetwork layer procedure\fR .sp 1P .RT .PP 3.2.3.1 See \(sc\ 3.1.3. In addition, for all calls (PSTN only, PSTN\(hyPSPDN, PSTN\(hyPSPDN\(hyPSTN) second stage addressing will apply using X.25 virtual call procedures. The calling terminal should include the called address and the calling address (see Note\ 2) in call request packets. The format of the called address shall conform to: .sp 9p .RT .LP a) the telephone network addressing scheme for PSTN only calls; .LP b) the telephone network addressing scheme with an X.121 DNIC for PSTN\(hyPSPDN calls (see Note\ 3); .LP c) the X.121 addressing scheme for PSTN\(hyPSPDN calls (see Note\ 1). .PP \fINote\ 1\fR \ \(em\ For other cases of internetworking the above rule shall apply. .PP \fINote\ 2\fR \ \(em\ In the case of PSTN\(hyPSPDN calls the verification of the calling address by the network requires further study. The format of the calling address is for further study. .PP \fINote\ 3\fR \ \(em\ The feasibility of such connections is for further study. .RT .sp 2P .LP 3.3 \fITerminals connected to a CSPDN\fR .sp 1P .RT .sp 1P .LP 3.3.1 \fIPhysical layer DTE/DCE interface characteristics\fR .sp 9p .RT .PP The DTE/DCE physical interface characteristics shall be in accordance with Recommendation\ X.21, or as an option, Recommendation\ X.22 for multi\(hycall operation. .RT .sp 2P .LP 3.3.2 \fILink layer procedure\fR .sp 1P .RT .sp 1P .LP 3.3.2.1 \fIGeneral\fR .sp 9p .RT .PP The link layer procedure shall be used during the data phase of Recommendation\ X.21 (or\ X.22) for data interchange over a single physical circuit between two terminals operating in User Classes of Services\ 3 to\ 7 and\ 30 as defined in Recommendation\ X.1. The link layer procedure shall consist of a fully symmetrical HDLC procedure as defined in Recommendation\ X.75 for single link operation. .bp .RT .sp 1P .LP 3.3.2.2 \fILink layer address procedure\fR .sp 9p .RT .PP The following describes the application of the link addressing procedures of Recommendation\ X.75. Link addresses (A\ and\ B) shall be assigned dynamically on a per\(hycall basis according to the following rules: .RT .LP a) the calling terminal shall take address\ A; .LP b) the called terminal shall take address\ B; .LP c) commands and responses shall be transferred as shown in Figure\ 3/T.70; .LP d) A and B addresses are coded as follows: .LP Address 12345678 .LP \ \ A 11000000 .LP \ \ B 10000000 .PP \fINote\fR \ \(em\ The terminal will discard all frames received with an address other than\ A and\ B. .LP .rs .sp 9P .ad r \fBFigure 3/T.70, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 3.3.2.3 \fILink layer implementation rules\fR .sp 9p .RT .PP In order to achieve full compatibility between different implementations, the rules below for the implementation of Recommendation\ X.75 shall be followed. .RT .sp 1P .LP 3.3.2.3.1 \fIGeneral rules\fR .sp 9p .RT .LP a) The 1984 version (\fIRed Book\fR ) of CCITT Recommendation\ X.75, \(sc\ 2, shall be used as the reference specification. .LP b) The term \*QSTE\*U shall be read as \*QDTE\*U. .LP c) The Non\(hyExtended mode of operation (modulo 8) shall be used. .LP d) Only the single link procedure (SLP) shall be used. .sp 1P .LP 3.3.2.3.2 \fISpecific rules\fR .sp 9p .RT .PP The following rules refer to the indicated sections and tables of Recommendation\ X.75. .RT .LP a) \fITable 1/X.75\fR (see Note 1) .LP I\(hyframe must not be sent with an empty I\(hyfield. .LP N\ \(>="\ 0 .LP N\ \(=\ N1 \(em 32 .LP A received empty I\(hyframe shall be treated as a valid I\(hyframe. .LP b) \fI\(sc 2.3.4.9\fR .LP Subparagraphs 5), 6) and 7) are not valid (shall not result in the sending of a FRMR). Instead the following actions shall be implemented: .LP \(em Not expected supervisory frames with the F bit set to 1 shall be ignored. .LP \(em Not expected UA or DM response shall be ignored. .LP \(em Frames with an invalid N(S) shall be responded to by sending REJECT. .LP Frames with a FRMR cntrol field shall not be responded by sending a FRMR. .bp .LP c) \fITable 7/X.75\fR .LP Bits W, X, Y and Z set to 0 indicate that no reason for frame rejection is given. .LP d) \fI\(sc 2.3.5.3\fR .LP The DTE and the CSPDN are not octet aligned and the last paragraph is therefore not valid. .LP e) \fI\(sc 2.3.5.5\fR .LP Higher layers should be notified when timer T3 expires (excessive idle state). .LP f ) \fI\(sc 2.4.3\fR .LP Related to the first paragraph, read instead of \*Qnext response\*U \*Qcorresponding response\*U. .LP g) \fI\(sc 2.4.4.1\fR .LP In the active channel state, the DTE shall transmit contiguous flags independent of the other DTE. .LP The calling DTE shall initialize the link by sending a SABM command with the P\ bit set to\ 1. .LP h) \fI\(sc 2.4.4.4.1\fR .LP A condition for entering the disconnected phase is also that no unacknowledged DISC command exists, because of collision cases (Ref.\ X.75, \(sc\ 2.4.4.5). .LP In the disconnected phase, it is the calling DTE which may initiate link set up. .LP i) \fI\(sc 2.4.5.9, fourth paragraph\fR .LP If a RNR is received, the DTE shall remain in the timer recovery condition (because the other DTE is still in the busy condition). .LP j) \fI\(sc 2.4.5.9, fifth paragraph\fR .LP If a RNR is received, the DTE shall not resume I\(hyframe transmission or retransmission. .LP k) \fI\(sc 2.4.5.9, last paragraph\fR .LP If the transmission attempt variable is equal to N2, the DTE shall enter the disconnected phase. .LP l) \fI\(sc 2.4.7.3\fR .LP In the frame rejection condition, the DTE shall only check the commands and react with a FRMR according to the P\ bit. .LP The frame rejection condition is cleared when the DTE receives a SABM, or, receives or transmits a DISC command. .LP m) \fI\(sc 2.4.7.3, second paragraph\fR (see Note 2) .LP Only the DTE which caused the FRMR condition may try to reset the link. .LP n) \fI\(sc 2.4.7.3, third paragraph\fR (see Note 3) .LP After N2 attempts to get the other DTE to reset the link, the DTE shall enter the disconnected phase. .LP o) \fI\(sc 2.4.8.1\fR (see Note 4) .LP The timer T1 shall be started at the end of frame transmission. The value of T1 depends on the data signalling rate, the frame length, the value of N2 and a fixed time of 1.5\ s representing both T2 and the transmission delay [see \(sc\ 3.3.2.3.2 | )]. The recommended value range is: 1.5\(hy15\ s. .LP p) \fI\(sc 2.4.8.2\fR (see Note 4) .LP T1\ >\ T2 .LP T2\ \(=\ 1\ s .LP Depending on the acknowledgement strategy used, the DTE designer may regard T2 as a decision parameter only, in which case the DTE is not obliged to implement a corresponding timer. .LP q) \fI\(sc 2.4.8.3, second paragraph\fR .LP 30\ s\ \(=\ T3\ \(=\ 60\ s .LP r) \fI\(sc 2.4.8.4\fR .LP N2\ \(mu\ T1\ \(>="\ 60\ s .LP s) \fI\(sc 2.4.8.5\fR .LP N1 = 1080 + (\fIn\fR \(mu 1024) bits; \fIn\fR = 0 or 1 or 3 or 7 or 15. .LP t) \fI\(sc 2.4.8.6\fR (see Note 4) .LP \fIk\fR = 2 \(em 7 (modulo 8) .bp .LP \fINote\ 1\fR \ \(em\ Terminals complying with the \fIRed Book\fR version of Recommendation\ T.70 may react by DL Reset ind. (FRMR). .LP \fINote\ 2\fR \ \(em\ Terminals complying with the \fIRed Book\fR version of Recommendation\ T.70 may react differently. .LP \fINote\ 3\fR \ \(em\ It is not meaningful to reset the link if the other DTE is not responding for N2\ \(mu\ T1. .LP \fINote\ 4\fR \ \(em\ The acknowledgement strategy used by the receiving DTE should be independent of any knowledge about the value of \fIk\fR used by the sending DTE. This can be achieved by either acknowledging every correctly received I\(hyframe as soon as possible or by implementing an acknowledgement timer, i.e.,\ a T2 timer as defined above [see \(sc\ 3.3.2.3.2 | )]. .sp 2P .LP 3.3.3 \fINetwork layer procedure\fR .sp 1P .RT .sp 1P .LP 3.3.3.1 \fICall control phase\fR .sp 9p .RT .PP The call control procedure conforms to Recommendation\ X.21, or as an option, Recommendation\ X.22 for multi\(hycall operation. .RT .sp 1P .LP 3.3.3.2 \fIData transfer phase\fR .sp 9p .RT .PP A minimal network layer is present during the data transfer phase and accommodated through the use of a two\(hyoctet network block header. The header comprises a one\(hyoctet length indicator followed by a network block type code specified below. The only network block currently defined is a network protocol data block as shown in Figure\ 4/T.70. .RT .LP .rs .sp 22P .ad r \fBFigure 4/T.70, p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 3.3.3.3 \fIData transfer procedure\fR .sp 1P .RT .sp 1P .LP 3.3.3.3.1 \fIHandling of the\fR \fIM\(hybit\fR .sp 9p .RT .PP The calling DTE shall negotiate the TPDU size with the called DTE at the transport layer, based on either the maximum TPDU size supported or the optimum TPDU size for the specific call, unless the default value of 128 octets is used. The agreed value will allow the sending DTE to transfer TPDUs without the need for segmenting at the Network layer and consequently the M\(hybit is set to zero. .bp .PP However, receiving DTEs must always be capable of reassembling segmented TPDUs by using the M\(hybit, since segmenting may take place in the network in some interworking situations, e.g.,\ when the composite network connection comprises a PSDN. .RT .sp 1P .LP 3.3.3.3.2 \fIError procedures\fR .sp 9p .RT .PP A Data PDU with a length indicator different from hexadecimal \*Q01\*U and/or with less than three octets shall be discarded and the physical network connection shall be cleared. .RT .sp 1P .LP 3.4 \fITerminals connected to an ISDN\fR .sp 9p .RT .PP See Recommendation T.90. .RT .sp 2P .LP \fB4\fR \fBInterworking between networks\fR .sp 1P .RT .PP 4.1 It is the responsibility of Administrations to decide in which network(s) the telematic services are to be provided. .sp 9p .RT .PP 4.2 Four possibilities are considered below: .LP a) Terminals connected to a circuit switched public data network\ (CSPDN); .LP b) Terminals connected to a packet switched public data network\ (PSPDN); .LP c) Terminals connected to a public switched telephone network\ (PSTN); .LP d) Terminals connected to an integrated services digital network (ISDN). .PP 4.3 Interworking between telematic terminals connected to any network must be possible. .PP 4.4 International interworking between telematic terminals shall preferably take place between networks of the same type when these networks are provided by both countries involved. .PP 4.5 In the case of international interworking between telematic terminals connected to dissimilar networks, Recommendation\ X.300 shall apply. .PP The interworking between CSPDNs and PSPDNs is described in Recommendation\ X.82 (Detailed arrangements for interworking between CSPDNs and PSPDNs based on Recommendation\ T.70). .LP \fB5\fR \fBTransport layer procedure\fR .sp 1P .RT .sp 2P .LP 5.1 \fITransport functions\fR .sp 1P .RT .sp 1P .LP 5.1.1 \fIGeneral\fR .sp 9p .RT .PP 5.1.1.1 The transport layer will perform all those functions that are necessary to bridge the gap between the services provided by the network layer and the services needed by the session layer . Therefore, the functions performed are dependent on two criteria: the services provided by the underlying network layer and the services required by the session layer. .sp 9p .RT .PP 5.1.1.2 It is the responsibility of the transport service user to select a given quality of service, which may imply the use of certain transport layer functions such as: .LP a) establishment of a transport connection .LP \(em transport connection identification .LP \(em transport connection multiplexing; .LP b) data transfer .LP \(em sequence control .LP \(em error detection .LP \(em error recovery .LP \(em segmenting and reassembling .LP \(em flow control .LP \(em purge; .LP c) termination of a transport connection. .PP \fINote\fR \ \(em\ Not all of the above functions will be available in the basic transport service (see \(sc\ 5.1.3). .bp .sp 2P .LP 5.1.2 \fITransport protocol classes\fR .sp 1P .RT .PP 5.1.2.1 Transport layer functions are grouped (for ease of negotiation) into a hierarchical system of transport protocol classes whereby classes occupying superior positions in the hierarchy implement functions of the lower classes together with the optional functions identified for their own class. .sp 9p .RT .PP 5.1.2.2 During transport connection establishment the use of a given transport protocol and optional functions should be negotiated according to the following rules: .LP \(em the calling terminal indicates the transport protocol class and (if applicable) the optional functions required; .LP \(em the called terminal indicates the transport protocol class and (if applicable) the optional functions that it is willing to support; .LP \(em all parameters to be used in the transport connection must be explicity indicated, otherwise default values will apply. .PP 5.1.2.3 The basic transport service described here is fulfilled by a protocol denoted in Recommendation\ X.224 as transport protocol class\ 0. That protocol class is compatible with Recommendation\ T.70. In the event of a discrepancy between transport protocol class\ 0 as described in Recommendation\ X.224 and Recommendation\ T.70, the latter takes precedence. .sp 2P .LP 5.1.3 \fIThe basic transport service (TS)\fR .sp 1P .RT .PP 5.1.3.1 A limited set of transport layer functions is defined for a basic transport service. The basic transport service is provided by transport layer functions which are performed by \fItransport layer protocol\fR \fIelements\fR . .sp 9p .RT .PP 5.1.3.2 Transport protocol data units (TPDUs) carrying transport service (TS) user information or control information are called \fIblocks\fR . .PP 5.1.3.3 Transport layer block types are as follows: .LP a) transport connection request (TCR) block; .LP b) transport connection accept\fR (TCA) block; .LP c) transport connection clear (TCC) block; .LP d) transport data (TDT) block; .LP e) transport block reject (TBR) block. .PP 5.1.3.4 The TCR and TCA blocks are used to indicate the protocol class, and optional functions, applying to a transport connection. The TCC\ block is used to indicate the reason for refusing a connection establishment. The TDT block carries information of the transport service user. The TBR block is used to report procedure errors to the remote terminal. .sp 2P .LP 5.1.4 \fITransport layer functions\fR .sp 1P .RT .PP 5.1.4.1 Basic class functions and associated transport layer protocol elements, i.e.\ blocks, include: .sp 9p .RT .LP a) transport connection establishment, transport connection identification, optional extended addressing and optional transport data block size negotiation (TCR, TCA and\ TCC blocks); .LP b) data delimitation, segmentation/reassembling of arbitrarily long transport service data units (TSDU). These are contained within TDT\ blocks. The end of a TSDU is indicated by a TSDU end mark in the last data block; .LP c) detection and indication of procedural errors (TBR\ block). .PP 5.1.4.2 Other characteristics of the basic transport service are: .LP a) maintenance of TSDU integrity; .LP b) overflow: if the user cannot absorb new data and if the appropriate buffers are not available, flow control is performed at the network/link layer as appropriate; .LP c) error: no mechanism is provided within the transport layer to facilitate recovery from detected errors. Where such errors are detected the user of the transport service should be informed so that appropriate recovery action may be taken. .bp .LP 5.2 \fIDescription of connection establishment and termination\fR \fIprocedures\fR .sp 1P .RT .sp 2P .LP 5.2.1 \fIGeneral\fR .sp 1P .RT .PP 5.2.1.1 The transport layer connection establishment and termination procedures shall also be used for negotiating transport protocol class and, if applicable, optional transport connection functions. .sp 9p .RT .PP 5.2.1.2 For the basic transport service, means are provided to establish a transport connection using a TCR\ block and a TCA\ block. This exchange provides: .LP a) a way to negotiate options; .LP b) a transport connection identification. The transport connection is identified by use of cross\(hyreferences. Each end of the connection is responsible for selecting a suitable transport connection identifier. .PP 5.2.1.3 This mechanism also provides an identification of the transport connection independent of any network connection identification and therefore provides independence from the life of the network connection. The binary value\ 0 should not be used as an identifier. The use of such references for reconnection requires further definition. .sp 2P .LP 5.2.2 \fITransport connection request (TCR) block\fR .sp 1P .RT .PP 5.2.2.1 The calling terminal shall indicate a transport connection request by transferring a TCR\ block to the remote terminal. The TCR\ block includes the transport functions (e.g.\ source reference, class, and optional functions) for negotiation of the characteristics of the transport connection being established. .sp 9p .RT .sp 2P .LP 5.2.3 \fITransport connection accept (TCA) block\fR .sp 1P .RT .PP 5.2.3.1 The called terminal shall indicate its acceptance of the transport connection by transferring a TCA\ block to the remote terminal. The TCA\ block includes the transport parameters applying to the connection and to be used by the calling terminal. .sp 9p .RT .PP 5.2.3.2 If a terminal receives the request for an optional TDT block size it may either: .LP \(em indicate its support by reproducing the requested value in the TCA\ block; .LP \(em request in the TCA block the use of a shorter allowable TDT\ block. The calling side either accepts this size by sending the first TDT\ block or disconnects the network connection; .LP \(em not accept the requested TDT block size parameter value by sending a TCA\ block without a TDT\ block size parameter. Therefore, the standardized TDT\ block size will apply. .PP A TCR requesting an optional TDT block size not supported by the called side should not be answered with\ TBR. .sp 2P .LP 5.2.4 \fITransport connection clear (TCC) block\fR .sp 1P .RT .PP 5.2.4.1 If a transport connection cannot be established, the called terminal shall respond to the TCR\ block with a TCC\ block. The clearing cause shall indicate why the connection was not accepted. .sp 9p .RT .PP It is up to the calling side whether the receipt of a TCC will cause complete disconnection or whether a new TCR with a parameter different from the first one will be sent (e.g.\ another extended transport layer address). In order to allow for subsequent TCRs, the sender of TCC may provide in the optional parameter field an appropriate parameter and associated value to indicate that another TCR is invited. The new optional parameter and its associated value(s) are for further study. .PP \fINote\fR \ \(em\ There is no explicit transport connection termination procedure in this Recommendation. Therefore, the lifetime of the transport connection is directly correlated to the lifetime of the supporting network connection. .RT .sp 2P .LP 5.2.5 \fITransport connection collision\fR .sp 1P .RT .PP 5.2.5.1 If the calling terminal receives a TCR block, it shall transfer a TBR\ block to notify the called terminal of the procedure error (see Annex\ B). .bp .sp 9p .RT .sp 2P .LP 5.2.6 \fIExtended addressing\fR .sp 1P .RT .PP 5.2.6.1 The extended addressing capability may be used to address terminals in a multiterminal configuration. .sp 9p .RT .PP The extension addresses for called and calling terminals are optional parameters to TCR and TCA. The use of the calling extension address is for further study. .PP 5.2.6.2 The receiving terminal shall respond with a TCA according to Table\ 1/T.70. .ce \fBH.T. [T1.70]\fR .ce TABLEAU\ 1/T.70 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(72p) | cw(78p) sw(78p) , ^ | c | c. Received TCR Receiver reaction { Multi\(hyterminal with extended addressing | ua\d\u)\d } Stand\(hyalone terminal _ .T& lw(72p) | cw(78p) | cw(78p) . Without extended addressing { Send TCA with extended addressing } { Send TCA without extended addressing } _ .T& lw(72p) | cw(78p) | cw(78p) . With extended addressing { Send TCA with extended addressing | ub\d\u)\d } { Send TCA without extended addressing } .TE .LP \ua\d\u)\d Multi\(hyterminal configuration, with capability for extended addressing. .LP \ub\d\u)\d If the called terminal is occupied or out of order, the call should be routed to a default terminal or mailbox. The sender will then be informed of the routing by the extension address of the connected terminal. The receiver of TCR may also in this case react by sending TCC. .nr PS 9 .RT .ad r \fBTable 1/T.70 [T1.70], p.\fR .sp 1P .RT .ad b .RT .LP .sp 3 .PP 5.2.6.3 The calling terminal may, when receiving a called terminal address in the TCA, act as specified in Table\ 2/T.70. .ce \fBH.T. [T2.70]\fR .ce TABLE\ 2/T.70 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(72p) | cw(56p) sw(50p) sw(50p) , ^ | c s s ^ | c | c | c. Sent TCR Calling terminal reaction TCA received with: No extended addressing Correct extended addressing Incorrect extended addressing _ .T& lw(72p) | cw(56p) | cw(100p) . Without extended addressing OK Neglect extension (See Note) _ .T& lw(72p) | cw(56p) | cw(50p) | cw(50p) . With extended addressing \ua\d\u)\d OK \ua\d\u)\d .TE .LP \ua\d\u)\d\ Reaction left to the discretion of the calling terminal. .LP \fINote\fR \ \(em\ Terminal complying with the 1980\(hy1984 version of Recommendation T.70 may react by releasing the network connection. .nr PS 9 .RT .ad r \fBTable 2/T.70 [T2.70], p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP 5.3 \fIDescription of\fR \fIdata transfer procedures\fR .sp 1P .RT .sp 2P .LP 5.3.1 \fIGeneral\fR .sp 1P .RT .PP 5.3.1.1 The data transfer procedure described in the following subsections applies only when the transport layer is in the data transfer phase, i.e.\ after completion of transport connection establishment and prior to clearing. .sp 9p .RT .PP \fINote\fR \ \(em\ When a connection is cleared, transport data blocks may be discarded. Hence it is left to the transport service user to define protocols able to cope with the various possible situations that may occur. .sp 2P .LP 5.3.2 \fITransport data block (TDT) length\fR .sp 1P .RT .PP 5.3.2.1 The standard maximum TDT block length to be supported by all terminals is 128\ octets including the data block header octets. However, the TDT\ block length may be restricted to a lower value when the TDT\ block is concatenated with other TDT\ blocks (see \(sc\ 5.5.3). .sp 9p .RT .PP 5.3.2.2 Other maximum data field lengths may be supported in conjunction with an optional TDT\ block size negotiation connection function (see \(sc\(sc\ 5.5.4.3 and\ 5.5.5.3). Optional maximum data field lengths shall be chosen from the following:\ 256, 512, 1024 and\ 2048\ octets. If the requested optional TDT\ block size cannot be supported, a shorter allowable TDT\ block size must be selected (see \(sc\ 5.2.3.2). .PP The agreed maximum TDT block size should be aimed at for TDT\ blocks having the TSDU end mark set to\ 0 and a number of octets less than the agreed maximum shall not cause the receiving transport entity to reject this TDT\ block. .sp 2P .LP 5.3.3 \fITransport service data unit (TSDU)\fR \fIend\fR .sp 1P .RT .PP 5.3.3.1 The \fITSDU end mark\fR is used to preserve the integrity of the TSDU. The TSDU end mark is set to binary\ 1 in the last TDT\ data block carrying information related to a certain TSDU. Exceptionally, this TDT\ block may be sent without carrying user information in order to allow for an immediate termination of a TSDU in certain error conditions. .sp 9p .RT .PP In case of a TSDU that comprises a single TDT\ block the TSDU end mark is also set to\ 1. In all other cases the TSDU end mark is set to zero. .sp 2P .LP 5.4 \fITreatment of procedure errors\fR .sp 1P .RT .PP 5.4.1 A terminal shall send a TBR block to the remote terminal to report the receipt of an invalid or not implemented block (if not explicitly specified otherwise in this Recommendation). During the establishment of a transport connection, terminals shall not send a TBR\ block upon the receipt of a TCR\ block whose parameters or parameter values are invalid or not implemented. In this case, terminals shall act as if no errors have occurred and send the appropriate response (if any). .sp 9p .RT .PP A terminal receiving a TBR block shall take appropriate recovery action. .PP \fINote\ 1\fR \ \(em\ A TBR whether invalid or valid shall not be answered by sending a TBR\ block. .PP \fINote\ 2\fR \ \(em\ Terminals complying with the Recommendation\ T.70 version of the 1981\(hy1984 study period may react to all of the above indicated conditions by sending\ TBR. .PP \fINote\ 3\fR \ \(em\ The definition of invalid block/parameter, etc. is provided by the state transition tables (see Annex\ B). .PP \fINote\ 4\fR \ \(em\ A TCR of which the PV of the TPDU size parameter is less than 07 (which is the basic length of the transport block size) shall be considered as an invalid TPDU. .PP \fINote\ 5\fR \ \(em\ In the states 1.1 for the calling side and 2.1 for the calling and called side the terminal may react either by sending TBR or by releasing the network connection. .PP \fIAttention\fR | \ The state tables and state transition diagrams have to be read according to Notes\ 4 and\ 5 above. .bp .RT .LP 5.5 \fIFormats\fR .sp 1P .RT .sp 2P .LP 5.5.1 \fIGeneral\fR .sp 1P .RT .PP 5.5.1.1 Transport protocol data units (TPDUs) carrying transport service (TS) user information or control information are called \fIblocks\fR (see \(sc\ 5.1.3). All blocks contain an integral number of octets. .sp 9p .RT .PP 5.5.1.2 Bits of an octet are numbered 8\ to\ 1 where bit 1 is the low order bit and is transmitted first. Octets of a block are consecutively numbered starting from\ 1 and are transmitted in this order. .PP When consecutive octets are used to represent a binary number, the lower octet has the most significant value. .PP 5.5.1.3 \fITDT block(s)\fR are used to transfer a transport service data unit (TSDU) transparently whilst maintaining the structure of the latter by means of the TSDU end mark. .PP 5.5.1.4 \fIControl blocks\fR (TCR, TCA, TCC, TBR) are used to control the transport protocol functions, including optional functions. .PP 5.5.1.5 A parameter field is present in all control blocks within the basic transport service to indicate optional functions. The parameter field contains one or more parameter elements. The first octet of each parameter element contains a parameter code to indicate the function(s) requested. .PP The general coding structure is shown in Figure 5/T.70. .LP .rs .sp 20P .ad r \fBFigure 5/T.70 p.\fR .sp 1P .RT .ad b .RT .PP 5.5.1.6 The parameter code field is binary coded and, without extension, provides for a maximum of 255\ para meters. Parameter code 11111111 is reserved for extension of the parameter code . The extension mechanism is for further study. .PP Octet 2 indicates the length, in octets, of the parameter value field. The parameter field length is binary coded and bit\ 1 is the low order bit of this indicator. .PP Octet 3 and subsequent octets contain the value of the parameter identified in the parameter code field. The coding of the parameter value field is dependent on the function being requested. .bp .RT .sp 2P .LP 5.5.2 \fIStructure of transport control and transport data blocks\fR .sp 1P .RT .PP 5.5.2.1 Figure 6/T.70 illustrates the general structure of transport layer blocks. A summary of transport layer blocks is given in Figure\ 7/T.70. .sp 9p .RT .LP .rs .sp 8P .ad r \fBFigure 6/T.70, p.\fR .sp 1P .RT .ad b .RT .LP .rs .sp 23P .ad r \fBFigure 7/T.70, p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 5.5.2.2 \fILength indicator (LI) field\fR .sp 1P .RT .sp 1P .LP 5.5.2.2.1\ \ Octet 1 contains the length indicator (LI) . The value of this indicator is a binary number that represents the length in octets of the control block (including parameters) and the header length in octets of data blocks (excluding any subsequent user information). In both cases this length does not include octet\ 1. .sp 9p .RT .LP 5.5.2.2.2\ \ The basic LI value shall be restricted to\ 127 (i.e.,\ a binary value of 01111111). The use of higher LI\ values and the use of the binary value 11111111 for extension purposes is for further study. .sp 2P .LP 5.5.2.3 \fIBlock type field\fR .sp 1P .RT .sp 1P .LP 5.5.2.3.1\ \ Octet 2 contains the block type code. Bits\ 1 to 4 of octet\ 2 are set to\ 0 for all transport layer blocks currently defined. It is for further study to determine whether or not bits\ 1 to\ 4 are required for future extension to the range of transport layer blocks currently defined or are used for other functions. .bp .sp 9p .RT .sp 2P .LP 5.5.2.4 \fIFunctional code field\fR .sp 1P .RT .sp 1P .LP 5.5.2.4.1\ \ Octet 3 and subsequent octets contain functional codes in a fixed format as per the block type (see Figure\ 7/T.70). .sp 9p .RT .sp 2P .LP 5.5.2.5 \fIParameter or TSDU field\fR .sp 1P .RT .sp 1P .LP 5.5.2.5.1\ \ A parameter field or a data field containing transport service (TS) user data may optionally follow the functional code field. .sp 9p .RT .sp 2P .LP 5.5.3 \fIConcatenation\fR .sp 1P .RT .PP 5.5.3.1 Concatenation of transport control and/or transport data blocks is currently not applicable to this Recommendation. However, where concatenation is used in the future, the arrangement shown in Figure\ 8/T.70 would apply. .sp 9p .RT .LP .rs .sp 36P .ad r \fBFigure 8/T.70, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP 5.5.4 \fITransport connection request (TCR) block format\fR .sp 1P .RT .PP 5.5.4.1 Figure 9/T.70 illustrates the format of the TCR block. .sp 9p .RT .LP .rs .sp 28P .ad r \fBFigure 9/T.70 p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 5.5.4.2 \fIParameters for extended addressing\fR .sp 9p .RT .PP Separate parameters are provided for the indication of called and calling extension addresses. The coding of these parameters is shown in Figure\ 10/T.70. The setting of bit\ 8 for extended addressing should be ignored by the transport layer. .PP The use of more than one called extension address is for further study. .RT .LP .rs .sp 13P .ad r \fBFigure 10/T.70, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 5.5.4.3 \fIParameter for transport data block size negotiation\fR .sp 9p .RT .PP This parameter defines the proposed maximum transport data block size (in octets including the transport data block header) to be used over the requested transport connection. The coding of this parameter is shown in Figure\ 11/T.70. .RT .LP .rs .sp 14P .ad r \fBFigure 11/T.70, p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 5.5.5 \fITransport connection accept (TCA) block format\fR .sp 1P .RT .PP 5.5.5.1 Figure 12/T.70 illustrates the format of the TCA block. .sp 9p .RT .LP .rs .sp 27P .ad r \fBFigure 12/T.70 p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 5.5.5.2 \fIParameters for extended addressing\fR .sp 9p .RT .PP See \(sc\ 5.5.4.2. .RT .sp 1P .LP 5.5.5.3 \fIParameter for transport data block size negotiation\fR .sp 9p .RT .PP See \(sc\ 5.5.4.3. The parameter value shall be equal to or less than the value specified in the TCR block. .RT .sp 2P .LP 5.5.6 \fITransport connection clear (TCC) block format\fR .sp 1P .RT .PP 5.5.6.1 Figure 13/T.70 illustrates the format of the TCC block. .sp 9p .RT .LP .rs .sp 43P .ad r \fBFigure 13/T.70, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 5.5.6.2 \fIParameter for additional clearing information\fR .sp 9p .RT .PP This parameter is provided to allow additional information relating to the clearing of the connection. The coding of this parameter is given in Figure\ 14/T.70 below. .RT .LP .rs .sp 12P .ad r \fBFigure 14/T.70 p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 5.5.7 \fITransport block reject (TBR) block format\fR .sp 1P .RT .PP 5.5.7.1 Figure 15/T.70 illustrates the format of the TBR block. .sp 9p .RT .LP .rs .sp 28P .ad r \fBFigure 15/T.70, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 5.5.7.2 \fIRejected block parameter\fR (mandatory) .sp 9p .RT .PP This parameter is used to indicate the bit pattern of the rejected block up to and including the octet that caused the rejection. Only the first detected procedural error or parameter, which cannot be acted upon, shall be indicated by this method. The coding of this parameter is given in Figure\ 16/T.70. .RT .LP .rs .sp 11P .ad r \fBFigure 16/T.70 p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 5.5.8 \fITransport data block (TDT) format\fR .sp 1P .RT .PP 5.5.8.1 Figure 17/T.70 illustrates the format of the TDT block. .sp 9p .RT .LP .rs .sp 18P .ad r \fBFigure 17/T.70 p.\fR .sp 1P .RT .ad b .RT .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation T.70) .sp 9p .RT .ce 0 .LP A.1 \fITransport and network service\fR .sp 1P .RT .PP The transport service (TS) is provided by the transport protocol (TP) making use of the services available from the network layer. This Annex also defines the\ TS characteristics which the TS\ users may exploit. .PP Interactions between TS users and the TS provider take place at the two TS access points (TSAP) (see Figures\ A\(hy1/T.70 to A\(hy6/T.70). Information is passed between a TS\ user and a TS\ provider by means of primitives, which may convey parameters. .bp .PP Primitives are abstract representations of interactions. They are solely descriptive and do not represent a specification or implementation. .PP The occurrence of a primitive is a logically instantaneous and indivisible event. The event occurs at a logically separate instant, which cannot be interrupted by another event. Only primitives of global significance are mentioned (having an impact on the remote user). .PP The following types of primitives are defined: .RT .LP a) request primitive .LP b) indication primitive .LP c) response primitive .LP d) confirm primitive. .PP The primitives a) and c) are directed from the service user to the service provider, b) and d) are going in the opposite direction. .PP \*QTransport\*U is designated by T, \*QNetwork\*U is designated by N. The terms CONNECT, DATA, DISCONNECT as part of a primitive name indicate that the primitive is used for establishment, data transfer, release of a transport connection \ (TC) or network connection \ (NC). .RT .sp 1P .LP \fIExamples:\fR .sp 9p .RT .LP T\(hyCONNECT request request to establish a TC .LP T\(hyDATA request request to transmit TS user data .LP N\(hyDISCONNECT indication indication that the NC has been released. .PP The relationship between valid sequences of TS primitives and the appropriate protocol elements is shown in Figures\ A\(hy1/T.70 to A\(hy6/T.70. The sequences of valid network service \ (NS) primitives are illustrated in Figures\ A\(hy7/T.70 to A\(hy12/T.70. .sp 1P .LP A.1.1 \fITransport service\fR .sp 9p .RT .PP The interactions shown in Figures\ A\(hy1/T.70 to A\(hy6/T.70 are not exhaustive. .RT .sp 1P .LP A.1.1.1\ \ \fITransport connection establishment\fR .sp 9p .RT .LP .rs .sp 19P .ad r \fBFigures A\(hy1/T.70 and A\(hy2/T.70 p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP A.1.1.2\ \ \fITransfer phase\fR .sp 9p .RT .LP .rs .sp 23P .ad r \fBFigure A\(hy3/T.70 p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP A.1.1.3\ \ \fITransport service error reporting\fR .sp 9p .RT .LP .rs .sp 18P .ad r \fBFigure A\(hy4/T.70 p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP A.1.1.4\ \ \fITC release\fR .sp 9p .RT .PP At present only the implicit release of TC is defined (see \(sc\ 5.2.4.1 of this Recommendation). .RT .LP .rs .sp 17P .ad r \fBFigures A\(hy5/T.70 and A\(hy6/T.70 p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP A.1.2 \fINetwork service\fR .sp 9p .RT .PP Figures A\(hy7/T.70 to A\(hy12/T.70 show the relationships of network service\ (NS) primitives at both sides of an\ NC. .RT .sp 1P .LP A.1.2.1\ \ \fINetwork connection establishment\fR .sp 9p .RT .LP .rs .sp 22P .ad r \fBFigures A\(hy7/T.70 and A\(hy8/T.70 p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP A.1.2.2\ \ \fINetwork data transfer\fR .sp 9p .RT .LP .rs .sp 12P .ad r \fBFigure A\(hy9/T.70 p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP A.1.2.3\ \ \fINetwork service error reporting\fR .sp 9p .RT .LP .rs .sp 13P .ad r \fBFigure A\(hy10/T.70 p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP A.1.2.4\ \ \fINetwork connection release\fR .sp 9p .RT .LP .rs .sp 13P .ad r \fBFigures A\(hy11/T.70 and A\(hy12/T.70 p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP A.2 \fIState transition diagrams for the basic\fR \fItransport layer\fR \fIprocedures\fR .sp 9p .RT .PP This part represents detailed state transition diagrams for the basic transport procedures. .PP Two description levels are used: .RT .LP a) \fIProtocol level\fR .LP This level addresses only the peer to peer protocol activities between two transport entities. It identifies the protocol state, events [receipt of transport protocol data units (TPDUs)] and actions (sending of TPDUs). .LP b) \fIDetailed level\fR .LP This level addresses the inter\(hylayer and local activities. It identifies the events, actions, conditions and states within each of the protocol level states. The inter\(hylayer activities are described using the transport service primitives defined in the first\ part of this Annex. .PP \fIExample\fR (see Figure\ A\(hy13/T.70) .PP For pure illustrative reasons, the example shows a simplified description of state 1 (response pending, called side) of the state transition diagram of this Recommendation. The event R\(hyTCR may be answered either by sending the action S\(hyTCA or\ S\(hyTCC. .PP The events and actions are not interruptable. They will complete their transfer irrespective of the occurrence of other events. .PP The detailed state transition diagrams are given in Figures\ A\(hy14/ and\ A\(hy15/T.70. .RT .LP .rs .sp 31P .ad r \fBFigure A\(hy13/T.70 p.37\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure A\(hy14/T.70 p.38\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure A\(hy15/T.70 p.\fR .sp 1P .RT .ad b .RT .LP .bp