InfoMagic Standards 1993 July

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

/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1992 / t / t564_1.asc < prev next >

Wrap

Text File | 1991-12-31 | 42.5 KB | 1,813 lines

Recommendation T.564 GATEWAY CHARACTERISTICS FOR VIDEOTEX INTERWORKING CONTENTS 1 Introduction 2 Scope and field of application 3 References 4 Definitions 5 Abbreviations 6 Model of the communication between local and external host 7 Relation between videotex and DTAM service 8 Use of lower layer services 9 General structure of the VIA 10 Videotex structure 1 Introduction This Recommendation specifies gateway characteristics which should be used for international videotex interworking between gateways. This document is a part of a set of standards produced to facilitate the interconnection of national videotex services. This set of standards is positioned with respect to the open systems interconnection basic reference model (Recommendation X.200). This document lies within the field of application layer of the OSI application layer. Inside the application layer it makes use of DTAM (document transfer, access and manipulation) specific application service element (Recommendation T.400). 2 Scope and field of application This Recommendation applies to the international videotex interworking between gateways as specified in this section. 2.1 National videotex services It is the responsibility of Administrations to decide the configuration of the national videotex services. 2.2 Videotex interworking definition Videotex interworking allows a videotex terminal pertaining to a given videotex service of a given country to interact in real time with a videotex host computer located in a different country. This videotex host may be either a videotex center of an external computer. 1 Fascicle VII.7 - Rec. T.564 2.3 Relation to other Recommendations Videotex interworking gateway characteristics are based upon concepts of DTAM defined in T.400 Series of Recommendations. Videotex interworking is conform to the videotex service defined in Recommendation F.300 and it is specified by the following profiles: - a document application profile specified in Recommendation T.504; - a communication application profile specified in Recommendation T.523; - an operational application profile specified in Recommendation T.541. General concepts of the international videotex interworking and the data syntaxes relevant for the videotex interworking are defined in Recommendation T.101. 3 References - Rec. F.300: Videotex service - Rec. X.200: Reference model of open systems interconnection for CCITT applications - Rec. X.213: Network service definition for open systems interconnection for CCITT applications - Rec. X.214: Transport service definition for open systems interconnection for CCITT applications - Rec. X.224: Transport protocol specification for open systems interconnection for CCITT applications - Rec. X.215: Session service definition for open systems interconnection for CCITT applications - Rec. X.225: Session protocol specification for open systems interconnection for CCITT applications - Rec. X.216: Presentation service definition for open systems interconnection for CCITT applications - Rec. X.226: Presentation protocol specification for open systems interconnection for CCITT applications - Rec. X.217: Association control service definition for open systems interconnection for CCITT applications - Rec. X.227: Association control protocol specification for open systems interconnection for CCITT applications - Rec. T.101: International interworking for videotex services - Rec. T.400 (1988): Introduction to document architecture, transfer and manipulation - Rec. T.411 (1988): Open document architecture (ODA) and interchange format - Introduction and general Fascicle VII.7 - Rec. T.564 2 principles - Rec. T.412 (1988): Open document architecture (ODA) and interchange format - Document structures - Rec. T.414 (1988): Open document architecture (ODA) and interchange format - Document profile - Rec. T.415 (1988): Open document architecture (ODA) and interchange format - Open document interchange format (ODIF) - Rec. T.431 (1988): Document transfer and manipulation (DTAM) - Services and protocols - Introduction and general principles - Rec. T.432 (1988): Document transfer and manipulation (DTAM) - Services and protocols - Service definition 3 Fascicle VII.7 - Rec. T.564 - Rec. T.433 (1988): Document transfer and manipulation (DTAM) - Services and protocols - Protocol specification - Rec. T.441 (1988): Document transfer and manipulation (DTAM) - Operational structure - Rec. T.504: Document application profile for videotex interworking - Rec. T.523: Communication application profile DM-1 for videotex interworking - Rec. T.541: Operational application profile for videotex interworking 4 Definitions The following definitions apply to all other parts of the Recommendation. This Recommendation makes use of the following terms as they are defined in Recommendation F.300: - videotex access point; - videotex frame; - videotex gateway; - videotex host; - videotex service; - videotex service center; - videotex terminal; - videotex user. This Recommendation makes use of the following terms as they are defined in Recommendation T.400: - attribute; - content portion; - page; - block; Fascicle VII.7 - Rec. T.564 4 - specific layout structure; - subordinate. 5 Abbreviations ACSE Association control service element CASE Common application service elements DDA Defined display area DTAM Document transfer, access and manipulation OSI Open systems interconnection SASE Specific application service element SE Structure element VIA Videotex interworking architecture 5 Fascicle VII.7 - Rec. T.564 6 Model of the communication between local and external host 6.1 International videotex interworking between gateways Videotex interworking may take place between videotex services in different countries, independently from the national configuration being used. An abstract configuration model has been established in Recommendation F.300 to represent an international videotex interworking configuration using gateways. In this abstract model, each cooperating country is represented by a videotex gateway. The DTAM protocol is intended to be used between the two gateways. Consequently a typical communication may be described as shown in Figure 1/T.564. FIGURE 1/T.564 The abstract model is not intended to be implemented as such. It is the responsibility of Administrations to decide how a gateway may be implemented. Throughout this document, and for a given terminal to videotex host communication, the gateway which supports the videotex terminal through its own national videotex service is called local host. On the other hand, the gateway which supports the videotex host through its own national videotex service is called external host. 6.2 Position of videotex interworking relative to OSI Videotex interworking between gateways is specified in a set of Recommendations (see 2.3) which are a part of the OSI application layer as defined by the OSI reference model (Recommen- dation X.200). Videotex interworking between gateways handles a specific architecture called videotex interworking architecture (VIA), conforming to DTAM document structures (T.410 Series of Recommendations) and DTAM operational structure (T.440 Series of Recommendations), and makes use of services and protocol provided by DTAM (T.430 Series of Recommendations). Videotex interworking gateway characteristics are specifying the general concepts of handling the VIA. The application profiles are specifying the use of DTAM document structures, DTAM operational structures, and DTAM service and protocol. Figure 2/T.564 depicts this situation: Fascicle VII.7 - Rec. T.564 6 FIGURE 2/T.564 6.3 Organization of the videotex interworking The videotex interworking application process consists of two parts which are in charge respectively of: - managing the communication with the peer entity; - supporting the local application process. The videotex interworking architecture (VIA), the DTAM service and the DTAM protocol correspond to the communicating part of the application process and represent those aspects of the application process which are pertinent to OSI. The VIA is a virtual data structure with a set of possible actions that can be performed on it. This structure is used to represent the current state of the communication between the two application processes. Any operation on VIA must be reported to the peer entity and to the videotex service user. These operations are reported to the peer entity by using the DTAM service which is provided by the DTAM protocol. Therefore, any action on the VIA implies: - an update of the local VIA; - the exchange of DTAM protocol elements in order to update accordingly the peer VIA. The local application process may also be expressed in terms of a videotex service which is offered on a national basis to a human user. This local application process is in charge of the mapping between the videotex service and the DTAM service. Note - Figure 3/T.564 is for information on the videotex interworking organization only. 7 Fascicle VII.7 - Rec. T.564 FIGURE 3/T.564 7 Relation between videotex and DTAM service (see Figure 4/T.564) This section does not form an integral part of this Recommendation. The local application process is in charge of the local mapping between the communicating OSI environment and the videotex service as defined by a given Administration. On the local host side, the local application process is in charge of converting the local host to external host dialogue into a videotex user dialogue. On the external host side, the local application process is in charge of converting the external host to local host dialogue into a national videotex host access dialogue. The two local application processes are able to communicate on an international basis by updating both their own and the peer entity VIA, which represents the common view of the communication as seen by both partners. To indicate that a VIA update is needed, the local process may express all the VIA modifications as DTAM service elements through the DTAM service interface. Any modification of the VIA must be reported to both the local and the remote users. When receiving a DTAM service primitive, the VIA is updated and the receiving local application process takes the updating into account. FIGURE 4/T.564 For a given definition of a videotex service, several local application processes may exist with different levels of complexity. For example, a given local application process may not take into account the existing VIA, or for each new frame to be displayed, delete the existing VIA and create a brand new one. A more clever local application process may, on its own, take care of the previous VIA and express through the DTAM service interface the sole modification of the VIA. Fascicle VII.7 - Rec. T.564 8 It is up to the Administrations concerned to define all the details of the local application process to communicate through the DTAM service, which supports the local application process. 8 Use of lower layer services The use of lower layer services is specified in Recommendation T.101. 9 General structure of the VIA 9.1 General data structure The following list is a basic set of requirements for the properties of a general data structure handled by the videotex interworking gateway. Videotex interworking is an application profile on top of DTAM and the videotex interworking architecture (VIA) is in line with the general structuring principles defined in Recommendation T.400. The VIA consists of a document profile, an operational profile and five data structures: - a specific layout structure: the display structure; - four operational structures which are used to carry: 1) the data entry structure; 2) the application control memory structure; 3) the administrative structure; 4) the special terminal facilities structure. Note - Only one operation profile is used for the four concerned operational structures. The data structure is composed of structure elements (SE) which can be manipulated independently as long as the protocol and other dependency rules are observed. The state of the VIA is determined by the states of all the elements of the VIA and the relationship between them. The station of the VIA expresses the current state of communication between the two partners. Manipulations of the structure elements of the VIA are specified as VIA operations and mapped to DTAM service elements. 9.2 Attributes The categories of SE attributes are: a) identification attributes which specify the type of the SE and identify individual SE; b) application defined attributes which are only meaningful for the videotex interworking architecture; c) specific attributes which depend on the SE type; d) default-value attributes which specify values to be used in identified SE types at lower level in the hierarchy; e) reference attributes which specify the relation between SEs. 9 Fascicle VII.7 - Rec. T.564 9.2.1 Identification attributes The identification attributes are the object type and object identifier attributes defined in Recommendation T.412 and in Recommendation T.441 (resp. Annex A to Recommendation T.541). Fascicle VII.7 - Rec. T.564 10 9.2.2 Application defined attributes Application defined attributes are attributes specified within this Recommendation for the structure elements of the VIA, with non═equivalent attributes within the T.400 Series of Recommendations. They are either mapped to the attribute "application comments" specified in Recommendation T.412 (for attributes pertaining to the display structure) or mapped on the "application defined attribute list" specified in Recommendation T.441 (for attributes pertaining to one of the four other VIA data structures). The mapping is specified in Recommendation T.504 or in Recommendation T.541 respectively. 9.2.3 Specific attributes These attributes are depending on the SE-type. Examples of specific attributes are attributes specifying the position or the dimension of the text. These attributes are defined in Recommendation T.412. 9.2.4 Default value attributes Since no generic structure, neither object class specification, nor styles are used for the VIA, the values of defaultable attributes may only be derived from either standard default values specified for the VIA (in a relevant CCITT Recommendation) or from a default value list. A default value list may only be used at the highest level of hierarchy in a given data structure. Therefore, to determine the value of an attribute classified as defaultable the priority order is: 1) attribute values specified explicitly in the attribute list of the SE itself; 2) attribute values specified in the "default value list" attributes of the SE situated at the highest level of hierarchy in the considered data structure; 3) the default value derived from the document profile (see Recommendation T.504) or from the operational application profile (see Recommendation T.541); 4) the default value defined in Recommendation T.412 or Recommendation T.441 (resp. Annex A to Recommendation T.541). 9.2.5 Reference attributes Reference attributes specify the relationships between the SEs aside from the tree-structure. Reference attributes are specified in Recommendation T.441 (resp. Annex A to Recommendation T.541). The use of the reference attribute is specified in this Recommendation. 9.3 General VIA operation The VIA data structure is partly initialized at the connection establishment time. A number of SEs are implicitly created (see Annex A). The VIA is then created and modified by a series of general VIA-operations on SEs. All the VIA operations provoke: - a modification of the local VIA; - the exchange of DTAM primitives specifying which VIA operations are to be performed on the remote VIA. Recommendation T.523 specifies the mapping of the general VIA operations onto the relevant DTAM operations and the rules for the use of the DTAM service. After reception of an indication primitive from the DTAM service the VIA is updated and the VIA operations are indicated to the local videotex service user. The general VIA operations to be performed on the SEs are: a) CREATE: the creation of an SE; b) DELETE: the deletion of an SE and all its subordinate SEs; c) MODIFY: the modification of attributes of an SE; Note - Use of MODIFY operation to add text to both content information attribute of text-unit and operational element content attribute is for further study. 11 Fascicle VII.7 - Rec. T.564 d) REBUILD: the deletion of an SE and its subordinates followed by the creation of a new SE replacing the previously deleted one. This is for further study. e) CALL MEMORY: the invocation of predefined or stored sequences of VIA operations. A DTAM service primitive addressing a particular SE has influence on the existence of that SE (CREATE, DELETE) or on the attributes of the SE (MODIFY). 10 Videotex structure The videotex structure consists of a document profile, an operational profile and the following structures: - The display structure (layout structure) It contains informations concerning the layout and informations to be displayed. In the VIA the display structure is represented by the DOCUMENT-SE and the subordinate SEs of the DOCUMENT-SE. - Four operational structures 1) The data entry structure It provides the user with a flexible means of entering data. It contains elements for describing the layout of fields, for storing data and for describing the reaction to various user inputs. It is represented in the VIA by the DATA-ENTRY-SE and its subordinate SEs. 2) The application control memory structure It is used to store VIA operations which can be repeatedly invoked. It is represented in the VIA by the APPLICATION-CONTROL-MEMORY-SE and its subordinate SEs. 3) The administrative structure It copes with informations such as accounting and identification and is represented in the VIA by the ADMINISTRATIVE-INFORMATION-SE and its subordinate SEs. 4) The special terminal facilities structure It is used to handle data necessary to set the terminal in a special state. This data is sent to the terminal before the actual "display data" is sent (e.g. character of dynamically redefinable character set). It is represented in the VIA by the SPECIAL-TERMINAL-FACILITIES-SE and its subordinate SEs. 10.1 Display structure 10.1.1 Overview of the display structure The display structure is concerned with the data to be displayed on the videotex terminal. The following paragraphs only describe the elements specific to the display structure. The text of a document to be displayed on a screen can be separated into various parts in order to: - distinguish between presentation units (such as areas on the screen) or logical units and the rest of the Fascicle VII.7 - Rec. T.564 12 screen; - use of different types of coding; - allow some parts of the screen to be protected or scrolled; - allow some parts of the screen to be updated independently from the rest of the screen and have a longer or shorter life than other parts. This separation introduces a subimage concept which allows different logical and independent areas to be recognized within the screen. These subimages can be: - updated independently; - coded independently; - organized in order to take care of application requirements. 13 Fascicle VII.7 - Rec. T.564 The subimage concept also allows: - to clearly separate data entry and display areas; - to compose a screen via a library of subimages; - to store subimages independently of the final position on the screen. The display structure consists of: - one DOCUMENT-SE; - one PAGE-SE describing the page structure which is used to display videotex frames; - one or more BLOCK-SEs subordinate to the page; - at most one content portion subordinate to each block. Figure 5/T.564 describes the hierarchy of the display structure elements. FIGURE 5/T.564 In the context of videotex interworking between gateways, a page is a rectangular area that correspond to the interchanged defined display area (DDA). A page is always a composite object. Blocks are immediately subordinate to a page. Blocks are rectangular areas. Block-size is restricted to be equal to the page. The use of block-size not equal to page is for further study. All constituents of the display structure conform the definitions of the document structures as specified in T.400 Series of Recommendations. The document application profile defined in Recommendation T.504 specifies details on the document profile and the display structure for the videotex interworking between gateways. 10.1.2 Application defined attributes This section identifies specific attributes used by the videotex interworking gateway which do not influence the layout process as defined in T.400 Series of Recommendations. These attributes have no direct equivalent in Recommendation T.412 and are mapped to the attribute "application comments". Fascicle VII.7 - Rec. T.564 14 10.1.2.1Write-access attribute This attribute is associated with each SE. The specification of this attribute is valid for all structures of the VIA. Its value is used to control the independent manipulation of the SE by any of two communicating hosts (local and external), specifying which host may, at any time: - modify the attributes of the SE; - delete or create subordinates SEs. This attribute also specifies the way how the write access may be transferred between the two hosts. This attribute is introduced for further structuring and controlling of the dialogue. This is for further study. 10.1.2.2Display-indication This attribute identifies if the block is to be displayed or not. It may take the value "mandatory" or "optional". If the value "mandatory" is selected, then the block is to be displayed, even if the user types ahead. If the value "optional" is selected, then the local host may decide not to display the block when the user types ahead. All "mandatory" blocks within the page must be displayed. 10.2 Data entry structure 10.2.1 Overview of the data entry structure The data entry structure is used to represent the data entry function. This function is some- times also referred to as data collection function. It allows for a controlled entrance of user suppled information in a truly distributed environment between the local and external hosts. In order to prevent exchange of data through the network for each elementary action of the user, several dialogue steps have to considered between the local and external host: a) In the first dialogue step, the external host defines a data entry program which describes all the actions the local host must follow when the user enters data. This data entry program contains the description of the form, i.e. the description of the different areas of the screen where entry will be performed. It also contains the reactions to user's inputs the local host has to follow. These reactions, called rules, contain e.g. the list of allowed character, the type of echo to be performed, the list of possible commands, etc. Moreover, a guidance message, called prompts, may be associated with each field. Theses messages are displayed each time the cursor reaches or leaves the corresponding field in order to give to the user some information about the filling of the form; b) When the local host then receives the run (in the case of duplex mode) the local host immediately sends it back to external host. It executes the defined data entry program till encountering an event which provokes the termination of the entry. This events must be one of the termination reasons defined by the external host and correspond either to a valid user command or to the running out of a time out or to the entire filling of a field. The termination reason is reported back to the external host as the second dialogue step. According to the regulations of the videotex service at the local host side, the report may or may not contain the data entered by the videotex user. 10.2.2 Data entry structure description (see Figure 6/T.564) The data entry structure consists of: 15 Fascicle VII.7 - Rec. T.564 a) one DATA-ENTRY-SE; b) subordinate to the DATA-ENTRY-SE: - zero, none or more FIELD-SEs; - one DATA-ENTRY-PROGRAM-SE; - one or more RULES-SEs; - zero, one or more PROMPT-SEs; - one RESULT-SE; Fascicle VII.7 - Rec. T.564 16 c) a single content portion subordinate to a FIELD-SE; d) a single content portion subordinate to RESULT-SE; e) one or more DATA-ENTRY-SUBPROGRAM-SEs subordinate to the DATA-ENTRY--PROGRAM-SE; f) a single content portion subordinate to a PROMPT-SE. FIGURE 6/T.564 10.2.3 Modes of communication Two modes of communication between local and external host are defined: - alternate mode; - duplex mode. The communication between local and external host may be based on the alternate mode, on the duplex mode, or on both modes. If the communication is based on the alternate mode, the local host should support data entry type 1, type 2 and type 3. If the communication is based on the duplex mode, the local host should support data entry type 4. If the communication us based on both modes, the local host should support all types of data entry. The mode of communication is negotiated in the DTAM association initialization phase. Details are specified in Recommendation T.523. 10.2.4 Types of data entry The four different types of data entry program which have been identified, are corresponding to different types of applications and different characteristics of fields: a) Type 1 - Information retrieval This type makes use of a single implicit information retrieval field which is always present when data entry 17 Fascicle VII.7 - Rec. T.564 type1 is selected. The position and dimensions of the field are determined by the lost host, generally corresponding to an area located in the bottom part of the screen. Consequently, non-specific FIELD-SE must be used and the reference- to-a-FIELD-SE attribute of the DATA-ENTRY-SUBPROGRAM-SE may be set to undefined or not be taken into account if defined. When the user has terminated the data entry, the Fascicle VII.7 - Rec. T.564 18 information which is sent back to the external host consists of the RESULT-SE which describes all the conditions encountered when the entry is stopped (termination reason, ...). The text associated with the termination reason, if any, is sent to the external host via the content portion associated with the RESULT-SE. b) Type 2 - Data collection This type generally corresponds to a form type of entry and makes use of one or more fields entirely defined by the external host. Moreover, in some videotex services, a single implicit information retrieval field may also be associates with this entry type to enter a videotex command (see 10.2.12.8.1). When the user has terminated the data entry, the information which is sent back to the external host are the content portions associated with the fields and the RESULT-SE. The text associated with the termination reason, if any, is sent to the external host via the content portion associated with the RESULT-SE. c) Type 3 - Data entry "on the fly" This type makes use of a single implicit field which is always present when data entry type 3 is selected. The position and dimensions of this implicit field are determined by the cursor position after the display of the information sent by the external host. Consequently, no specified FIELD-SE is used and reference-to-a- FIELD-SE attribute of the DATA-ENTRY-SUBPROGRAM-SE may be set to undefined and should not be taken into account when defined. The size of the field is fixed to 128 bytes. When the user has terminated the data entry, the information which is sent back to the external host consists of the RESULT-SE. The text associated with the termination reason, if any, is sent to the external host via the content portion associated with the RESULT-SE. d) Type 4 - Duplex data entry This types makes use of a single implicit field which is always present when data entry type 4 is selected. The position and dimensions of this implicit field are determined by the current cursor position. Consequently, no specific FIELD-SE is used and reference-to- a-FIELD-SE attribute of the DATA-ENTRY- SUBPROGRAM-SE may be set to undefined and should not be taken into account when defined. The size of the field is fixed to 128 bytes. When the user has terminated the data entry, the information which is sent back to the external host consists of the RESULT-SE. The text associated with the termination reason, if any, is sent to the external host via the content portion associates with the RESULT-SE. 10.2.5 DATA-ENTRY-SE This is the SE at the highest level of the data entry structure. Only one DATA-ENTRY-SE may be defined at a given time. 10.2.6 DATA-ENTRY-PROGRAM-SE This SE is subordinate to the DATA-ENTRY-SE. At a given time, one and only one DATA-ENTRY- PROGRAM-SE may be subordinate to the DATA-ENTRY-SE. A data entry program performs a data collection function on a form. A form corresponds to a screen structured into none, one or more fields where the user may enter data. The following attribute is mapped to the reference attribute defined in Recommendation T.441 (resp. Annex A to Recommendation T.541). 10.2.6.1First-subprogram This attribute is set by the external host to indicate to the local host the reference to the first data entry subprogram to be executed. However if the local host is not able to start with the indicated first subprogram the local host may fall back to process the subprograms in the natural order of the SE-identifiers. The application defined attributes of the DATA-ENTRY-PROGRAM-SE are the following: 10.2.6.2Data-entry-type This attribute is specified by the external host to indicate which interpretation the local host has to perform in order to be able to support the entry. This attribute may take the value type 1, 2, 3 or 4. The value indicates which type of data entry has to be performed. 19 Fascicle VII.7 - Rec. T.564 Remark on the control of the user input In the general situation of an international videotex interworking the following attributes, specified to allow local hosts to control the users' input, may not be supported by some local hosts. In these cases no checking of the relevant attributes will be performed by the local host. 10.2.6.3Allowed-characters-for-a-keyword-access-command This attribute set by the external host indicates whether the list of characters represents the allowed or forbidden characters. Possible values:Yes: means allowed characters in the list; No: means forbidden characters in the list. This attribute is not taken into account if the D1 d command is disabled. 10.2.6.4Character-list-for-keyword-access This attribute set by the external host contains a list of allowed or forbidden characters for keyword access. The list is encoded according to T.51 plus "space". This attribute is not taken into account if the D1 d command is disabled. 10.2.6.5Max-length-keyword-access This attribute set by the external host specifies the maximum length of the input field for keyword access. 10.2.6.6Allowed-character-for-a-direct-access-command This attribute indicates whether alphabetic characters (a, b, ... z) may be used inside a direct access command. This attribute is defined by the external host but not taken into account if the D1 b command is disabled. Possible values:Yes: means alphabetic characters are allowed; No: means alphabetic characters are not allowed. 10.2.6.7Max-length-direct-access This attribute set by the external host specifies the maximum length of the direct access input. 10.2.7 RESULT-SE The RESULT-SE is subordinate to the DATA-ENTRY-SE. At a given time only one RESULT-SE may be subordinate to the DATA-ENTRY-SE. The following attribute is mapped to the reference attribute defined in Recommendation T.441 (resp. Annex A to Recommendation T.541). 10.2.7.1Last subprogram This attribute set by the local host reflects the reference to the data entry subprogram currently being executed when a termination reason was detected. Some local hosts may not be able to update this attribute when the user aborts the filling of the form. Consequently, this attribute may be left undefined when the termination reason is D17. The application defined attribute of the RESULT-SE is the following: 10.2.7.2Termination reason This attribute set by the local host indicates the reason which provoked the termination of the data entry. This reason may be either a valid command, the entire filling of the field or the expiration of a time out. 10.2.8 Result content portion This content portion set by the local host and reported in some cases to the external host if the termination reason attribute of the RESULT-SE corresponds to a command with parameter: D1. The result content portion makes use of the attribute operational element content type (see Recommendation T.441, resp. Annex A to Recommendation T.541), as follows: Fascicle VII.7 - Rec. T.564 20 10.2.8.1Type of coding This attribute is set by the local host and specifies the coding used to represent the content and may take one of the following values: - T.50 (IRV); - T.51 "plus space". The result content portion makes use of the attribute operational element content (see Recommendation T.441, or Annex A to Recommendation T.541), as follows: 10.2.8.2Content information This attribute is set by the local host to report the text associated with the termination- reason attribute of the RESULT-SE, if any. 10.2.9 FIELD-SE A field is used to defined a subimage where user inputs are to be echoed. It is used by the local host for reporting to the external host user inputs. It may also be used by the external host to describe a subimage or to set initial data into an entry area. A FIELD-SE is subordinate to a DATA-ENTRY-SE. At a given time, several FIELD-SEs may be subordinate to a DATA-ENTRY-SE. The application defined attributes of the FIELD-SE are the following: 10.2.9.1Field layout This attribute specifies the layout characteristics of the field. A field is described as a sequence of rectangular areas called hereafter field-blocks. Each field-block is described by its position (X, Y) and its dimensions (DX, DY). Remarks on the use of system fields The system field facility is an optional function provided by a videotex service. A system field is a data collection field in which predetermined type of data is filled in by the videotex service or by the user. When using system fields in an international connection it has to be taken into account that a general user identification mechanism based on the ongoing work on ACSE and the use of association (D-INITIATE service) is for further study, and that the harmonization of the concerned type of data with other telematic services is still under study. It is up to the Administrations to decide to set up or not the system field facility. The implementation and use of the above system fields in international connections may be subject to legal restrictions (e.g. consumer privacy) that may be in effect nationally or internationally. Services which do not support the system field facility will ignore all the associated protocol items and consider all the system fields as normal data collection fields. The international availability of this data or parts of it may be subject to legal restrictions or restrictions imposed by users or Administrations. 10.2.9.2Field-type This attribute is set by the external host to indicate whether or not the field is a system field. A system field is a field that should be filled in by the local host system itself and not by the user. If this attribute has the value "0" then the field is to be completed by the user - i.e. a normal data collection field. A non-zero value indicates that (if possible) the local host should complete the field with system data as follows: 1 Country code 1a National telephone number 2 Subscriber No. 2a Co-user-suffix 2b User No. 3 Subscriber title 4 Subscriber name 5 Additional name 6 Street 21 Fascicle VII.7 - Rec. T.564