Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

On implementing the ISO virtual terminal protocol for a UNIX 4.2 BSD environment Ng, Steve Chi Ho 1988

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-UBC_1988_A6_7 N48.pdf [ 5.86MB ]
Metadata
JSON: 831-1.0051938.json
JSON-LD: 831-1.0051938-ld.json
RDF/XML (Pretty): 831-1.0051938-rdf.xml
RDF/JSON: 831-1.0051938-rdf.json
Turtle: 831-1.0051938-turtle.txt
N-Triples: 831-1.0051938-rdf-ntriples.txt
Original Record: 831-1.0051938-source.json
Full Text
831-1.0051938-fulltext.txt
Citation
831-1.0051938.ris

Full Text

O N I M P L E M E N T I N G T H E ISO V I R T U A L T E R M I N A L P R O T O C O L F O R A U N I X 4.2 BSD E N V I R O N M E N T By S T E V E CHI HO N G B.C.Sc.(Honours), University of Windsor, 1986 A THESIS S U B M I T T E D IN P A R T I A L F U L F I L L M E N T OF T H E R E Q U I R E M E N T S F O R T H E D E G R E E OF M A S T E R OF S C I E N C E in T H E F A C U L T Y OF G R A D U A T E STUDIES ( D E P A R T M E N T OF C O M P U T E R SCIENCE) We accept this thesis as conforming to the required standard T H E U N I V E R S I T Y OF BRITISH C O L U M B I A October 1988 © Steve Chi Ho Ng, 1988 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department The University of British Columbia 1956 Main Mall Vancouver, Canada V6T 1Y3 DE-6(3/81) Abstract Virtual terminal protocols provide remote terminal-oriented communications be-tween network users. They are designed to allow terminals and hosts on a hetero-geneous network to communicate without requiring one side to "know" the terminal characteristics handled by the other side. With the diversification of different types of terminals, there is a tremenduous interest in research and design of such protocols. In this thesis we consider the design and implementation of a virtual terminal pro-tocol, that is, the ISO V T P described by ISO documents DIS 9040 and DIS 9041. In particular, we implemented and tested the usefulness of the ISO V T P under the U N I X environment. We conclude that the ISO V T P is useful in the U N I X environment. However, several inconsistencies and incomplete information in the ISO documentation, that require further revisions by the standard committee, are identified. Furthermore, we compare the ISO V T P with other terminal protocols, such as A R P A N E T T E L N E T and C C I T T P A D Facility, pointing out their differences and short-comings. i i C o n t e n t s Abstract ii Contents iii List of Tables v List of Figures vi Acknowledgement vii 1 Introduction 1 2 The ISO Virtual Terminal Standard 6 2.1 Overview of Application Layer Structure 7 2.2 The Virtual Terminal Model 9 2.2.1 Mode of Operation . 11 2.2.2 Access Right 12 2.2.3 Type of Delivery Control 13 2.2.4 V T Profile 14 2.2.5 Display Objects 15 2.2.6 Control Objects 22 2.2.7 Device Objects 26 2.3 The Vir tual Terminal Service 30 2.4 The Vir tual Terminal Protocol 39 3 The ISO V T P Implementation 46 3.1 The ubcVTP Implementation Model 47 3.2 The Virtual Terminal Model for ubcVTP 50 3.3 Local Mapping Function 57 3.3.1 The Server-LMF 58 ii i 3.3.2 The Client-LMF 65 3.4 The Virtual Terminal Protocol Machine 68 3.5 A S N . l Encoding and Decoding 71 3.6 Dummy A C S E and Presentation layer 73 4 Related Work 74 5 Conclusion 89 5.1 Summary 89 5.2 Possible improvement 91 5.3 Future Research 93 Bibl iography 96 Appendix 101 A u b c V T P Private Profile 101 B A S N . l Definitions of P D U s for V T P 103 C State Transit ion Diagrams 123 iv L i s t o f T a b l e s 2.1 Primary Display Object VTE-parameters 18 2.2 Addressing VTE-parameters 19 2.3 Repertoire VTE-parameters 20 2.4 Emphasis and Colour Assignment VTE-parameters 21 2.5 Control Object VTE-parameters 23 2.6 Semantics and Defaults for Parameter CO-size 24 2.7 E C H O Control Object VTE-parameters 26 2.8 Device Object V T E parameters 27 2.9 Basic Class Virtual Terminal Services (Kernel set) 30 2.10 Update Operations of Display Object 32 2.11 Predefined Special Coordinate Values 33 2.12 Optional Basic Class Virtual Terminal Services 37 2.13 V T Service Primitives to PDUs Mapping 41 3.1 Mapping Between Terminal Specific and V T Abstract Operations . . . . 63 3.2 Size of Input and Output Files for A S N . l - C Compiler 72 4.1 T E L N E T Commands and Options 77 4.2 P A D Parameters (X.3) 79 B . l Error code for A S N . l defintion of the V T P PDUs 105 v L i s t o f F i g u r e s 1.1 The V T Model 3 2.1 Application Layer Structure (ALS) 8 2.2 Structure of ISO V T P with Respect to OSI Reference Model 10 2.3 A Typical A-mode V T Session 42 3.1 The ubcVTP Implementation Model 48 3.2 Relationship of pty to ubcVTP and Applications 60 3.3 Structure of the Keymap 61 3.4 Termcap isovt for the ubcVTP Implementation 64 vi A c k n o w l e d g e m e n t First, I would like to sincerely thank my supervisor, Dr. Gerald Neufeld, for his great interest, valuable suggestions, advice and guidance concerning the topic and my thesis. I am also grateful to Dr. Samuel Chanson for being my second reader. His comments and insights are appreciated. I would like to extend my appreciation to the department of Computer Science for financial support. To all my friends at the department, big thanks for all their kindness and the great times. Especially, I would like to acknowledge the following people: Jane Mulligan and Herbert Kreyszig for reading drafts of my thesis, Winston Gu for his technical assistance with the Bibliography, and Yueli Yang for supplying the A S N . l - C compiler. I would like to express my gratitude to Carlin Chao for her moral support, patience, and invaluable assistance. Finally, special thanks are to my wonderful parents and siblings for all their encour-agement and support during my graduate studies in Vancouver. v i i C h a p t e r 1 I n t r o d u c t i o n With the advent of heterogeneous computer networks, the need to access diverse computer systems through a single terminal has increased. Usually, in order to be able to use a terminal from one vender with a host from another vendor, a special host software package must be built to accomodate the foreign terminal. Consider a network with N types of terminals and M types of hosts. For complete connectivity, each host type must contain a software package for handling each terminal type. In the worst case, M x N packages must be developed. Furthermore, if a new type of host is acquired, it must be equipped with N new terminal I /O packages. If a new type of terminal is acquired, each host must be equipped with new 1/0 software, for a total of M new packages. Clearly, this is impractical and it discourages multivendor interoperability. Terminal protocols were designed to tackle this problem. Two basic approaches have emerged. One approach attemps to parameterize the differences between terminals. 1 CHAPTER 1. INTRODUCTION 2 The protocol is used by the host to set and read the various terminal parameters to the requested values. For example, parameters are defined for the terminal speed, character that terminates a line, character that deletes a line, etc.. Different terminals will have a different set of values for these parameters, since each of them describes one physcial characteristic of the real device. Examples of this approach are CCITT ' s Packet Assembler/Disassembler (PAD) facility as specified in X . 3 , X.28 and X.29, and Datapac's Interactive Terminal Interface (ITI) [29]. One of the major drawbacks for this approach is the lack of flexibility. As more complex terminals are used, more and more parameters must be defined to deal with them. Early versions of X.3 had 12 parameters and this number has grown to 22 in the latest recommendation. A n early version of ITI had more than 20 parameters and has grown to over 50. The second approach is to define a Virtual Terminal (VT) . A virtual terminal is an abstract representation of a real terminal, complete with various abstract operations. This abstract representation may not have a direct relationship with the local terminal's characteristics. For example, a virtual terminal that supports colour does not mean the local device must be a colour terminal. Because of this, mapping functions must be provided to translate the abstract format into the local representation. Figure 1.1 depicts this model. The terminal side of a connection maps the ouput of its terminal into the V T format for transmission to the host. The host then maps the V T format into its local form. The same procedure is performed for output from host to terminal. CHAPTER 1. INTRODUCTION 3 t e r m i n a l local local ^mapping V T V T • mapping I function network function open system A open system B Figure 1.1: The V T Model This method reduces the M x N problem to a Af x 1 problem because each host on the network needs to support only one type of terminal, the V T . This approach has proven to be more flexible since the support of a new type of terminal is a matter of defining a new V T and implementing a new mapping module. The A R P A N E T T E L N E T protocol was the first Virtual Terminal Protocol(VTP). T E L N E T (acronym for TELecommunications NETwork) is a very simple protocol in-tended for use by scroll mode terminals. However, as complex terminal and personal computers use grew, scroll mode terminal became out-of-date and T E L N E T has not proven flexible enough to support the new terminal technology. Besides the Americans, Europeans have long been active in defining virtual terminal models that can be used in a wider range of applications. These include several inter-national organizations such as European Informatics Network (EIN), Euronet, IFIP, national organizations such as the Belgian University Network, the German PLX Net-work, the French Cyclades Network and the French user association I N F O R E P [29,9]. The European investigations into V T P have made two major contributions : (i) a well-defined virtual terminal, and CHAPTER 1. INTRODUCTION 4 (ii) the development of a model for attentions or interrupts. Both are crucial in a general V T P . This thesis describes the latest development in V T P by the International Standard Organization (ISO). The V T P standard, including Draft International Standards (DIS) 9040 [46] and 9041 [49], describes the Basic Class V T service and protocol for character-oriented devices such as video display terminals. This work is heavily based on the Generic Virtual Terminal Service and Protocol developed by the European Computer Manufacturers Association ( E C M A ) [4]. ISO V T P developement has already gone through several stages, the one described in this thesis, is the second version of DIS 9040 and DIS 9041 published in December, 1987. The first version was published in Apr i l , 1987. DIS 9040 describes the model of the V T protocol and the service facilities that the protocol user can access, it also describes how these facilities are used and interpreted. DIS 9041 is the protocol specification. It describes the Protocol Data Units (PDUs) sent between implementions and the actions they should perform. This Basic Class V T P is intended to support line mode, scroll mode and page mode types of terminal devices. For more sophisticated devices such as data entry terminals, a Form Class V T P is defined as an addendum to the protocol standard. However, Form Class V T P will not be discussed in this thesis and is left for future study. CHAPTER 1. INTRODUCTION 5 In order to test the usefulness and the praticality of V T P , an implementation of a subset of ISO V T P was done on the U N I X 1 operating system. This implementation is based on the second version of DIS 9040 and DIS 9041. The implementation model as well as some local concerns and solution techniques are described in detail in the thesis. In addition, some of the ambiguity and inconsistency that we found in the standard are identified. We hope that our experience will be helpful to others who plan to implement V T P in the near future. The rest of the thesis is structured in the following manner: • Chapter 2 presents the essence of the ISO V T P specifications in particular the V T model. • Chapter 3 describes the local implementation of ISO V T P , highlighting our own virtual terminal model that is more suitable for applications in the U N I X envi-ronment. • Chapter 4 discusses some of the related work. Of greatest interest is the compar-ison between ISO V T P and A R P A N E T T E L N E T and C C I T T P A D Facility. • Chapter 5 concludes up by giving a summary and some suggestions on areas that deserve further research. 1UNIX is a registered trademark of AT&T C h a p t e r 2 T h e I S O V i r t u a l T e r m i n a l S t a n d a r d In this chapter, the ISO Virtual Terminal standard is described. The material specified in the two volume standard is quite bulky and not very well organized. Thus, this chapter is organized in the following way, aiming to help understand the original material easier: • Section 1 gives an overview on the Application layer structure and identifies the role of ISO V T standard within the OSI achitecture, • Section 2 describes the virtual terminal model that defines the objects to be manipulated, • Section 3 describes the virtual terminal service that defines the operations which may be applied to the objects, and • Section 4 describes the virtual terminal protocol that defines the legal sequences in which the virtual terminal services can be performed. 6 CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 7 2.1 Overview of Application Layer Structure The International Standard Organization(ISO) has defined a seven layer architec-ture called Open System Interconnection (OSI) reference model to facilitate the com-munication of computer systems within a heterogeneous networking environment [48]. This reference model provides a common basis for the co-ordination of the development of protocol standards, as well as allowing existing ones to be placed within a common framework. Among these seven layers, the Application layer is the highest and it pro-vides the sole means for application processes (APs) to access the capabilities available from the OSI Environment (OSIE). Entities in the Application Layer or Application Entities (AEs), represent the set of communicating functions used for interworking in the OSIE, are made up of a collection of application service elements (ASEs)(see Fig-ure 2.1), each of them is defined by a set of service and protocol standards. These ASEs accept and process requests for provision of some OSI capabilities or provide the appli-cation processes with some responses as a result of stimulus received from the OSIE. The ISO Virtual Terminal Protocol (VTP) is one of these ASEs. It provides remote terminal access capability on a heterogeneous network through the OSIE. Examples of other ASEs are the File Transfer, Access and Management (FTAM) protocol, the Job Transfer and Manipulation (JTM) protocol and the Message Handling Service (MHS). One special type of A S E , the Association Control Service Element (ACSE) facili-CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 8 Presentation Session Transport Network Data Link Physical Figure 2.1: Application Layer Structure (ALS) tates other ASEs to working together. It provides basic facilities for the control of an application association (analogous to connection in lower layer) between two applica-tion entities that communicate by means of a presentation connection. Although the terms C A S E and SASE have been used often in the past, today, only the term A S E is used. A C A S E , or Common A S E , represented the common functions needed for different ASEs between computers. SASE, or Specific A S E , was used to differentiate F T A M from V T P and other kinds of application protocols. To date however, no objective criteria has been established for distinguishing a C A S E from a S A S E . For a more detailed description on application layer structure, see ISO D P 9545 [47]. Roux [50] also gave a very good overview of this topic. In the ISO V T P model, a V T user comprising an application process gains the AE2 CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 9 capability of accessing resources on remote system through the service provided by the VT-entities ( V T service or V T S ) . In turn, this VT-entity uses the services provided by A C S E and Presentation Layer to effect the communication with the peer VT-entity. It is necessary to understand that a VT-user, in this context, is not a human user or an end user's application program. It is a local mapping process that maps a vendor supplied terminal interface onto a V T service. Figure 2.2 depicts this relationship. 2.2 The Virtual Terminal Model Before communication can take place between two VT-entities, a Virtual Terminal Environment (VTE) must be agreed upon on between two VT-users. The V T E consists of a set of V T E parameters, each describing some specific aspect of the environment. These include the model describing the virtual terminal and the types of service that are available on a V T association. A complete and consistent set of V T E parameters is called a /u / / -VTE. A virtual terminal is modeled as three kinds of abstract objects, each of them is defined by a set of V T E parameters. They are • display objects which define how graphical information is represented, • control objects which define how unstructured information such as signal and control information, is represented, and CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD terminal y — < local mapping process 5 VT service primitives \ 7 VT- entity A C S E P-entity o o o VT protocol local mapping process VT service primitives association control protocol presentation layer protocol VT- entity A C S E P-entity o o o open system A open system B Figure 2.2: Structure of ISO V T P with Respect to OSI Reference Model CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 11 • device objects which assist in the mapping of display objects to real devices. Before descriptions are given for each of these types of objects, some other aspects of the V T E have to be clarified in order to provide a better understanding of the nature of these objects, and the parameters that define them. 2 . 2 . 1 Mode of Operation The ISO virtual terminal can be operated in either of the two modes: asynchronous mode (A-mode) and synchronous mode (S-mode). A virtual terminal described in A-mode is intended to model the operation of an asynchronous terminal, such as D E C VT100 1 , which provides a two way simultaneous (full-duplex) dialogue between the two V T users. On the other hand, a S-mode virtual terminal provides a two way alternate (half-duplex) dialogue, thus modelling the operation of a synchronous terminal such as I B M 2 3270. The mode of operation also determines how many display objects exist in the V T E . S-mode has one display object and A-mode has two. Basic Class Virtual Terminal Protocol does not support more than two display objects. The mode V T E parameter contains the value for the mode of operation and must be agreed by both V T users at the time of establishing the association. 1 DEC and VT100 are both registered trademarks of Digital Equipment Corperation. 2 IBM is the registered trademark of International Business Machines. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 12 2 . 2 . 2 Access Right Access right is an abstract object representing permission to carry out some set of operations. Certain instances of display and control objects defined in the V T E are subject to access control, and only by holding the correct access right can a V T user update these objects. Two types of access rights are defined by the standard. The first type is a single reassignable access right called W A V A R (Write Access VARiable), whose ownership can be passed back and forth between the two V T users. A t any single moment, only the V T user holding this access right can update access controlled objects. This organization is best suited to represent the half-duplex nature of synchronous terminals, where the terminal user and the application program take turns to accessing the actual terminal, as represented by a single display object in S-mode. The second type is a pair of non-reassignable access rights called W A C I (Write Access Connection Initiator) and W A C A (Write Access Connection Acceptor) respec-tively. The V T user who initiated the V T association will own the W A C I access right while the one that accepts the connection will own the W A C A access right. This type of access control is typically used to describe the full-duplex nature of asynchronous terminals (A-mode) where one display object may be assigned the W A C I access right to model the terminal keyboard and the other one may be assigned the W A C A access right to model the terminal screen. Thus, the terminal side V T user can access the CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 13 keyboard display object, while the application side V T user is accessing the screen display object simultaneously. 2.2.3 Type of Delivery Control Data may be sent by a V T user at any time, but its delivery to the peer user is up to the remote V T implementation. Although this is usually acceptable, there are cases that a V T user may want to have explicit control over when these updates are delivered. For example, in A-mode, a V T user may want data to be delivered after a full line of text has been entered on the terminal. The V T standard has provided this mechanism by defining a V T E parameter called type-of-delivery-control. Three possible values are defined, they are no-delivery-control, simple-delivery-control and quarantine-delivery-control. No-delivery-control, the simplest case, means that a V T user can have no direct influence on when updates are delivered. This is the default value for the parameter. If the parameter has the value simple-delivery-control, either V T user can mark a point in the data stream to indicate that all updates before this point should be delivered to the peer user. Either V T implementation is still free to deliver updates to its user at anytime. Thus, updates could have been delivered at any time prior to the delivery point. The third alternative, quarantine-delivery-control, allows a V T user to restrict the CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 14 delivery of updates to its peer user, that is no updates are delivered until the sending V T user requests delivery. One of the side effects of this type of delivery control is net-effecting. Since updates are guaranteed not to be delivered until the delivery request is received, several updates may be combined into a single one to reflect the net effect of a series of updates. For example, if an input line is orginally transferred with a typing error, the user may correct the error and then request delivery. The peer user will only see the corrected input. For the last two types of delivery control, the initiating V T user may optionally request an acknowledgement of delivery from the peer user. 2.2.4 V T Profile Since a large number of parameters are required to completely define a V T E , ISO V T uses a profile to refer to a predefined set of values in order to reduce the amount of communication. The profile is also a place where semantics of display and control objects can be denned. Each profile is expressed in the B N F (Backus-Naur form) notation defined in the V T standard for describing V T E s and each is assigned a unique name. When a V T E parameter does not have explicit value defined in a profile, its default value wil l be used. A profile name may be specified by the initiator of a V T association and, depending on whether the negotiation service facility is in use, the V T E defined by that profile may later be replaced with another defined in another CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 15 profile, or have values of its individual V T E parameters modified. If no profile name is given at the time of estabilishing the association the default profile will be used. There are two default profiles, one for S-mode and one for A-mode, both of them are defined by the standard in DIS 9040. Profiles may also have arguments, allowing precise negotiation of only a few V T E parameters without requiring the complex negotiation service facility. There are also a set of registered profiles which are defined in the standard to contain some well known V T E s for different types of applications. Since a registration authority does not yet exist at the time of releasing the second verison of the standard, it is expected that these registered profiles will be transferred to the profile register when such an authority is established under the authority of ISO. When a profile definition is only known to the two communicating V T users, it is called a private profile. 2 . 2 . 5 Display Objects Display objects are the mechanism by which a terminal's screen and keyboard are modelled. They allow real events related to a specific terminal to be represented as abstract events on a virtual terminal. A display object is defined as either a one, two or three dimensional array of char-acter box graphic elements. A character box graphic element, including data displayed on a terminal screen and data given to an application program, is defined in the V T CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 16 standard as "an atomic element of a repertoire". This means, a character from some character set together with that character's attributes. The three dimensions of the display objects are named X , Y and Z, with X being the lowest order dimension. A set of array elements identified by a contiguous set of X coordinate values is called an X -array. Similarly, a set of X-arrays identified by a contiguous set of Y coordinate values is called Y-array, and a set of Y-arrays identified by a contiguous set of Z coordinate values is called a Z-array. In a typical display object, an X-array may represent a line, a Y-array may represent a page, and (if used) a Z-array may represent a group of pages (a document) on a terminal screen. At any given time, an array element is either empty or it contains a primary at-tribute value which indicates what character is currently being assigned to that position in the display object. Each array element also has a number of secondary attributes: the character set, emphasis, foreground colour, background colour and font. The last four are usually referred to as rendition attributes. For example, an array element may contain the ASCII character ' A ' with emphasis equals bold, foreground colour equals red, background colour equals white and font equals Geneva. A display object is also associated with a display pointer, a set of model attribute variables and a set of global attribute variables. The display pointer identifies the current position in the display object and in some cases, acts like a cursor on the virtual terminal. The set of global attribute variables consist of a value for each of the CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 17 secondary attributes. Each value is either "null" or an explicit value for this attribute selected from the set of available secondary attribute values in their corresponding VTE-parameter ( we will explain VTE-parameter in a moment). For example, if the VTE-parameter for foreground colour has the value black, red, green and blue 3, the possible value for the model attribute variable of foreground colour may then be selected from these four colours. The set of modal attribute variables is similar to the set of global attribute variables with one exception, that the character sets attribute is excluded. These two sets of attributes determine what secondary attributes should be assigned to an array element when a primary attribute is put into this array element. Their exact usage is described in section 2.3. Display Object V T E - p a r a m e t e r A display object is denned by assigning values to the V T E parameters associated with that object. Display object V T E parameters are divided into three levels: primary, secondary and tertiary. Primary parameters describe the characteristics of the display object. The secondary and tertiary parameters give finer details on the primary param-eters and their existence depends on the existence of the associated primary parameters. Some primary parameters have the type capability and they imply the existence of an associated assignment type parameters. Each of these assignment parameters is an 3each of the VTE-parameter for describing attributes is itself a list. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 18 ordered list of some possible values available for the secondary attributes of the display object. The maximum number of elements in each orderd list is specified in the asso-ciated capability parameter. Table 2.1 contains the primary parameters, their possible values and their defaults. Parameter Possible Value(s) Default display-object-name any character string none object-access-right WACI, WACA, or none WAVAR dimensions 1, 2, or 3 2 erasure-capability yes or no no repertoire-capability 1, . . . , JV 1 emphasis-capability 1,...,N 1 foreground-color-capability 1,...,N 1 background-color-capability l , . . . , i V 1 Table 2.1: Primary Display Object VTE-parameters The display-object-name parameter uniquely identifies the specific display object in the V T E . The object-access-right parameter governs which VT-user can update this dis-play object. The dimension parameter identifies the perspective of the virtual screen. The erasure-capability parameter controls whether elements in the display object may be erased. The repertoire-capability parameter indicates the number of character sets supported. The emphasis-capability parameter indicates the number of emphasis levels that are available. The foreground- and background-colour-capability parameters indi-cate the number of foregound and backgound colours that are supplied by the display CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 19 object. The secondary display object VTE-parameters are divided into several groups. The first group contains addressing parameters associated with each dimension defined in Table 2.1. The number of occurrences in this group of secondary parameters depends on the number of dimension defined. For example, if the display object is only two-dimensional, no secondary parameter exists for dimension Z. Table 2.2 contains the parameters, their values and defaults for dimension X . For dimensions Y and Z, x should be substituted by y and z in each parameter defined. Parameter Possible Value(s) Default x-bound unbounded, 1,.. . , N unbounded x-addressing no constraint, higher only, or not permited higher only x-absolute yes, no no x-window unbounded, 0,...,N if x-bound - unbounded default = 0 else default = x-bound Table 2.2: Addressing VTE-parameters The x-bound parameter indicates the upper bound of the dimension; graphical ele-ments written on the display object beyond this limit will be invalid. The x-addressing parameter indicates whether relative movement of the display pointer will be allowed in this dimension. For example, can the display pointer move forward and downward three element positions with respect to the current position on this display object? The CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 20 x-absolute parameter indicates whether direct movement of the display pointer will be allowed in this dimension. For example, can the display pointer move to the first row and the third column on this display object? The x-window parameter specifies the portion of the dimension, from the highest element updated and back, that an imple-mentation must store. In other word, it places a lower limit on the dimension where update operations may apply. The next group of secondary display object parameters is associated with the pri-mary display object parameter repertoire-capability. While repertoire-capability in-dicates how many character sets are supported, these two parameters (as defined in Table 2.3) give further specifications for each of the character sets. Parameter Possible Value (s) Default repertoire-assignment a character set designating escape sequence as defined in ISO 2022 [39] or the escape sequence for the transparent set as defined in DIS 9040 the set of graphic characters of the IRV of ISO 646 [40] (equivalent to 7 bits ASCII character set) font capability 1 , . . . , /V 1 Table 2.3: Repertoire VTE-parameters The repertoire assignment parameter identifies a particular character set using "a character set designating escape sequence" as defined in ISO 2022 [39]. The font-capability parameter indicates the number of different fonts that are available for the character set. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 21 Parameters concerned with emphasis and colour assignments make up the last group of secondary display object parameters. Table 2.4 contains these parameters as well as their allowed values and defaults. Parameter Value Default emphasis assignment an emphasis name as denned in ISO 6429 [34] "normal" if emphasis-capability = 1 foreground color assignment an colour name as defined in ISO 6429 [34] "device dependent" if foreground-color-capability = 1 background colour assignment an colour name as denned in ISO 6429 [34] "device dependent" if background-color-capability = 1 Table 2.4: Emphasis and Colour Assignment VTE-parameters The emphasis-assignment parameter lists all the possible emphasis values. For example, normal, bold, underlined, blinking are all possible values for this parame-ter. The foreground- and background-colour-assignment parameters list all the possible foreground and background colours such as black, red, green, etc., that are supported by the virtual terminal. For the default values "normal" and "device-dependent" the virtual terminal may use whatever level of emphasis or colour that is available on the real device. The only tertiary display object parameter is the font-assignment which is associated with the secondary parameter font-capability. Each instance of this parameter is a list of font names for the associated character set as denned by the secondary parameter CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 22 repertoire-assignment. Currently there is no ISO standard for fonts, thus the use of this parameter is left open for user-defined conventions. 2.2.6 Control Objects The next type of abstract objects that make up the virtual terminal is the control object(CO). A virtual terminal can have any number of control objects, each of them represents certain type of control information for the virtual terminal. Examples of control information include device on/off status, interrupts generated by function keys, and signals sent by light pen, mouse or sensor. Table 2.5 defines the V T E parameters for the control object as well as their possible values and defaults. The CO-name parameter uniquely identifies the control object in the V T E , the CO-type-identifier identifies the type of control object. If it has a value type of O B J E C T I D E N T I F I E R of A S N . l [38], the control object is either defined by the V T standard ( a standard control object) or defined in a registered profile. After the previously mentioned registration authority is established, the O B J E C T IDENTIFIER value will also be used to identify registered control objects. On the other hand, if the parameter contains character string value, the control object is a private one. The CO-access parameter indicates which V T user can access this control object, only the V T user holding the specified access right may update the content of this control object. If the parameter has a value of "not-subject-to-access-control", there is no constraint on CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 23 Parameter Possible Value (s) Default CO-name a character string none CO-type identifier either a value of ASN.l OBJECT IDENTIFIER type or a character string none CO-access not-subject-to- access-control WAVAR, WACI, or WACA not-subject-to-access control CO-priority normal, high, or urgent normal CO-trigger not selected, selected (irrelevent, if CO-access equals not-subject-to-access-control) not selected CO-category character, boolean, symbolic, integer, or transparent boolean CO-repertoire-assignment same as display object VTE-parameter repertoire-assigment (relevent only if CO-category equals character) same as display object VTE-parameter repertoire-assignment CO-size 1,...,N depends on CO-category depends on CO-category Table 2.5: Control Object VTE-parameters when or which V T user may update the control object. The CO-priority parameter indicates the update priority of this object relative to updates on other objects. The V T service provider wil l always service the updates in the order of "urgent", "high" and "normal", where urgent has the highest priority and normal the lowest. The CO-trigger parameter indicates whether this control object has the tigger charateristic. If the control object has the trigger charateristic, update to this object will cause updates to other objects which have been held up by the service provider, to be delivered to CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 24 the user. This is often referred to as implicit delivery 4. In S-mode, it also implies a transfer of the W A V A R access right ownership to the peer user. The CO-category and CO-size parameters identify the type and maximum size of the control object content. The appropriate value for CO-size depends on the value of CO-category. Table 2.6 contains the defaults and initial values of CO-size for each of the categories. CO-category semantic for CO-size default inital value character maximum length of character string 16 null boolean maximum number of boolean values 16 false for all values symbolic maximum number of distinct values 255 null for all values integer maximum value of integer value 65535 0 transparent maximum number of bits 16 0 for all bits Table 2.6: Semantics and Defaults for Parameter CO-size Except for those of type Boolean, a control object contains a single unit of in-formation. For example, a single character string, a symbolic value, an integer or a transparent (uninterpreted) bit string. When the control object is of type Boolean, it may contain one or more Boolean values and each value is addressed by its numeric position in the ordered list. The CO-repertoire-assignment parameter identifies the 4The opposite, explicit delivery, means the delivery is explicitly requested by the VT-user using the delivery control services. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 25 character set for the control object when CO-category is character. Since most of the time, control information is very specific to applications and real devices, and cannnot be adequately modeled by updates to the display object, the control object provides a solution to this problem. However since any number of control objects can be defined to represent nearly any kind of control information, it is very difficult to find a common way to represent all of their meanings. Thus, the V T standard does not provide a mechanism for specifying control information semantics. Currently, three alternatives are suggested to make control object semantics known to both communicating parties. The first is to describe the meaning and usage of a control object in a V T profile. The second is to register the control object definition with the international registration authority (make it well-known to everyone). The last one is simply make the semantics known to both V T users "by means outside the scope of the V T standard" [46]. At this moment, there is still no registered control object defined, but a standard control object, called ECHO control object, is defined in DIS 9040. This control object is mainly used in A-mode to allow a remote application to control echoing in the local terminal. Its structure is defined in Table 2.7. Basically, this control object acts like a switch to tell the local V T user when and when not to echo input updates on the terminal screen. According to the standard, the initial value of the E C H O control object is "false", that means no local echoing should be performed when V T communication starts. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 26 Parameter Value Default CO-name VT-B-CO-EHCO none C O-type-identifier vt-b-sco-echo none CO-access not-subject-to-access-control none CO-priority normal • none CO-trigger selected, not-selected selected CO-category boolean none CO-size 1 none Table 2.7: ECHO Control Object VTE-parameters 2.2.7 Device Objects The third and final kind of object in the V T E is the Device Object. A virtual terminal can have mulitple device objects, each of them provides V T users with a mechanism for specifying certain real device characteristics to assist in mapping display objects to and from the real device. They are especially useful when two dissimilar real devices are associated with the same display object, such as when a terminal is attached with a printer. The primary difference between the device object when compared with the display and control objects, is that it cannot be directly updated by V T users. The V T standard does not provide any update operations on the device object, thus their characteristics (the V T E parameters that describe them) can only be modified by negotiation facilities (we will discuss negotiation in the next section). Table 2.8 contains the device object V T E parameters together with their possible values and defaults. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD Parameter Possible Value Default device-name a character string none device-default-co-access not-subject-to-access-control, WAVAR, WACI, or WACA not-subject-to-access control device-default-co-trigger selected or not-selected not-selected device-default-CO-initial-value true or false false for all boolean values device-repertoire assignment same as display object repertoire-assignment same as display object repertoire-assignment device-font-assignment same as display object font-assignment same as display object font-assignment device-emphasis-assignment same as display object emphasis assignment same as display object emphasis assignment device-foreground-colour-assignment same as display object foreground-color-assignment same as display object foreground-color-assignment device-background colour-assignment same as display object background colour assignment same as display object background-colour-assignment device-minimum-x-array-length 1,...,N none device-minimum-y-array-length 1,...,N none device-control-object a list of character string, each of them is a control object name none device-display-object a character string none device-termination-length a list of tuples <event,event-id> where event is of type footnotesize ASN.l ANY and event-id is a nonezero positive integer none; if absent, no explicit termination condition is defined device-termination-timeout a tuple < T, E, event-id > where T and E are positive integers specifying a timeout of T(10 * *E), and event-id is a non-zero positive integer none; if absent, no timeout applies (equivalent to T = 0) Table 2.8: Device Object V T E parameters CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 28 The device-name parameter uniquely identifies the device object in the V T E . The device-default-CO-access and device-default-CO-trigger parameters identify the charac-teristics of the default control object associated with this device object. Their meanings are identical to the corresponding CO-access and CO-trigger control object parameters. This control object is pre-defined as having Boolean type of size eight and can be up-dated (although its associated device object cannot) through the name of its associated device object. Although the semantics for this control object is not defined in the stan-dard, one of the Boolean values has been widely used in registered profiles to represent the terminal's on/off status. The device-default-CO-initial-value parameter gives the initial value to this default control object. The device object assignment type parame-ters have the same meanings as their corresponding display object assignment parame-ters. They are defined to provide mapping guidelines between attributes supported by display object and those supported by the real device. For example, a display object may support four foreground colours such as black, red, green and yellow. A device ob-ject foreground colour assigment may be black, dark grey, light grey and white since the real device is a monochrome monitor. While x-bound and y-bound display object pa-rameters set the upper limit of line and page lengths for the virtual terminal, the device-minimum-X-array-length and device-minimum- Y-array-length parameters set the lower l imit 5 . The device-control-objects and device-display-object parameters identify a list of 6The meaning of this lower limit is different from that for the display object update-window parameter. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 29 control objects and a display object that are associated with this device object. Thus logical links are set up automatically between objects within the V T E . The three ter-mination type parameters specify a set of conditions in which the local V T user should cause notification of previous updates to the peer V T user. In other words, all previous updates that are being held up by the service provider should be delivered to the peer V T user upon recognising these conditions. The device-termination-event-list specifies a set of termination conditions which may be anything ranging from a "character" being entered or a function key being depressed, to a flag being set. Since the standard does not define the nature of these events, their semantics again, must be specified in the profile. The device-termination-length parameter specifies the number of updates to the display object's array elements updates after which this termination condition should occur. The device-termination-timeout parameter specifies a time interval after which termination condition should occur. Optionally, a termination control object (TCO) can be defined, as specified by the device-termination-control-object parameter, to be associated with this device object. When a termination condition occurs, the event-id associated with the condition will be written onto the T C O . Thus, a "reason code" can be passed to the peer user, identifying the cause for the delivery of updates. It places a constraint on the real device that is going to support the virtual terminal, while the previous one is used to control the update operations on display object. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 30 2.3 The Virtual Terminal Service The interaction between the V T user and its service provider takes the form of passing service primitives which convey information by using service parameters. What services are available for a V T user at an association depends on the mode of operation and the functional units selected. Table 2.9 lists the Basic Class Virtual Terminal services that are always assumed on a V T association. Facility Service type Establishment VT-ASSOCIATE confirmed Termination VT-RELEASE confirmed VT-U-ABORT non-confirmed VT-P-ABORT provider initiated Data Transfer VT-DATA confirmed Delivery Control VT-DELIVER non-confirmed VT-ACK-RECEIPT non-confirmed Access-right VT-GrVE-TOKENS non-confirmed Management VT-REQUEST-TOKENS non-confirmed Table 2.9: Basic Class Virtual Terminal Services (Kernel set) Like all OSI service definitions, each service is expressed in terms of a group of primitives and parameters [37]. The number of primitives associated with a service depends on the type of service. A confirmed type service has four primitives: request, indication, response and confirm, a non-confirmed type service has two: request and indication, and provider initiated type has only one: indication. The first service listed, V T - A S S O C I A T E , is used to establish a V T association and CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 31 to define a virtual terminal for that association. Several important pieces of information such as mode of operation, functional units and initial owner of W A V A R access right if S-mode is in use, must also be specified when a user initiates an association. The service parameter, functional-unit, is a value used to indicate what extra services or capabilities should be available on a V T association. Possible values for functional-unit are Switch Profile Negotiation, Switch Profile and Multiple Interaction Negotiation, Negotiated Release, Urgent Information Exchange and Break. The next three services are all used to terminate an association. V T - R E L E A S E provides an orderly release with no loss of data that may be refused by the peer V T user if the Negotiated Release functional unit is selected at the time of establishing an association. V T - U - A B O R T may be invoked when a V T user wishes to abruptly terminate an association, in this case, the peer user cannot refuse the termination. V T -P - A B O R T is issued by the service provider itself when it detects an error condition such as association terminated by the lower layer. Either of the abort services may result in user data being lost. The next service in Table 2.9, V T - D A T A , conveys data between two V T users. The exact format of data is a list of one or more updates to either display or control objects. As was mentioned earlier, the local mapping function is responsible for converting terminal specific information into these updates for the abstract V T objects. Display object updates express operations on the display object such as entering CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 32 characters, moving the display pointer, changing the attribute assoicated with a set of array elements, or erasing the contents of a set of array elements. Table 2.10 contains these operations and their required parameters. The first four are macro operations Operation Parameter (s) Next X-array none Next Y-array none Previous X-array none Previous Y-array none Pointer-relative p, q, r each is an offset relative to the current pointer's coordinate Pointer-absolute an absolute pointer's coodinate or one of the special values defined in Table 2.11 Attribute attribute-id attribute-value attribute-extent Text primary-attribute-value Repeat Text finish-address primary-attribute-value-string Erase erase-extent reset attribute Table 2.10: Update Operations of Display Object which do not require any parameters. They are used to move the display pointer to the beginning of next line, next page, previous line and previous page. The next operation, pointer-relative, is used to move the display pointer to a new position by specifying a coordinate offsets with respect to the pointer's current position. The last addressing operation, pointer-absolute, is used to move the display pointer to a new position by specifying absolute coordinates. The absolute coordinates may be specified by having an explicit value for each coordinate declared or by selecting one of the special coordinate values as defined in Table 2.11. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 33 Special Coordinate value Meaning current the current position of the display pointer start the first position on the first line of the first page start-Y the first position on the first line of the current page start-X the first position ont he current line of the current page end the last position on the last line of the last page end-Y the last position on the last line of the current page end-X the last position on the current line of the current page Table 2.11: Predefined Special Coordinate Values Following the addressing operations is the attribute operation which assigns sec-ondary attributes to one or more array elements. The attribute that is going to be set, is identified by the attribute-id. The number of array elements affected depends on attribute-extent which has possible values are global, address, and modal. Global sets all array elements as well as the global attribute variable for the display object to the specified attribute value. Address assigns the attribute value to all elements between two specified coodinates, and modal simply sets the modal attribute variable associated with the display object to the specified attribute value without updating any array element. The text operation puts characters, as specified by the primary-attibute-value pa-CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 34 rameter, into the array element at the pointer's current position. This will also cause an implicit movement of the display pointer, ie. increment it to the next array element on the current line. When the last element in the line is filled, the display pointer moves one position past the end of the line and does not move until an explicit ad-dressing operation is done. The secondary attribute for the newly entered character is determined in the following order : (i) the value of the corresponding modal attribute variable, if it is not "null", (ii) the existing value in the array element, if it is left unchanged, and (iii) the value of the corresponding global attribute variable, if it is not "null". If none of the above conditions is true, the default attribute value will be applied. Repeat-text operation has the effect of repeating the text operation. The character string in the parameter primary-attribute-value-string is repeatedly written on consec-utive array elements until the specified coordinates, the finish-address, are reached. The last operation, erase, is used to erase from the primary attribute one or more array elements according to the value of erase-extent. Erase-extent specifies a starting and an ending address which may be absolute coordinates or one of the special values in Table 2.11. Secondary attributes may also be erased if reset-attribute has the value "true". CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 35 Control object updates are less structured than those available for the display object. Their main purpose is to enter a special value to the content of the control object. Since control objects have different types (as defined by the value of VTE-parameter C O -category), updates are classified into : • character-update which writes a character string on the control object, • boolean-update which modifies individual boolean values, according to an optional mask indicating which values are to be modified, • symbolic-update which writes an symbolic integer value on the control object, • integer-update which writes an integer value on the control object, and • bitstring-update which replaces the content of a transparent type control object by an uninterpreted bit string value. Since updates to the control object have priority, a seperate data transfer path may be required to transfer urgent updates, so that they can bypass all previously transmitted updates information not yet delivered to the user. The availability of such a capability depends on whether the Urgent Information Exchange functional unit is selected and the availiablity of an expedited data transfer service from the lower layers. The next two services that follow Data Transfer facility in Table 2.9 are used for delivery control. V T - D E L I V E R is used to place a delivery mark in the data stream CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 36 and its meaning (as defined in the previous section) varies with the type of delivery control in effect. If the current profile specifies no-delivery-control, this service may not be invoked. If simple- or quarantine-delivery-control is in effect, a V T user may request acknowledgement on the VT-Deliver and the peer must response with the V T -A C K - R E C E I P T service. The last two services in Table 2.9 belong to the Access-Right Management facility and are only used in S-mode. Since only one user wil l hold the W A V A R access right at any point in time in S-mode, in order to access the V T abstract objects and services provided by the V T service provider, a token is used to indicate who is the owner of this access right. The V T - G I V E - T O K E N S service transfers the token from the user who has it to the one who doesn't. The V T - R E Q U E S T - T O K E N S service allows the user without the token to request it from the user who has, though it is not guaranteed to be successful. Several optional services are also specified in the V T standard, their availability depends on whether the corresponding funtional units are selected. Table 2.12 contains these services, their types and the facilities to which they belong. VT-S W I T C H - P R O F I L E service is available when the functional unit Switch Profile Negotiation (SPN) is selected. As its name suggests, this service allows the V T users to switch profile without breaking and re-establishing the association. Since it is a confirmed service, the profile arguments (if any) can be negotiated between two V T CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 37 Facility Service Type Switch Profile VT-SWITCH-PROFILE confirmed Negotiation Multiple Interaction VT-START-NEG confirmed Negotiation VT-END-NEG confirmed VT-NEG-INVITE non-confirmed VT-NEG-OFFER non-confirmed VT-NEG-ACCEPT non-confirmed VT-NEG-REJECT non-confirmed Interrup VT-BREAK confirmed Table 2.12: Optional Basic Class Virtual Terminal Services users. The peer user may or may not accept the new profile. If it does accept, the old V T E is entirely replaced by the new one specified in the new profile and any context associated with the previous V T E , e.g. the current contents of its display and control objects, is lost. The next optional negotiation facility is the Multiple Interaction Negotiation (MIN). It is available when the functional unit Switch Profile and Multiple Interaction Negoti-ation are selected. The name of the functional unit suggests that when the V T service provider supports M I N , it must also support S P N . In some cases this may be a burden for implementors of V T P where only M I N will be used by their applications. M I N pro-vides the V T users with a mechanism to modify individual V T E parameters without replacing the complete profile. The negotiation phase is started by the V T - S T A R T - N E G service and terminated by CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 38 the V T - E N D - N E G service. Once negotiation phase starts, the initiating V T user may invite (using the V T - N E G - I N V I T E servie) the peer user to propose values for V T E -parameters, or offer (using the V T - N E G - O F F E R service) values to the peer user. The peer user may return an offer (using the V T - N E G - O F F E R ) in response to an invitation, or accept (using the V T - N E G - A C C E P T service), reject(using the V T - N E G - R E J E C T ) or counter-offer (using V T - N E G - O F F E R ) an offer. Because of the complex nature of M I N , the standard imposes strict control on the sequences of negotiation. In A-mode, only the initiating V T user may send initial offers, invitations and request an end to the negotiation. In S-mode, the initiating V T user must hold the token and must pass it to the peer user after offers or invitations. The last optional service, V T - B R E A K , is selected from the funtional unit Break. Its intended usage is to simulate the "break-in" function found on most terminals. The V T -B R E A K service allows a VT-user to interrupt a previously initiated sequence of updates to display and control objects, discard all updates currently being exchanged in either direction, and resume exchanging data after the services providers have resynchronized their activities. The V T - B R E A K service carries an important piece of information, a display pointer value, indicating what the peer VT-user believes is the current value of the display pointer. This value helps VT-users to resychronize their activities on the display object. Definitions of parameters for all of the above mentioned services can be found in the CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 39 V T standard. However, there is a little inconsistency between the documents DIS 9040 and DIS 9041. The changes made in DIS 9040 for the second version were not reflected in DIS 9041. Thus definitions for service parameters may not be matched between these two documents, although both documents are referring to the same service definition. In case of arbitration or dispute, definitions in DIS 9040 should take precedence over those in DIS 9041. 2.4 The Virtual Terminal Protocol Two V T implementations communicate with each other by passing Protocol Data Units (PDUs) which convey information stored in service parameters. The integrity of the dialogue is maintained by the Virtual Terminal Protocol Machine ( V T P M ) at each side of the association. The V T protocol is connection-oriented which allows only one virtual terminal to be active on a single connection at any one time. Overall, the protocol describes : (i) the actions to be taken when service primitives are received from the user or a lower layer, (ii) the actions to be taken in response to PDUs sent by the peer user, and (iii) the actions to be taken as a result of events within the local system. Actions that may be taken by the protocol include : CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 40 (i) establishing and terminating a V T association, (ii) sending and receiving data(PDUs) to and from the peer V T P M , (iii) negotiating with its user and the peer V T P M to agree upon the V T environment, (iv) controlling the delivery of data to its user and the peer V T P M according to the type of delivery control, (v) controlling the dialogue to enforce a two-way alternate discipline in S-mode op-eration, and (vi) handling of error condition which may be generated from the protocol itself or from the lower layer. Table 2.13 contains the mapping between service primitives and PDUs. In most cases, this mapping is a one to one correspondence between service primi-tives and PDUs. Request or response type service primitives are mapped into request or response types PDUs, whereas request or response type PDUs are mapped into indi-cation or confirm type service primitives. However, because of different priority levels on control object updates, a V T - D A T A service primitive may map into different PDUs according to the priority level "normal", "high" and "urgent". A typical A-mode V T session is illustrated in Figure 2.3. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 41 Type Service Primitive Protocol Data unit Association Establish VT-ASSOCIATE.request/indication VT-ASSO CIATE.response / confirm ASQ (VT-ASSOCIATE-REQ) ASR(VT-ASSOCIATE-RESP) Association Termination VT-RELEASE.request / indication VT-RELEASE.response/confirm VT-U-ABORT.request /indication VT-P-ABORT.indication RLQ(VT-RELEASE-REQ) RLR(VT-RELEASE-RESP) AUQ(VT-U-ABORT-REQ) APQ(VT-P-ABORT-REQ) Data Transfer VT-D ATA.request / indcation ND Q (VT-D ATA-REQ) HDQ(VT-HIGH-PRI-DATA-REQ) UD Q (VT-URGENT-DATA-REQ) Data delivery control VT-DELIVER.request/indication VT-ACK-RECEIPT.request/indication DLQ(VT-DELIVER-REQ) DAQ(VT-ACK-REQ) Dialogue Management VT-GIVE-TOKEN.request /indication VT-REQUEST-TOKEN.request/indication VT-BREAK.request/indication VT-BREAK.response/confirm GTQ(VT-GIVE-TOKEN-REQ) RTQ(VT-REQUEST-TOKEN-REQ) BKQ(VT-BREAK-REQ) BKR(VT-BREAK-RESP) Negotiation VT-SWITCH-PROFILE.request/indication VT-START-NEG .request/indication SPQ(VT-SWITCH-PROFILE-REQ) SNQ(VT-START-NEG-REQ) VT-START-NEG .response/confirm VT-END-NEG .request/indication VT-END-NEG .response/confirm VT-NEG-INVITE.request/indication VT-NEQ-OFFER.request/indication VT-NEQ-ACCEPT.request /indication VT-NEQ-REJECT.request/indication SNR(VT-START-NEG-RESP) ENQ (VT-END-NEG-REQ) ENR( VT-END-NEG-RESP) NIQ (FVT-NEG-INVITE-REQ) NO Q (VT-NEG-OFFER-REQ) NAQ (VT-NEG-ACCEPT-REQ) NJQ(VT-NEG-REJECT-REQ) Table 2.13: V T Service Primitives to PDUs Mapping CHAPTER 2. THE ISO VLRTUAL TERMINAL STANDARD V T P M V T P M VT-ASSOCIATE.request VT-ASSOCIATE.confirm VT-DATA.request (normal) VT-DELIVER.request VT-ACK-RECEIPT.indication VT-DATA.request * (normal) • VT-DATA.request (urgent) VT-DELIVER.request VT-RELEASE.request VT-RELEASE.confirm VT-ASSOCIATE.indication VT-ASSOCIATE.response VT-DATE.indication (normal) vT-DATA.indication (normal) VT-DELIVER.indication (ACK required) VT-ACK-RECEIPT.request V VT-DATA.Indioation (urgent) VT-DATA.indication « (normal) o VT-DELIVER.indication (ACK not required) VT-RELEASE.indication VT-RELEASE.response Figure 2.3: A Typical A-mode V T Session CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 43 In this example simple-delivery-control is assumed in which V T updates may be held up by either V T P M , and a V T - D E L I V E R service primitive will force the delivery to the peer user. Also, urgent updates will always bypass other previously initiated updates. As we mentioned earlier, the V T P M makes use of the services provided by the A C S E and Presentation layer to communicate with the peer. Services that are assumed from A C S E are: • A -ASSOCIATE request and indication which convey the ASQ pdu, • A -ASSOCIATE response and confirm which convey the ASR pdu, • A - R E L E A S E request and indication which convey the R L Q pdu, • A - R E L E A S E response and confirm which convey the RLR pdu, • A - A B O R T request and indication which convey the A U Q pdu, and • A - P - A B O R T request and indication which convey the A P Q pdu. Description of A C S E service and protocol can be found in C C I T T documents X.2176 [11] and X.227 7 [10]. Services that are assumed from the Presentation layer are: 6Equivalent to ISO DIS 8649. 7Equivalent to ISO DIS 8650. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 44 • P -DATA request and indication which convery the NDQ, D L Q , NIQ, N O Q , N A Q and NJQ pdus. • P - T Y P E D - D A T A request and indication which convey the HDQ, UDQ and D A Q pdus, • P - E X P E D I T E D - D A T A request and indication which convey the UDQ pdu, • P - T O K E N - G I V E request and indication which convey the G T Q pdu, • P - T O K E N - P L E A S E request and indication which convey the R T Q pdu, • P -RESYNCHRONIZE request and indication which convey the B K Q pdu, • P -RESYNCHRONIZE response and confirm which convey the B K R pdu, • P -SYNCHRONIZE-MAJOR request and indication which convey the SPQ, SNQ and E N Q pdus, and • P -SYNCHRONIZE-MAJOR response and confirm which convey the SPR, SNR and E N R pdus. Description of Presentation service and protocol can be found in C C I T T documents X.2168 [16] and X.2269 [15]. 8Equivalent to ISO DIS 8822. 9Equivalent to ISO DIS 8823. CHAPTER 2. THE ISO VIRTUAL TERMINAL STANDARD 45 Although V T protocol will not directly interact with the Session layer, certain functional requirements from the Session layer must be assumed in order to provide support to the Presentation layer and in turn provide support to the V T P M . These functional requirements describe what functional units must be made available in the Session layer. They are: • the duplex functional unit for A-mode operation or half-duplex functional unit for S-mode operation, • the typed functional unit if the priority of updates require "high" or "urgent", • the expedited functional unit if the urgent data V T functional unit is selected, • the negotiated release functional unit if the negotiated release V T functional unit is selected, • the major synchronization functional unit if any negotiation type of the V T func-tional unit is selected, and • the resynchronize functional unit if the break V T functional unit is selected. Description of Session service and protocol can be found in C C I T T documents X.215 1 0 [19] and X.225 1 1 [18]. "Equivalent to ISO IS 8326. "Equivalent to ISO IS 8327. Chapter 3 The ISO V T P Implementation As part of this thesis, we implemented a subset of the ISO V T protocol on the SUN 3/260 Workstation1 running SUN UNIX Release 3.2 (a UNIX 4.2/4.3 BSD compatible). Our aim was to implement and test the usefulness of the ISO V T protocol under the UNLX environment. From now on we denote our implementation of the protocol by ubcVTP, whereas V T P refers to the ISO V T P as described in the previous chapter. Since ubcVTP is a subset of ISO V T P , unless noted otherwise, comments about ISO V T P will apply to ubcVTP as well. ubcVTP was written in the C programming language and accounts for approximately 12,000 lines of documented source code. This chapter describes the implementaion details of this local implementation. The chapter is organized in the following manner: • Section 1 presents the ubcVTP implementation model. 1SUN Workstation is a registered trademark of the Sun Microsystem Inc. 46 CHAPTER 3. THE ISO VTP IMPLEMENTATION 47 • Section 2 describes the virtual terminal model that is denned by the ubcVTP. • Section 3 describes the local mapping function that is used to map terminal or application I/O on V T operations. • Section 4 describes the virtual terminal protocol machine that is used to imple-ment the virtual terminal protocol. • Section 5 describes the combined A C S E and Presentation layer which provides an interface to the Transport layer. 3.1 The u b c V T P Implementation Model The ubcVTP implementation model, as shown in Figure 3.1, is very similar to the one in Figure 2.2, with some exceptions: • an interface unit, called pty, is added between the local mapping process and the user application program, • another interface unit, called tty, is added between the local mapping process and the terminal, • a separate layer is added between the V T protocol and the Presentation layer to translate the abstract syntax of PDUs into their transfer syntax and vice versa, • A C S E and Presentation layers are now combined into a single layer. CHAPTER 3. THE ISO VTP IMPLEMENTATION Client Server terminal 7 ^ C \7 TTY T T Y O U T T T Y I N L M F V T P M A S N . 1 Encoder & Decoder Dummy ACSE & Presentation Layer PTYOUT = PTYIN L M F V T P M A S N . 1 Encoder & Decoder Dummy ACSE & Presentation Layer Figure 3.1: The ubcVTP Implementation Model CHAPTER 3. THE ISO VTP IMPLEMENTATION 49 As illustrated, several layers must be traversed before the transmission of data occurs between the network (or more precisely, the network interface provided by the UNIX operating system), and the application or terminal in either direction. In order to increase the efficiency of the implementation, all layers are built under a single UNIX user process. Communications between layers are through function calls. Instead of copying data from one layer to another, pointers to a shared memory which contains the necessary service primitives and their parameters, are passed between layers. The task of mapping an application's or terminal's I/O to and from V T operations is also kept under the single UNIX user process. For this reason we call it the local mapping function rather than the local mapping process to avoid the possible misunder-standing that the function is a seperate UNIX process. Communication between the interface unit and the local mapping function is through two data queues, one for each direction. Each element in the queues is a single character that is being read from, or waiting to be sent to the interface unit. There is no data queue to connect the lowest layer in the ubcVTP implementation and the network interface, because the data at this level is P D U oriented. A complete P D U must be read and sent at any time, thus the implementation does not need to store the input or output data. Instead, it will block at this point until reading or sending of a complete P D U is finished. We want to make it clear that this "blocking" mechanism is not the same as that in the read and write functions provided by the UNIX operating system. Our blocking mechanism was CHAPTER 3. THE ISO VTP IMPLEMENTATION 50 implemented as an atomic transaction, that is it reads and writes a complete PDU at a time, or it does not read or write at all. With the combination of non-blocking I/O operations and the select facility provided by the UNDX operating system, processing of input and output is switched between the application and the network or the terminal and the network. The ubcVTP implementation is intended to allow a user to login remotely to an-other computer system and to access the applications in that system, regardless of the differences in the terminal characteristics expected by the remote applications and the local terminal. Such sequences of events can be modelled using the client/server model, where the local user is the client and the remote application is the server. Extending the model, the ubcVTP implementation that communicates with the local user be-comes the client-VTP and the one that communicates with the application is called server- VTP. Before the internal structure of each layer is described, another important aspect of the ubcVTP implementation must be discussed. It is the virtual terminal model that is defined by ubcVTP. 3.2 The Virtual Terminal Model for ubcVTP Although the ISO VTP has provided several profiles to describe different virtual terminal models that can be used for different applications, we feel that they are either CHAPTER 3. THE ISO VTP IMPLEMENTATION 51 too complicated or too simple, and cannot be directly applied to applications in the U N I X environment. The virtual terminal model that we need should have the following features: (i) it should allow operation in asynchronous mode, (ii) it should be a scroll mode type terminal, with scrolling capability in either direc-tions (up or down), (iii) it should support all relative or absolute cursor movements on the whole screen, (iv) it should have the insert line and delete line capability to allow applications to simulate the scrolling of text within a document (file), (v) it should handle proper line update for character insert and delete mode instead of redrawing the whole line (vi) it should support more emphasis level than simply "normal" such as "reverse" or "blinking". Actually the above features are not very demanding, they can usually be found in to-day's terminals. The profile we found that is closest to our requirment is v t - b - r p r - a l [46], However, the virtual terminal that is defined by this profile only allows forward rel-ative addressing and no absolute addressing at a l l 2 . Further, only the emphasis level 2The profile does not explicitly state this but the default values for those parameters imply it. CHAPTER 3. THE ISO VTP IMPLEMENTATION 52 "normal" is supported. No profiles denned in the standard will be able to suppport feature (iv) and (v) because the Basic Class V T P itself does not have the capability to move text around within the boundary of a display object. We feel these features are important because they help to reduce traffic on the network which connects the user and the application. Without these features, if the application program wants to delete or insert a line, it must redraw the lower part of the screen to reflect the changes. In this case, many unnecessary text update operations will be sent from the server-VTP through V T - D A T A - R E Q to the client-VTP. A similar situation wil l occur when the virtual terminal does not have the insert or delete character capability. Although the V T standard has indicated that a V T E can be modified to meet the special needs of different applications, through the use of the negotiation facility, it is unclear how this is to be done. For changing individual parameters within a V T E , the M I N facility must be used. However, even with the M I N facility, we cannot define new objects within the V T E . There is no way to pass the semantics of the new object to the peer user and thus, the peer user cannot identify the usage of that object. Even with parameters that already exist in the V T E , there may still be problems in assigning them new values . For example, all assignment parameters of a display object use a character string to identify rendition attributes. When a new attribute value is passed to the peer user, the peer user may have difficulty in interpreting the meaning of this character string without considerable large amount of string comparison. The worst CHAPTER 3. THE ISO VTP IMPLEMENTATION 53 case is for parameters having values of A S N . l type A N Y [38]. It is impossible to convert this syntax into the local representation without an early agreement of an explicit data type between the two communicating parties. Due to the reasons outlined above, we have decided to define our own profile for our own virtual terminal model. The complete definition of the profile is contained in Appendix A . The profile has been assigned the name vt-b-ppr-al which follows the convention as defined in the V T standard for profile names [46]. Its contents are represented in B N F notation to make it compatible with other profiles defined in the standard. Since UNLX only supports asychronous type terminals, our private profile contains two display objects to indicate that the virtual terminal defined belongs to this type. The first display object is called "screen", and is intended to represent the terminal screen. Similarly, for the second display object which is called "keyboard". Since the terminal user is always the initiator of a V T association in our ubcVTP implementation, and the screen output is always controlled by the remote application program, the "screen" display object has been assigned the W A C A access-right and the "keyboard" display object has been assigned the W A C I access-right. The user may log on to different terminals having different screen size from time to time, thus the profile provides extra flexilibity by defining two arguments to represent this information. Profile argument r l is used to represent the line length and profile CHAPTER 3. THE ISO VTP IMPLEMENTATION 54 argument r2 is used to represent the page length of a terminal. The "screen" display object has two dimensions: the x-dimension represents a line and the y-dimension represents a page. The value in profile argument r l is assigned to parameter x-bound, however, parameter y-bound must be "unbounded" in order to constraint the virtual terminal as being a scroll mode type terminal. Profile argument r2 is then assigned to parameter y-window. This is a reasonable approach because y-window should be equal to the page length of the terminal, otherwise text and absolute-addressing operations cannot work on a full screen basis 3. Relative- and absolute-addressing operations are permitted on all dimensions of this display object in order to fullfi.il the above mentioned requirement (feature (iii)). The control sequence4 for erasing text has to be mapped onto the V T erase op-eration, so the erase-capability is assigned the value "yes". The display object, that is the "screen", supports five different emphasis levels. The parameter for the control sequence Select Graphic Rendition 5 can be directly mapped onto one of these emphasis values. Other attribute parameters for the "screen" display object assume their default values. Since the default value is "device-dependent", the ubcVTP implementation simply ignores these parameters and does not bother to provide any mapping for them. 3As defined in the previous chapter, text operations that are outside the window bounds are invalid. 4 A control sequence is a character string which allows the application program to perform certain actions on the terminal screen. We will further explain control sequences later in this chapter. 5The control sequence SGR has the form ' 'ESC [ P m*' in where each P represents a rendition number as defined in ISO 6429 [34] CHAPTER 3. THE ISO VTP IMPLEMENTATION 55 Input editing in U N I X is done remotely, so the ubcVTP implementation on the terminal side need only transmit keyboard input, character by character, to the remote application program. As a result, the "keyboard" display object is only one dimen-sional. Explicit addressing operations are not allowed, as imposed by the addressing parameters. Only text operations and the implicit addressing operations they imply are allowed on the "keyboard" display object. Since the display pointer cannot move backward, the display object will not have any erasure capability. We did not specify this parameter in the profile because the default value for erasure-capability is already "no". The attribute parameters for the "keyboard" display object also assume their default values. It is rare to find keyboards that have keys to change the rendition attributes of individual character on the screen. As mentioned, the ISO V T P does not support any insert or delete line operations on the virtual terminal, thus we have defined a control object to represent this kind of operation. The control object is called I N D E L which stands for INsert and DELete control object. The remote application program controls what should be on the terminal screen, thus the control object can only be updated by the remote application program ( as imposed by the W A C A access-right). A l l insert or delete type control sequences generated by the application programs will now be mapped into the update operation of this control object. The control object contains four Boolean values and each is used to indicate which of the four control sequences has been received. These four CHAPTER 3. THE ISO VTP IMPLEMENTATION 56 control sequences represent the effect of insert-line, delete-line, insert character and delete character. For example, when a control sequence for delete line is received by the local mapping function, the second Boolean variable of this control object will be set to true (after some kind of mapping). In turn, the VTPM(see Figure 3.1) will transfer the update of the control object to the peer V T P M where the update will be decoded at the peer local mapping function. Upon detecting that the second boolean value is on, a terminal dependent control sequence for delete line will be sent to the physical terminal. Actually, the control object can also be denned as having transparent type of size four where each bit represents one control sequence, but this is up to the programmer's preference. There is a device object denned for the "screen" display object. The parameters of the default control object for this device object have not really been used in our ubcVTP implementation, since the terminal should always be in the "on"state if the user has logged onto a remote computer system. We include these parameters for reasons of compatibility with other profiles in the standard. The next two parameters, device-minimum-X-array-length and device-minimum-Y-array length, have been set to the line length and the page length of the real terminal as indicated by the profile arguments r l and r2. This is essential, otherwise how can a full screen editor function correctly on a terminal screen that is smaller than it expects. We did not define any termination parameters for the device object because we do not want to wait for any conditions CHAPTER 3. THE ISO VTP IMPLEMENTATION 57 before forwarding updates, in order to maintain good response time on keyboard input echoing. Both server-VTP and client-VTP will deliver updates to the peer user as soon as they are received from the local user. Because of this restriction, the value for the parameter type-of-delivery-control will be "no-delivery-control". A l l other forms of delivery control are redundant, if V T implementions on both sides of the association deliver updates as soon as they can. None of the attribute parameters are defined for this device object either, because most of the associated attribute parameters in the "screen" display object have the value "device-dependent". The values of the emphasis parameter can be directly mapped onto those found in the real device; we do not require the emphasis parameter to provide any more device specific information. Finally, there is no device object defined for the "keyboard" display object because its structure is very simple and can be easily mapped to a real terminal's keyboard. There is no control object defined for the display object, thus a device object is not needed to establish a relationship between this display object and any other control objects. 3 . 3 Local Mapping Function As previously mentioned, the direct user of the V T protocol is not the human terminal user, nor the application process residing in the remote machine. It is the local mapping function (LMF) that maps vendor supplied terminal interfaces onto V T CHAPTER 3. THE ISO VTP IMPLEMENTATION 58 services, which perform updates to the abstract objects comprising the virtual terminal. The interface to an application process residing in a remote system is different from that is the local physical terminal, creating a need for two different L M F s . One of them, called the server-LMF, provides a mapping between the application's I /O and V T services. The other one, called the client-LMF, maps the terminal's I /O to and from the V T services. The remainder of this section will describe each of these L M F s in detail. 3.3.1 The Server-LMF The server-LMF lies between the application program and the V T protocol. We will first describe the interface that allows the server-LMF to interact with the application program, then the mapping function that maps the application's output onto V T oper-ations. Finally, the mapping function that maps V T operations onto the application's input is described. Interface to Appl icat ion Program Many application programs will not function properly without a terminal for stan-dard input and output. Sockets themselves do not provide any semantics for terminals In order for the V T protocol to communicate between the network and the applica-tion program, a special device must act as a bridge to link the V T protocol and the CHAPTER 3. THE ISO VTP IMPLEMENTATION 59 application program together. In U N I X , such a device is called pseudo-terminal or pty [26]. A pty consists of two parts: a master side and a slave side. The V T protocol, or more specificly the server-LMF, communicates with the master side while the application program communicates with the slave side. Data written on the slave side is supplied as input to the server-LMF read from the master side, while data written on the master side is supplied as terminal input for the slave. In this way, the server-LMF on the master side has control over the information read and written on the salve side, which appears to the application program as standard input and output from a physical terminal. Figure 3.2 depicts this relationship. Appl icat ion Output M a p p i n g Output from application programs contains ordinary text (displayable characters) and control data such as escape sequences to control the cursor movement on the terminal screen. To map ordinary text output into V T services is easy. A l l characters from column three to seven in the ASCII character set table are displayable (except character D E L ) . If a received character falls in this range, it is translated into a text operation for update of the display object. However, because of the diverse differences in escape sequences, numerous string comparisons must be performed in order to map an escape sequence into one of the display or control object's update operations. Certainly, CHAPTER 3. THE ISO VTP IMPLEMENTATION 60 Unix 4.2 BSD - Based computer System Unix user processes TCP P / l P PTY PTY MASTER SLAVE Unix system kernel Figure 3.2: Relationship of pty to ubcVTP and Applications this is impractical. Consequently, a special data structure, called keymap, has been designed for doing this kind of mapping without requiring any direct string comparisons. Figure 3.3 depicts the structure of keymap. Keymap contains three levels. Each level contains an array of 128 entries in which each entry is indexed by the decimal value of a received character according to the 7 bit ASCII table. Furthermore, each array element is a pointer to a function which specifies what action should be done when the corresponding character is received. CHAPTER 3. THE ISO VTP IMPLEMENTATION 61 0 1 A B C D J L 3 ( get_param ) CUD Figure 3.3: Structure of the Keymap Keymap level 1 (LI) is used to decode ordinary text (the GO character set6) and single control characters (the CO control character set). Keymap level 2 (L2) is used to decode two character escape sequences such as ' ESC M ' . This type of escape sequence is the representation of an 8 bit C I control character in a 7 bit character environment7. Keymap level 3 (L3) is used to decode escape sequences of the form ESC [ P . . . . P F 6For definitions of general and control character sets, see ISO 2022. 7ISO 2022 contains this extension technique CHAPTER 3. THE ISO VTP IMPLEMENTATION 62 which are usually called control sequences8. Here the two characters, ESC and ' [ ' , represent the 8 bit character CSI (Control Sequence Introductor) in a 7 bit character environment. P is the parameter for the escape sequence which may have multiple occurances, and F represents the final character that designates the function of the sequence. When each character in an escape sequence passes through keymap, one of three events will occur. The first event is to continue the decoding in a deeper level in keymap. The second event is to invoke the function get-param, as shown in Figure 3.3, to collect the parameters for the escape sequence. The last event is to invoke a function that maps the escape sequence, according to the final character, into an update operation of the display or control object. For example, upon receiving the excape sequence ESC [ 3 A, which means move the cursor up three lines on the screen, the following steps will happen: (i) the first character ESC wil l be decoded at L l which signifies a second level of keymap is required to decode the sequence, (ii) the second character ' [' is decoded at L2 which signifies another level of keymap is required to further decode the sequence, (iii) the character '3 ' is decoded at L3 where the function get.param is invoked to convert the character into a decimal 3, 8Control sequences are explained in ISO 6429 CHAPTER 3. T H E ISO VTP IMPLEMENTATION 63 (iv) the final character 'A' is decoded at L3 which designates the function CUU (see Figure 3.3) to map the whole sequence into the update operation, pointer-relative, of the display object with relative offset on the Y coordinate equal to -3 and X equal to 0. Table 3.1 contains all the possible mapping that are provided by keymap to decode terminal specific data into V T abstract operations. Terminal Specific Operation VT Abstract Operation all displayable characters The text operation of display object all control characters, ESC-sequences and control sequences that will move the cursor on the screen The relative-addressing or absolute-addressing operation of display object erase line and erase page control sequences The erase operation of display object control sequences that change the rendition attribute on the screen The attribute operation of display object delete line control sequence Boolean update with value '0010' to control object " INDEL" delete character control sequence Boolean update with value '0001' to control object " INDEL" insert line control sequence Boolean update with value '1000' to control object " INDEL" insert character control sequence Boolean update with value '0100' to control object " INDEL" Table 3.1: Mapping Between Terminal Specific and V T Abstract Operations CHAPTER 3. THE ISO VTP IMPLEMENTATION 64 The V i r t u a l Terminal 's Termcap Although standards exist for terminal control sequences [34], vendors like to in-troduce private control sequences for their terminals. It is impossible to have a single keymap that can decode all sequences for different vendor's terminals. In order to avoid having one keymap (or L M F ) for each different type of terminal, a new termcap entry has been denned inside the U N I X termcap data base. The termcap data base is the collection of terminals' capabilitities, with one entry for each type of terminal supported. When an application program like vi wants to perform some specific op-eration on the terminal, for example moving the cursor on the screen, it will look up the entry for this terminal in the data base and find the control sequence necessary to perform the operation. The termcap that we have defined is called isovt (stands for ISO Virtual Terminal), Figure 3.4 contains the definition for this terminal type 9 This V T I i s o v t I ISO V i r t u a l Te rmina l : \ :co#80:li#24:cl=\E[H\E[J:bl="G:le=~H:nd=\E[C:up=\E[A:do=~J:\ : cm=\E [7,i'/.d; °/.dH: ho=\E [H: ce=\E [K: cd=\E [ J : al=\E [L: dl=\E [M: \ : i c= \E [(0: dc=\E [P: so=\E [7m: se=\E [m: us=\E [4m: ue=\E [m :mb=\E [5m: \ :md=\E[lm:mr=\E[7m:me=\E[m:kl=\E[D:kr=\E[C:ku=\E[A:kd=\E[B:\ : i s= \E[H\E[J : r s= \E[m\E[H\E[J : Figure 3.4: Termcap isovt for the ubcVTP Implementation virtual terminal contains capabilities like moving the cursor, changing the rendition 9For a more detailed description of individual fields, please refer to the UNLX Programmer's manual [22]. CHAPTER 3. THE ISO VTP IMPLEMENTATION 65 attributes, inserting and deleting lines, and inserting and deleting characters. These should be sufficient to support most of the applications on U N I X like Csh, Vi and the more powerful screen editor Emacs. By introducing the new terminal type to the applications, we need only a single keymap because all control sequences generated by application programs can be predetermined. Appl icat ion Input M a p p i n g Mapping V T abstract operations into an application's input is not as difficult as mapping its output to V T abstract operations. The only operation that is expected by the server L M F is the text update operation of a display object (see terminal output mapping in the following section). The character that is stored in the text operation is simply extracted and written onto the master side of the pty so that this character will appear as standard input to the application. 3 . 3 . 2 T h e C l i e n t - L M F Because the interface between L M F and the terminal is different than that be-tween L M F and the application program, separate mapping functions must be built, which translate V T operations into terminal input, and from terminal output into V T operations. We will describe each of these in turn. CHAPTER 3. THE ISO VTP IMPLEMENTATION 66 Interface to Physical Terminals For application programs to read from the terminal's keyboard or write to the terminal's screen, a terminal driver must exist to convert hardware signals to and from user data. In the U N I X operating system, such a terminal driver is called tty driver and is automatically created when an application program is started up from the user's terminal. Thus, for the client-LMF to read input from the keyboard, it simply read from the standard input of the tty driver. Similarly, to write output on the screen, the client-LMF can write to the standard output of the tty driver. Screen Output M a p p i n g Since a user may log on to different types of terminals from time to time to run the V T protocol, the terminal characteristics are not predictable by the client-LMF. It is again impractical to develop one L M F for each type of terminal supported. Fortunately, each terminal type has an entry in the termcap data base as described in the previous section. Thus, the mapping function in the client-LMF can adjust itself dynamically according to the capabilities in the termcap entry that describes the current log on terminal. For example, the client-LMF may map the display object's erase operation to the escape sequence ESC [ L for one type of terminal and ESC E for another type of terminal, although they both mean "erase the whole screen". In order to achieve such terminal type independence, a set of functions found in the termcap library were CHAPTER 3. THE ISO VTP IMPLEMENTATION 67 used to extract the termcap entry and to decode terminal capabilities. Sometimes a delay specified in milliseconds, may be added to the front of an escape sequence in the termcap entry so that the terminal will have enough time to properly interpret the sequence. Thus, functions are also provided by the termcap library to output an escape sequence to the terminal in which the delay will be automatically converted into padding characters on the screen. Detailed desciptions of termcap library functions can be found in section 3X of the UNLX Programmer's Manual [22]. K e y b o a r d Input M a p p i n g The structure for the keyboard display object allows text update as its only possible operation; thus the task of mapping the keyboard input becomes very simple. Each character read from the standard input wil l simply be stored inside the text update operation of the display object. There are two major reasons why we pass all input characters as uninterpreted ASCII values to the remote system. The first reason is that input to a terminal in the UNLX environment is interpreted remotely, or more precisely, the meaning of each input character is defined by the remote application, not the local system. Each character may have different meanings in different applications. For example, control-D means scroll down ten lines in V i but logout in Csh. The second one is that users are allowed to change the meaning of a character or character sequence within an application. For example, a user may change the interrupt character from CHAPTER 3. THE ISO VTP IMPLEMENTATION 68 control-® to control-C in Csh or change the binding for moving up one line from ESC p to ESC s in Emacs. It is impossible to build a keymap for decoding a terminal input, because the semantics of a character or character sequence, and user's behaviour are nondeterministic. By passing uninterpreted characters, the ubcVTP implementation is very flexible and transparent to both user and remote application. 3.4 The Virtual Terminal Protocol Machine The V T P M which houses the V T protocol, is being modelled as a finite state machine which has proven to be the most practical way to implement protocols [52,6,54]. In this approach, V T P M is viewed as a black box with memory containing its current state which may be altered by input events. Output events may or may not happen as a result of state changes. Input events for V T P M consist of service primitives received from the local user(request or response) and V T - P D U s received as user data on service primitives from lower layers (indication or confirm). Output events are the generation of service primitives for its local user (indication or confirm) and V T - P D U s as user data on service primitives to the lower layers (request or response). Indications that are generated by the lower layers themselves may also consistute some of the input events. The action to be taken on any input event is described in a state table by the V T standard. Because of the large number of states and input events, it is imprac-CHAPTER 3. THE ISO VTP IMPLEMENTATION 69 tical to implement the state table using nested switch statements in the C language, which is quite common in the implementation of lower layers protocols. Instead, a two dimensional table has been denned with columns representing the states and rows rep-resenting the input events. A combination of state and input event will index an entry in the table which is a pointer to a function. This function, called the event handler, may alter the machine's current state and generate one or more output events. Thus a program statement like table[input-event][current-state] will initiate an appropriate function call to execute a fragment of code that performs the necessary action. Protocol errors, as represented by an empty entry in the state table, are dealt with by calling special event handlers which will generate error messages to the user or peer V T P M . The state tables denned by the V T standard in DIS 9041 are quite ambiguous. For certain states and actions, there has been a confusion between A-mode and S-mode operations. For example, in A-mode operation, when V T P M receives a R E L E A S E request primitive from the user, it will send a R T Q P D U to its peer to request the token (when it does not currently hold the token), and go to the "Release, awaiting token" state. Certainly, this kind of action should belong to S-mode, not A-mode. Even though, a Session release token may be used for the Negotiated Release functional unit, CHAPTER 3. THE ISO VTP IMPLEMENTATION 70 it does not seem to be the responsibility of the V T P M to take care of it. As a matter of fact, neither A C S E nor the Presentation layer will wait for a token in their release operations [36,15]. In order to have a better understanding of the behaviour of our V T P M implementation, a set of state transition diagrams are provided in Appendix C. Since the use of V T P under the U N I X environment is very restrictive, not every service is implemented in the ubcVTP. Services that are supported by the local V T P M implementation are: • V T - A S S O C I A T E • V T - R E L E A S E • V T - U - A B O R T • V T - P - A B O R T • V T - D A T A 1 0 • V T - D E L I V E R • V T - A C K - R E C E I P T • V T - S W I T C H - P R O F I L E • V T - B R E A K 10Since there is no separate channel to provide expedited data transfer in our supporting services, UDQ will be transferred using the normal data path. CHAPTER 3. THE ISO VTP IMPLEMENTATION 71 Services that are not currently supported by V T P M are: • all services that are related to Multiple Interaction Negotiation (MIN) • V T - G I V E - T O K E N • V T - R E Q U E S T - T O K E N Because of this, the state transition diagrams in Appendix C contain only those tran-sitions where their corresponding services are supported. 3 . 5 A S N . l E n c o d i n g a n d D e c o d i n g As previously stated, the Application layer is concerned with the meaning of the transmitted data, while the Presentation layer governs the way this meaning is rep-resented [30]. In other words, the Presentation layer changes the local syntax into a commonly known transfer syntax, however, the actual translating process is not being done inside the Presentation layer. The Presentation layer only negotiates with its peer as to which transfer syntax selected by the Application Entity is suitable. A l l Applica-tion layer protocol elements must be translated into bit level octet strings before being passed to the Presentation layer [53]. The abstract syntax used by V T is called Abstract Syntax Notation One (ASN.l) [38] which currently has only one transfer syntax, called the Basic Encoding Rules (BER) [42]. Because of the complex nature of V T protocol elements, an A S N . l to CHAPTER 3. THE ISO VTP IMPLEMENTATION 72 C compiler has been used to ease the task of writing translation functions for the B E R . This compiler was also developed at the Department of Computer Science at the University of British Columbia [55]. Input to the compiler is the specification of P D U structures in A S N . l syntax, while outputs from compiler consists of the equivalent P D U structures in C syntax, a set of encoding functions which translate PDUs in C syntax into A S N . l syntax, and a set of decoding functions which translate PDUs from A S N . l syntax to C syntax. Complete description of this compiler can be found in [55]. Table 3.2 contains the size of each of the input and output files in term of lines, to illustrate the effort required to develop these translation functions if they were to be done by hand. Appendix B contains the complete listing of the input file. Some input file pdu structures in A S N . l syntax 775 lines output files pdu structures in C syntax 1582 lines encoding functions 2726 lines decoding functions 3002 lines Table 3.2: Size of Input and Output Files for A S N . l - C Compiler modification has been done inside the original definition given by the V T standard [49] due to the restrictions of the compiler and errors in the definition itself. A complete explanation can also be found in Appendix B . CHAPTER 3. THE ISO VTP IMPLEMENTATION 73 3 . 6 D u m m y A C S E a n d P r e s e n t a t i o n l a y e r In the ubcVTP implementation, the A C S E and Presentation layer is not distinct and is not ISO-standard. In fact, there is no actual functionality within this layer, it merely acts as an interface to the lower layers. Since the use of ubcVTP is very restric-tive, many of the Session layer's functional units are not required and therefore, it is also omitted. Thus, the top most layer underneath the ubcVTP is the Transport layer, specifically the A R P A N E T Transmission Control Protocol/Internet Protocol (TCP/ IP) (see Figure 3.2). The interface provided by the combined A C S E and Presentation layer makes use of T C P / I P stream sockets supported by UNLX 4.2 BSD. The Transport layer offers reliable connection service, facilitating the establishment of a connection over which the two V T entities communicate. Chapter 4 Related Work At this time, there is no other implementation for the ISO Basic Class V T P . There have been projects undertaken to implement a Form Class terminal protocol that allows users to define fields on the screen, and to read or write a single field at a time. They are the Simple Screen Management Protocol (SSMP) defined by the University of Newcastle [21,20] and the Full Screen Access Protocol("Tam Ekran Erisim Protokolii" or T E E P ) [7] defined by the Middle East Technical University. However, these terminal protocols are not ISO standards (as defined by [43,44]), although they utilize some of the concepts or abstract operations defined by ISO V T P . Thus, instead of comparing implementations, we will compare the ISO V T P with other terminal protocols developed by other standards organizations. We have selected the two most widely used terminal protocols, namely the A R P A N E T T E L N E T [1] protocol and C C I T T P A D facility (the X .3 , X.28 and X.29 protocol suite) [14,12,17]. The T E L N E T protocol was orginally defined in 1972 for use on the A R P A N E T . It 74 CHAPTER 4. RELATED WORK 75 was updated and was widely used on the A R P A N E T by 1977, and became a military standard in 1984 [31]. P A D was first proposed by the C C I T T committee in 1977 to allow simple terminal devices to be connected directly to an X.25 [13] packet switching network. Subsequently, it was updated every four years to accomodate more facilities and is still widely used today [9]. Although all of these protocols provide services to allow a user using traditional terminal devices to communicate with remote application processes through a computer communication network, the way to describe a terminal's characteristics and its services are different in the three protocols. As a result, we have selected the following criteria to make our comparison more systematic : • T e r m i n a l Type . What type of terminal is supported by the protocol and how are the terminal characteristics represented? • Opera t ion M o d e . What mode of operation is supported by the terminal pro-tocol, asychronous, synchronous or both? • D a t a De l ive ry C o n t r o l . Does the protocol allow users to control when data are delivered to the peer? • Addres s ing C a p a b i l i t y . Does the protocol provide facilities to allow the remote application process to control cursor movement on the local terminal? • E r a s i n g C a p a b i l i t y . Does the protocol allow the user to erase input data? CHAPTER 4. RELATED WORK 76 • At t r ibute support. What rendition attributes such as emphasis, colour or font, are support by the protocol? Does the protocol allow the user to change the rendition attribute associated with a character on the terminal screen? • Echoing Control . Does the protocol allow remote application processes to control local echoing? • Interrupt handling. Can the protocol handle interrupt signals? • Negotiation. Does the terminal protocol have a negotiation facility to extend its services and to modify the description of the real device? Terminal T y p e Both T E L N E T and P A D can support line mode and scroll mode type terminals. In addition to these, V T P can support page mode type terminals. Both T E L N E T and V T P can be extended to cover Form mode type terminals. The Data Entry Terminal option in T E L N E T allows its Network Virtual Terminal 1 to be modified to support Form mode type terminals, while the extended facility set in Basic class V T P turns the V T P into Form class to support this terminal mode. V T P defines a Virtual Terminal to model terminal characteristic in an abstract way. Mapping functions must be provided to map this abstract format into their local 'we will explain this in a moment CHAPTER 4. RELATED WORK 77 representation. Control signals are represented by updates to the virtual terminal. T E L N E T uses a similar approach by denning a Network Virtual Terminal(NVT) that all implementations must support. The N V T does not really exist, since all terminal characteristics are represented by the T E L N E T options. Commands in T E L N E T are used to provide the N V T control functions. Some of these commands and options are shown in Table 4.1 2 . Since T E L N E T commands are sent interspersed with user data, TELNET Commands TELENET Options Command name Abbrev. End of Subnegotiation SE Binary Transmission N O P Echo Data Mark D M Reconnection Break B R K Suppress Go Ahead Interrupt Process IP Approximate Message Size Are you there A Y T Status Erase Character E C Timing Mark Erase Line E L Output line width Go Ahead G A Output horizontal tab stops Begin subnegotiation SB Output vertical tab stops W I L L Extended ASCII W O N T Logout DO Data Entry Terminal D O N T Terminal type Interpret As Command IAC Table 4.1: T E L N E T Commands and Options all commands are preceded by a special character, I A C , so that they can be recognized. P A D uses a set of parameters to describe the characteristics of the real device (as Complete option list can be found in [2] which is reprinted in [l] CHAPTER 4. RELATED WORK 78 specified in X.3 [14]). These parameters also describe the operations of P A D and are reproduced in Table 4.2. Control signals sent from terminal users are represented in P A D command singals as specified in X.28 [12], while control signal sent from the application process are represented in P A D messages as specified in X.29 [17]. M o d e of Operat ion P A D can only be operated in asynchronous mode, while both T E L N E T and V T P can support asynchronous as well as synchronous modes of operations. To distinguish between asychronous and synchronous mode, T E L N E T uses an option called Suppress Go Ahead to indicate asychronous mode is in effect. This option also disables the command Go Ahead (similar to a token) which is used to control whose turn it is to transmit data when communication is in synchronous mode. The use of the command Go Ahead is quite confusing in T E L N E T , there are no strict controls over when or how this command is used. According to the specification, the application side T E L N E T can assume an implicit Go Ahead at the end of each input line ( signalled by a carriage return and line feed) sent from the user side T E L N E T . Thus, this command is mainly used by the application process to give up the channel access right. This is ususally not acceptable for terminals which allow users to input multiple lines of data to an application process. In contrast, V T P handles synchronous terminals better than T E L N E T . The V T E -CHAPTER 4. RELATED WORK Number Description 1 Whether terminal operator can escape from data transfer to P A D command state 2 Whether P A D echoes back characters received from terminal 3 Terminal characters that will trigger the sending of a partially full packet by the P A D 4 Timeout value that will trigger the sending of a partially full packet by the P A D 5 Whether P A D can exercise flow control over terminal output, using X - O N , X - O F F 6 Whether P A D can send service signals (control information) to terminal 7 Action(s) taken by P A D on receipt of break signal from terminal 8 Whether P A D wil l discard D T E data intended for terminal 9 Number of padding characters inserted after carraige return (to terminal) 10 Whether P A D inserts control characters to prevent terminal line line overflow 11 Terminal speed(bps) 12 Whether terminal can exercise flow control over P A D , using X - O N , X - O F F 13 Whether P A D inserts line feed after carriage return sent or echoed to terminal 14 Number of padding characters inserted after line feed (to terminal) 15 Whether P A D supports editing during data transfer (denned in parameters 16-18) 16 Character delete 17 Line delete 18 Line display 19 Terminal type for editing P A D service signal (e.g., character delete) 20 Characters that are not echoed to terminal when echo is enabled 21 Parity treatment of characters to/from terminal 22 Number of lines to be displayed at one time Table 4.2: P A D Parameters (X.3) CHAPTER 4. RELATED WORK 80 parameter mode-of-operation and the access-right on the display object(s) clearly in-dicate the mode of operation. Further, the token management facility allows either V T user to request and relinquish the token. The protocol also specifies strict rules on usage of the token, including when the token may be implicitly transferred to the peer user to enforce even sharing of the communication channel by the two V T users 3 . D a t a Delivery Contro l Data Delivery control in T E L N E T is achieved by using the T E L N E T option Timing Mark [32]. It allows a user at one end of the connection to mark a point in the data stream where he wishes to be' sure that all previously transmitted data has been processed. The DO Timing Mark command marks this point in the data stream. A W I L L Timing Mark is sent in response indicating all data, up to and including the DO Timing Mark, has been processed. A W O N T Timing Mark response indicates all previously transmitted data has been received, but not yet processed. P A D uses two parameters to achieve the effect of data delivery control. The first parameter specifies a character which will trigger the P A D to forward an X.25 packet. Usually P A D will buffer user input until the X.25 packet is completely filled. When this character is received by P A D , it will transmit the X.25 packet even if it is only partially full. Another parameter provides a similar effect by specifying a timeout value 3DIS 9040 has descriptions of when the token will be implicitly transferred. CHAPTER 4. RELATED WORK 81 that wil l trigger the sending of a partially full packet by the P A D upon expiry. V T P contains both types of delivery control provided by T E L N E T and P A D . The VT-DELIVER.request service primitive with acknowledgement required, and the V T -ACK-RECEIPT.reques t service primitive perform the same function as DO Timing Mark and W I L L Timing Mark. The termination conditions provided by the Device Object parameters have the same effect as the P A D parameters with the extra capability of specifying the user input data length that will trigger data delivery. One type of delivery control provided by V T P that cannot be handled by the other two protocols is quarantine delivery control. In this type of control, data are not delivered until the local user explicitly sends out a request. Thus input data can be edited before delivery to produce net-effecting. Addressing Capabi l i ty Neither T E L N E T nor P A D support any addressing operations. Although both of them support scrolling terminals, characters can only be entered in a sequential forwarding manner. Further, no function is provided to map control sequences for cursor movement, which may be generated by remote applications, into the terminal's local representation. To control cursor movement on the screen, both protocols simply pass the uninterpreted control sequences to the local terminal. By doing this, the terminal characteristics for handling cursor movement have to be matched with those CHAPTER 4. RELATED WORK 82 expected by the application process. In contrast, V T P provides a rich set of addressing operations. Any terminal dependent control sequence for cursor movement can be represented by the addressing operation on display object. For example, cursor up, down, left and right can be mapped on to relative-addressing operation and direct cursor movement can be mapped on to absolute-addressing operation. Erasing Capabi l i ty T E L N E T and P A D only allow users to erase the previous character and current line. T E L N E T provides two commands, Erase Character(EC) and Erase Line(EL), to erase the previous character and current line, while P A D contains two parameters, Character Delete and Line Delete, to specify what characters, when received by the P A D , wil l cause P A D to perform the corresponding erase functions. V T P provides a more flexible erase operation than those provided by the other two protocols. The operation uses two parameters to mark the beginning and the ending of a block of text that is to be erased. Thus, a single operation can erase a character, a line, a few lines or even the complete screen. Attr ibute Support T E L N E T can only support one character set. Normal user data are represented using the 7 bit ASCII character set while commands are represented by 8 bits to CHAPTER 4. RELATED WORK 83 distinguish them from user data. P A D uses C C I T T International Alphabet No.5 which is a variant of ASCII codes to represent all data sent between the terminal and the P A D , and also between P A D and the remote system that contains the application process. Colour, emphasis or font are not supported by either of these protocols. A l l of these attributes have to be device dependent, therefore no command or parameter can specify how rendition attributes on the screen can be changed. In contrast, every character transmitted by V T P can have its own font, colour (both foreground and background) or emphasis level. Further, each character can be selected from a different character set which is independent of the others. The single operation attribute, provided by V T P can be used to change the attribute associated not only with a character, but also with a block of characters or even with a page on the screen. Echoing Contro l A l l three protocols provide some mechanism to allow a remote application to control local echoing. In P A D , an echo parameter can be set by the remote application to indicate that P A D should echo back all user input data. It also provides a echo mask to specify what characters should or should not be echoed back. In V T P , a E C H O control object is denned for the remote application. When the content of this control object is set (true), the local V T implementation should start echoing user input data. T E L N E T uses an option called Echo to indicate when local echoing is in effect, however, the usage CHAPTER 4. RELATED WORK 84 of this echo mechanism is different from the two just described. In the previous two protocols, defaults for the echo parameter and echo control object are false, meaning no local echoing. When remote applications want input to be echoed locally, they set the parameter or control object to true. In T E L N E T , the default is to have user input echoed locally. If the remote application process requires local echoing, it simply does nothing. When the remote application wants to take over the echoing task (remote echoing), it will select the Echo option to indicate that echoing should now be done remotely. Interrupt A l l three protocols support some kind of interrupt signal which can be generated by either side of the connection. Out-of-band facilities are also available to transmit these signals across the network as quickly as possible. T E L N E T has three commands to represent three different types of interrupt signals. The first is the Break command which provides a signal outside the ASCII character set to represent the Break or Attention signal available on many systems. The second is the Interrupt Process command which allows the local user to interrupt the operation of a remote process. The third is the Abort Output command which allows a process to run to completion without sending any output to the user's terminal. A l l of these commands can be sent either in the data stream (like all other T E L N E T commands) or CHAPTER 4. RELATED WORK 85 with a Synch signal (out-of-band signal). To send an out-of-band signal, T E L N E T sends the appropriate T E L N E T command followed by the Data Mark sequence (IAC DM) as T C P Urgent data. When T E L N E T receives a T C P Urgent notification, it continues to scan the data stream for T E L N E T commands and processes them, but throws away any user data. This continues until the Data Mark is found, where processing returns to normal. Although the V T P only provides a Break facility to represent the break signal, other interrupt or control signals can be represented using control object. As a matter of fact, any control information can be represented by a control object as long as its semantics are made known to both communicating parties. Using urgent priority on updates to these control objects allows signals to be sent in an out-of-band fasion. In P A D , both terminal user and application processes can send interrupt and break. On the terminal side, the user requests an interrupt by sending the interrupt P A D command signal ( as specified in X.28 [12]) to the P A D . Upon receiving this command, the P A D wil l send an X.25 interrupt packet to the remote system. The user information field in the interrupt packet can be used to provide extra information to specify the type of interrupt. To handle a break signal from the user keyboard, P A D specifies a set possible actions, as described in parameter 7 of P A D (see Table 4.2), that generate an X.25 interrupt packet and may or may not be followed by the indication of break P A D message (to the application process). On the application side, there is no explicit command to generate an interrupt, but since the application process is using the X.25 CHAPTER 4. RELATED WORK 86 protocol to communicate with the P A D , it can always generate an appropriate call to the packet layer of X.25 to request an interrupt packet to be sent. For the break signal, the application process sends out an "indication of break" P A D message to the P A D . When the P A D receives such a message, it generates a break signal on the user's terminal. According to X.25 recommendations, no interrupt packets are subject to flow control and they are always sent in head of the queue fashion. However, the break message may not bypass all other user data, since it is sent as an X.25 data packet with the Q bit set to 1 to indicate that the packet contains control information (see [13] for further explanation on packet format and Q-bit). Negotiation T E L N E T and V T P both provide nogotiation facilities for users. Negotiation in T E L N E T is achieved by the four commands W I L L , W O N T , DO and D O N T (We have already seen some of their use in subsection Data Delivery Control). W I L L X is used to indicate that the sender would like to enable option X (an offer); DO X and D O N T X are the positive and negative response respectively. Similarly, DO X is sent to indicate that the sender would like the other side to enable option X (a request); W I L L X and W O N T X are the positive and negative acknowledgments. For example, if the remote application process would like use the binary transmission option 4, it will 4This option is similar to the transparent mode of VTP where all characters are sent uninterpreted CHAPTER 4. RELATED WORK 87 send the T E L N E T command "WILL Binary Transmission" to the terminal user. If the terminal user agrees to the option, it will send back the command "DO Binary Transmission". This kind of negotiation mechanism is quite smiliar to the Multiple Interaction Negotiation in V T P . Another negotiation mechanism in T E L N E T which resembles the effect of Switch Profile Negotiation (although it can not achieve the same effect as V T P by a single command interaction), allows the user to replace the definition of the N V T on a T E L N E T connection. A good example of this is the Data Entry Terminal (DET) option which is used to model a form mode type terminal. Once the option has been negotiated (using the four negotiation commands explained above), both users can use subnegotiation commands Begin Subnegotiation (SB) and End Subnegotiation (SE) to define the form mode facilities for editing, erasing, data transmission, and formatting. Further discussion of using subnegotiation on form mode terminals can be found in [31]. For P A D , there is no negotiation facility available. Although both user and appli-cation process can set and read PAD's parameters, most of the time these parameters wil l only be set by one side and never be changed by the other side. Further, most of the parameters are used to describe terminal characteristics, and thus will only be set by the terminal user. For example, parameters for the terminal's transmission speed, number of padding characters inserted after carriage return, character for line delete, etc., are all set by the terminal user to be read by the application process. CHAPTER 4. RELATED WORK 88 Although these comparisons are quite primitive, they illustrate that V T P provides better support to sophisticated terminals than the other two protocols. There are no features in the other two protocols that cannot be mapped onto V T P service facilities or V T E parameters. If no direct mapping exists, a control object can always be defined to represent the necessary information. For example, we can define a boolean type control objects to represent the T E L N E T command Abort Output, one for each direction of data flow. When a user wants to send an Abort Output signal to the remote application process, it can simply update the content of this control object to true. When the mapping function on the application side receives such an update, it will translate it back into an Abort Output signal and send it to the application process. Parameters in P A D can be represented in a similar way. For the interested reader, Sue McLeod and Kathleen Huber [32] has presented a V T profile that wil l replicate most of the features in T E L N E T and the ISO standard itself [46] contains a registered profile, mboxvt-b-rpr-a6, to provide support for X.3 PAD compatible operation for users of the ISO Virtual Terminal Service. Chapter 5 Conclusion 5 . 1 S u m m a r y Remote terminal access through computer network has long been a problem because of the diversities in terminal types and host types. The Basic Class Virtual Terminal Protocol (VTP) developed by the International Standard Organisation (ISO) provides a solution to this by defining a virtual terminal which is an abstract representation of the real terminal for the remote host and a local terminal user to communicate with. This thesis report provides a detailed description of the virtual terminal protocol contained in the two ISO documents DIS 9040 [46] and DIS 9041 [49]. Inconsistencies and errors found in the documents during the study warrant further revisions of the documents. A comparative study of other terminal protocols is also presented here, in order to see which capabilities of the ISO V T P are not found in other terminal protocols, and furthermore to determine whether the ISO V T P can replicate the capabilities of other protocols. Finally, an implementation of a useful subset of the ISO V T P on the UNLX 89 CHAPTER 5. CONCLUSION 90 operating system is presented. In this thesis we defined a new virtual terminal profile which is different from the ones described in the standard. Our profile is more suitable for use inside the UNIX operating system environment. The implementation consists of several parts. They are: • the interface to the UNIX operating system, • the mapping between output of the application and that of the terminal to the V T abstract operation, and vice versa, • the virtual terminal protocol machine that controls the communication dialogue between two V T service users, • the translation of the V T PDUs in ASN. l syntax to and from C syntax, and • the interface to the lower layer, in particular, the transport layer provided by the Transmission Control Protocol (TCP) in UNLX. We believe that the experience we gained in implementing the ISO V T P on the UNIX operating system as documented in this thesis, will be valuable to other people who plan to implement V T P in the future. CHAPTERS. CONCLUSION 91 5.2 Possible improvement Several improvement on ubcVTP is taken into consideration. The first one is to ask whether the local echoing mechanism of V T P is workable under the U N I X environment. With remote echoing1 , the ubcVTP (and all other terminal protocols) will send each character to the host as soon as it has been typed, in order for it to be echoed back onto the local screen. Otherwise if this is not done, user will not see what was typed. The overhead cost to transmit each single character packet is very high. According to our measurement, the P D U size to transmit a single character (using the text operation) is twenty bytes. The extra nineteen bytes are used by A S N . l to contain the type definition of the P D U . Since this single character must traverse the network twice, the total overhead will be thirty-eight bytes. In additon, any delay within the network will make such response time 2 very poor. However, if local echoing is turned on, users' input do not need to traverse the network twice, thus reducing some of the overhead. As a result, reponse time is guaranteed to be improved since this is locally taken care of. Another advantage of having local echoing is that net-effecting can be applied to user input. Because the problem of remote echoing does not exist when user input is echoed locally, user input can be temporary stored in the client-LMF. In such cases, the 1 Since UNIX system only support asynchronous terminal, all echoing are done remotely. 2reponse time here means how long a user has to wait for a character to be displayed on the screen when it is typed from the keyboard. CHAPTER 5. CONCLUSION 92 user input can be edited such as combining several updates into a single one, before being transmitted to the peer user. Network traffic should obviously be reduced if this secheme is employed. However, we have difficulty in implementing local echoing under the UNIX environment, even though the standard has a full explanation on how local echoing can be done with V T P 3 . The major problem is that the server-LMF does not know when the application process wants or does not want the user's input to be echoed. For example, the user password should not be echoed back on the screen when runnning a login application. The pty will not generate any signal to the server-LMF, when its echoing capability is toggled by the application process. Without this kind of information, the server-LMF cannot send appropriate updates to the ECHO control object to toggle the local echoing mechanism inside the client-LMF. Another problem with local echoing is that the semantics of key sequences defined by the remote application is no longer meaningful in the local system. For example, when Emacs receives the control-P character, it knows a control sequence for moving the cusor up one line has to be sent to the local terminal. However, if this control-P character is echoed locally, it will mean nothing to the terminal. Most likely, the character control-P will be displayed on the screen rather than moving the cursor. One possible solution to this is to define a set of standard key-bindings for the local editing 3Besides the ECHO control object, the standard also specifies an echo control algorithm to help coordinate local echo output with normal output form application. CHAPTER 5. CONCLUSION 93 functions that can be used on any terminal. However, by doing this, ubcVTP will no longer be transparent to the user. Besides, the capability of the remote application may degrade since it is difficult to have a single set of keybindings that meets the needs of all applications. A l l of these issue must be resolved before ubcVTP can be made more efficient. Another possible improvement is to make ubcVTP support more character sets than simply ASCII code. It seems that it is not too difficult to do. The character set designing escape sequences for the new character set can be denned in the parameter repertoire-assignment of the display object. When an application selects a new char-acter set using escape sequence like Shift-Out (SO) or Locking Shift-Out One (LSI) [34], the keymap in the server-LMF should be able to translate the escape sequence into the attribute updates of the display object. The character set is identified by its relative position in the repertoire assignment4. When the client-LMF receives such an update, it will translate it back into an escape sequence that wil l change the currently used character set on the local terminal. 5 . 3 Future Research Since the requirement of the virtual terminal protocol is a moving target, a V T P that is sufficient to support today's terminal technology may not be adequate for tomor-4Repertoire assignment is a list itself CHAPTER 5. CONCLUSION 94 row's need. Thus, research is undergoing to explore different class of V T P for different class of terminal devices. According to the Generic Virtual Terminal Service and Pro-tocol Description [4], a virtual terminal protocol can be classified into Basic Class, Form Class, Image Class, Graphic Class and Mixed-Mode Class. Basic Class has just been described in this thesis report. The Form Class V T P is intended to support form filling type terminals (or data entry terminals) in which individual fields can be defined on the screen to accept user data. Restriction such as numeric only or invisible only, can also be applied to individual fields. Usually, the whole screen (the whole form) is transmitted between the host and the user's terminal (similar to page mode terminal). The ISO documents DIS 9040 D A D 1 [43] and DIS 9041 DAD1 [44] describe the service and protocol for this class of V T P . ISO is intended to merge these two documents with those for the Basic Class. Thus, future Basic Class V T P will be more sophisticated and will not be "basic" anymore. The Image Class V T P is intended to support Bit Map Graphic terminal such as those used in the micro-computers. Graphic Class V T P is intended to support Raster Graphic terminals such as those used for professional workstations. Both Image Class and Graphic Class V T P would allow users to create multiple windows on the terminal screen with possible overlapping capability. The last one, Mixed-Mode Class is the combination of all other classes. This class of V T P would not exist until all other classes of V T P are fully defined. Up to now, there still has been no proposal made by the standard committe for Image Class or Graphic Class, CHAPTER 5. CONCLUSION 95 and this problem definitely deserves future research. Sunyound Han and SunWan Choi [24] have proposed a Window Class virtual terminal model that allow users to create multiple windows on the screen with the capability to support both text and graphic within the same window. However, only the capabilities of the model are described, the actual structure of the various abstract objects or the format of its services have not been mentioned. Further research on these areas needs to be explored before the Window Class V T P can be implemented. B i b l i o g r a p h y Defense Communications Agency. DDN Protocol Handbook. Menlo Park, C A , D E C . 1985. Defense Communications Agency. Militray Standard TELNET Protocol. M I L -STD-1782, May 1984. European Computer Manufacturers Association. Basic Class Virtual Terminal Service Description and Protocol Description. ECMA-88 , Mar. 1988. European Computer Manufacturers Association. Generic Virtual Terminal Ser-vice and Protocol Description. ECMA-87 , Mar. 1987. Paul D. Bartou. The Application Layer of the Reference Model of Open Systems Interconnections. Proceeding of the IEEE, 71(12):1404-1407, Dec. 1983. A . Bastable, D . M . Ireland, and A . Langsford. Building an Open Communication Application. Software Engineering, 2(5):178-183, 1987. Semih Bilgen, Mustafa Aykut, and Orkun Ekinci. A Forms Class Virtual Terminal Service Project. Computer Networks and ISDN Systems, 305-309, 1987. David Chappel. The Virtual Terminal Protocol. Open Systems Data Transfer, Omnicom Information Service Transmission # 29, Aug. 1987. John D. Day. Terminal Protocols. IEEE Transations on Communications, com-28(4), Apr . 1980. Comite Consultatif et Internationale de Telegraphique et Telephonique. Assicia-tion Control Protocol Specification for Open Systems Interconnection for CCITT Applications. C C I T T Recommendation X.227, 1988. Comite Consultatif et Internationale de Telegraphique et Telephonique. Asso-ciation Control Service Definition for Open Systems Interconnection for CCITT Applications. C C I T T Recommendation X.217, 1988. 96 BIBLIOGRAPHY 97 [12] Comite Consultatif et Internationale de Telegraphique et Telephonique. D T E / D C E Interface For A Start-Stop Mode Data Terminal Equipment Accessing The Packet Assembly/Disassembly Facility (PAD) In A Public Data Network Sit-uated In The Same Country. In CCITT Red Book, Volumn VIII - Fascicle VIII.S, C C I T T Recommendation X.28, Oct. 1984. [13] Comite Consultatif et Internationale de Telegraphique et Telephonique. Inter-face Between Data Terminal Equipment (DTE) A N D D A T A Circuit-Terminating Equipment (DCE) For Terminals Operating In The Packet Mode And Connected To Public Data Networks By Dedicated Circuit. In CCITT Red Book, Volumn VIII - Fascicle VIII.S, C C I T T Recommendation X.25, Oct. 1984. [14] Comite Consultatif et Internationale de Tefegraphique et Telephonique. Packet Assembly/Disassembly Facility (PAD) in a Public Data Network. In CCITT Red Book, Volumn VIII - Fascicle VIII.S, C C I T T Recommendation X . 3 , Oct. 1984. [15] Comite Consultatif et Internationale de Telegraphique et Telephonique. Presen-tation Protocol Definition for Open Systems Interconnection for CCITT Applica-tions. C C I T T Recommendation X.226, 1988. [16] Comite Consultatif et Internationale de Telegraphique et Telephonique. Presenta-tion Service Definition for Open Systems Interconnection for CCITT Applications. C C I T T Recommendation X.216, 1988. [17] Comite Consultatif et Internationale de Telegraphique et Telephonique. Procedure For The Exchange Of Control Information And User Data Between A Packet As-sembly/Disassembly (PAD) Facility And A Packet Mode D T E Or Another P A D . In CCITT Red Book, Volumn VIII - Fascicle VIII.S, C C I T T Recommendation X.29, Oct. 1984. [18] Comity Consultatif et Internationale de Telegraphique et Telephonique. Session Protocol Definition for Open Systems Interconnection for CCITT Applications. C C I T T Recommendation X.225, 1988. [19] Comite Consultatif et Internationale de Telegraphique et Telephonique. Ses-sion Service Definition for Open Systems Interconnection for CCITT Applications. C C I T T Recommendation X.215, 1988. [20] Brian Gilmore. A User View Layer of Virtual Terminal Standarlization. Computer Network and ISDN systems, 13(3):229-233, 1984. BIBLIOGRAPHY 98 [21] Brian Gilmore. ISO Directions in V T P . In International Open Systems' 87, pages 255-263, 1987. [22] Computer Systems Research Group. UNIX Programmer's Reference Manual. Computer Science Division, Department of Electrical Engineering and Computer Science, University of California, Berkeley, California, Apr. 1986. [23] Fred Halsall. Data Communications, Computer Networks and OSI. Addision-Wesley Publishing Company, second edition, 1988. [24] Sunyoung Han and Sunwan Choi. Window Class Virtual Terminals. In Pacific Computer Communications' 85, pages 405-407, 1985. [25] John Larmonth. Common Application Service Element (CASE) Standardlization. Open Systems Data Transfer, Omnicom Information Service Transmission # 19, Dec. 1985. [26] S. Leffler, R. Fabry, W. Joy, P. Lapsley, S. Miller, and C. Torek. An advanced 4.3 BSD Interprocess Communication Tutorial. U N I X Programmer's Supplementary Documents, Volumn 1. Computer Systems Research Group, Computer Science Division, Department of Electrical Engineering and Computer Science, University of California, Berkeley, California, Apr. 1986. [27] Henry A . Lowe. OSI Virtual Terminal Service. Proceeding of the IEEE, 71(12):1408-1413, Dec. 1986. [28] Henry A . Lowe. The ISO Virtual Terminal Service and Protocol. In International Open Systems' 86, pages 91-97, 1986. [29] F . Magnee, A . Endrizzi, and J . Day. A Survey of Terminal Protocols. Computer Networks, 299-314, 1979. [30] Lee Mantelman. Upper Layer: From bizarre to bazaar. Data Communication, 110-128, Jan. 1988. [31] Sue McLeod. T E L N E T . In Handbook of Computer Communications Standards, Volume 3:Department of Defense (DOD) Protocol Standards, Macmillan Publish-ing Company, 1988. [32] Sue McLeod and Kathleen Huber. ISO Virtual Terminal Protocol and its Re-lationship to M I L - S T D T E L N E T . In Proceedings of The Computer Networking Symposium, pages 110-119, 1986. BIBLIOGRAPHY 99 [33] International Standards Organization. Data Processing - Procedure for Registra-tion of Escape Sequence, 3 r d Version. ISO IS 2375, Nov. 1985. [34] International Standards Organization. Information Processing Systems - ISO 7-bit and 8-bit Coded character Sets - Control Functions for Coded Character Sets. ISO DIS 6429, May. 1987. [35] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Abstract Syntax Notation One (ASN.l). Proposed Draft Addendum 1: Extensions to ASN.l Basic Encoding Rules. ISO IS 8824 P D A D 1, Dec. 1987. [36] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Protocol Specification for ACSE. ISO DIS 8650, May. 1986. [37] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Service Conventions. ISO T R 8509, Sep. 1987. [38] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.l). ISO IS 8824, May 1987. [39] International Standards Organization. Information Processing Systems - Open Systems Interconnection - ISO 7-bit and 8-bit Coded Character Sets, Code Exten-sion Techniques, 3rd Version. ISO IS 2022, May. 1986. [40] International Standards Organization. Information Processing Systems - Open Systems Interconnection - ISO 7-bit Coded Character Sets for Information Inter-change, 2nd Version. ISO IS 646, Jul. 1983. [41] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Abstract Syntax Notation One (ASN.l). Proposed Draft Addendum 1: Extensions to ASN.l. ISO IS 8824 P D A D 1, Dec. 1987. [42] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syn-tax Notation One (ASN.l). ISO IS 8825, May 1987. [43] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Virtual Terminal Service, Draft Addendum on Extended Faculty Set. ISO DIS 9040 D A D 1, Nov. 1987. BIBLIOGRAPHY 100 [44] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Virtual Terminal Protocol, Addendum 1: Extended Fac-ulty Set. ISO DIS 9041 D A D 1, Dec. 1987. [45] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Service Definition for ACSE. ISO DIS 8649, Jun. 1986. [46] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Virtual Terminal Service, Basic Class, 2nd Version. ISO DIS 9040.2, Oct. 1987. [47] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Application Layer Structure (ALS). ISO D P 9545, Nov. 1987. [48] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Basic Reference Model. ISO IS 7498, Oct. 1984. [49] International Standards Organization. Information Processing Systems - Open Systems Interconnection - Virtual Terminal Protocol, Basic Class, 2nd Version. ISO DIS 9041.2, Oct. 1987. [50] Evelyne Roux. OSI's Final Frontier: The Application Layer. Data Communica-tion, Jan. 1988. [51] Stuart Sechrest. An Introductory 4-3 BSD Interprocess Communication Tutorial. U N I X Programmer's Supplementary Documents, Volumn 1. Computer Systems Research Group, Computer Science Division, Department of Electrical Engineering and Computer Science, University of California, Berkeley, California, Apr . 1986. [52] John B . Stephensen. Practical Issues in OSI Technology Implementations. In International Open Systems' 86, pages 149-103, 1986. [53] G . J . Taylor. Representaion of User Data in the Presentation Layer. In Interna-tional Open Systems' 87, pages 293-304, 1987. [54] Steve Wendler. Implementation of Open Systems: an Architectural Approach. In International Open Systems' 86, pages 165-175, 1986. [55] Yueli Yang. An Implemention of ASN.l-C Compiler. Master's thesis, Department of Computer Science, University of British Columbia, Oct. 1988. A p p e n d i x A u b c V T P P r i v a t e P r o f i l e Pro f i l e v t -b -ppr -a l ( r l , r2) Display-object *(double occurrence)* { display-object-name = ' ' d i s p l a y ' ' object -access-r ight = WACA, dimension = 2, x-dimension = { x-bound = prof i le -argument- r l , * ( l ine- length) * x-addressing = ' 'no c o n s t r a i n t , x-absolute = ' ' y e s ' ' , *(x-window by default equal to x-bound)* } , y-dimension = { y-bound = ' 'unbound' ' , * (defaul t ) * y-addressing = ' 'no c o n s t r a i n t ' ' , y-absolute = ' ' y e s ' ' , y-window = profile-argument-r2 *(page length)* }, erasure-capabi l i ty = ' ' y e s ' ' , emphasis-capabil ity = 5, emphasis-assignment = { ' ' n o r m a l ' ' , ' ' B o l d ' ' , ' ' u n d e r l i n e d ' ' , ' ' B l i n k i n g » » . " reverseVideo " >, 101 APPENDIX A . UBCVTP PRIVATE PROFILE 102 * ( a l l other at t r ibutes assume the i r default values)* display-object-name = ' 'keyboard * *, object -access-r ight = WACI, dimensions = 1, x-dimension = { x-addressing = ' 'not permi t ted ' ' , *(only i m p l i c i t forward sequential i s avai lable) * *(x-bound, x-absolute, and x-window assume defaul t ) * >, * ( a l l other at t r ibutes assume default values)* }. Control-objects * (s ingle occurrence)* < CO-name = "INDEL' », CO-type- ident i f ier = ' ' i n d e l ' ' , CO-access = WACA, CO-category = boolean, * (defaul t ) * CO-size = 4 >, Device-objects * (s ingle occurrence)* {. device-name = ' ' d i s p l a y - d e v i c e , device-display-object = ' ' d i s p l a y ' ' , device-defaul t -co-access = WACA, dev ice -de fau l t -co - in i t i a l - va lue = ' ' t r u e * ' , * ( i n i t i a l l y ' ' o n ' ' ) * device-control -object = ' ' INDEL ' ' , device-minimum-X-array-length = prof i le -argument- r l , device-minimum-Y-array-length = profile-argument-r2, * ( a l l other device parameters assume default values or are not required )* >, *(no device object i s associated with the keyboard display object)* A p p e n d i x B A S N . l D e f i n i t i o n s o f P D U s fo r V T P This appendix contains the modified A S N . l definitions for protocol data units for ISO V T P . The modifications are identified by three different symbols. Lines that are marked with asterisk(*) mean the variable name or type name on that line has been modified. There are several reasons for these changes: (i) a typing error was found in the original definition, (ii) the original name is used inconsistently in the definition, (iii) the current A S N . l - C compiler cannot handle the case in which a single type name is used to refer to different structures within different modules. Lines that are marked with ' X ' mean the original constructor type definition has been expanded into two simpler data types. For example, the type definition CDSoffer ::= SET OF SEQUENCE -fobjectName P r i n t a b l e S t r i n g , objOffer DisplayObjectOffer> has been expanded into the following two data types: 103 APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 104 CDSoffer ::= SET OF CDSoffSeq CDSoffSeq ::= SEQUENCE {objectName P r i n t a b l e S t r i n g , DisplayObj ectOffer} objOffer Actually, the A S N . l - C compiler will automatically break down complex data types, however, the new type names assigned by the compiler to the new data type are not very meaningful to the implementor. Thus, all complex data types are expanded before they are passed to the compiler. Finally, lines that are marked with E T n where n is an integer, mean an error was found in the original definition. Explanations to these errors are contained in Table B . l . Sometimes lines may be marked with more that one symbol, it means that those lines have undergone several changes. Some data types may not be defined in the same order as specified in the standard, because output from the A S N . l - C compiler is in C syntax and C requires all types be declared before being referenced. This ordering is not imposed by the A S N . l syntax. The reader is strongly recommended to compare the definitions in this appendix with those in the standard [49]. APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 105 Error Code Description TE1 Missing definition for PDU RLQ. Type for rlq-pdu is added. All tag numbers in type BasicVTPitem have to be re-adjustified. TE2 Keyword OPTIONAL is added because this variable is not required if the profile does not have any argument. TE3 Tag number and the keyword IMPLICIT for variable enr-reason are deleted because we cannot implicitly tag on a CHOICE type. Also, tag numbers inside type ENR-FailureReason are re-adjustified to avoid conflict with other tab numbers within type ENRcontent. TE4 Variable home is deleted from the original definition because operation home is not supported by VTP in its 2nd verison. After the deletion, all tag number within DOupdate are rejustified. TE5 Tag number and keyword IMPLICIT are deleted from variable ptr-absolute ptr-absolute because we cannot implicitly tag on a choice type. Tag numbers within type DOupdate require rejustification. TE6 Type Erase Type is deleted from origional definition because parameter to operation erase has changed. TE7 All tag numbers have been incremented by 10 to avoid conflict with other tag numbers in type DOupdate. TE8 variable endX is added to represent the special coordinate value endX. After the addition, tag numbers inside type Pointer must be rejustified. TE9 Keyword IMPLICIT is deleted because all referencing variables are already implicitly tagged. TE10 Both variables are implicitly tagged because variables must have distinct types inside a CHOICE type. TE11 Keyword IMPLICIT is deleted because no tag number is given in the original defintion and all referencing variables are already implicitly tagged. TE12 the value notPermitted is added for variable addressing. TE13 possible values for variable absolute have been changed to yes and no. TE14 type for variable absolute has been changed from INTEGER to BOOLEAN. Table B . l : Error code for A S N . l defintion of the V T P PDUs APPENDIX C. STATE TRANSITION DIAGRAMS Abnormal Release 126 +AUQ -VT-U-AROBT.ind +VT-U-Abort.req -AUQ Interrupt +BKR -VT-BREAK.conf +VT-BREAK.resp -BKR +VT-BREAK.req -BKR +BRK -VT-BREAK.ind APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 106 IS09041-VTP DEFINITIONS ::= BEGIN —++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ —+ ISO V i r t u a l Terminal Protocol Data Unit D e f i n i t i o n + —++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ BasicVTPitem ::= CHOICE { asq-pdu [0] IMPLICIT ASQcontent, asr-pdu [1] IMPLICIT ASRcontent, rlq-pdu [2] IMPLICIT NULL, --ET1 rlr- p d u [3] IMPLICIT RLRcontent, auq-pdu [4] IMPLICIT PrintableString, apq-pdu [5] IMPLICIT APQcontent, hdq-pdu [6] IMPLICIT SEQUENCE OF G.COupdate, — * ndq-pdu [7] IMPLICIT NDQcontent, udq-pdu [8] IMPLICIT SEQUENCE OF G.COupdate, --* bkq-pdu [9] IMPLICIT BKqcontent, bkr-pdu [10] IMPLICIT BKRcontent, dlq-pdu [11] IMPLICIT BOOLEAN, — true i f acknowledge required daq-pdu [12] IMPLICIT NULL, spq-pdu [13] IMPLICIT G.Profile, spr-pdu [14] IMPLICIT SPRcontent, snq-pdu [15] IMPLICIT G.Profile, snr-pdu [16] IMPLICIT SNRcontent, enq-pdu [17] IMPLICIT ENQcontent, enr-pdu [18] IMPLICIT ENRcontent, niq-pdu [19] IMPLICIT G.ParamldentList, noq-pdu [20] IMPLICIT G.ParamOfferList, naq-pdu [21] IMPLICIT G.ParamValueList, njq-pdu [22] IMPLICIT G.ParamldentList > APQcontent ::= INTEGER { protocol-errer (0), l o c a l - e r r e r (1) } ASQcontent ::- SEQUENCE { class [0] IMPLICIT INTEGER {basic (1)}, impld [1] IMPLICIT G.Implementationldent OPTIONAL, APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 107 f U n i t s [2] IMPLICIT G.FunctionalUnits, prof [3] IMPLICIT G.Profile OPTIONAL, proVeraion [4] IMPLICIT G.ProtocolVersion, —DEFAULT 'l'B, coWinner [5] IMPLICIT G.CollisionWinner OPTIONAL > ASRcontent SEQUENCE asr-reason as r - r e s u l t impld proVersion profArgValueList f U n i t s coWinner ASR-FailureReason OPTIONAL, [2] IMPLICIT G.Result3, [3] IMPLICIT G.Implementationldent OPTIONAL, [4] IMPLICIT G.ProtocolVersion, —DEFAULT 'l'B, [5] IMPLICIT G.ProfileArgumValueList OPTIONAL, • [6] IMPLICIT G.FunctionalUnits, [7] IMPLICIT G.CollisionWinner OPTIONAL > -ET2 ASR-FailureReason ::= CHOICE { userFailureReason [0] providerFailureResaon [1] IMPLICIT PrintableString, IMPLICIT INTEGER {. vte-param-not-supported (1) , vte-param-comb-not-supported (2), vte-incomplete (3), vt-prof ile-not-supported (4) )• } BKqcontent ::= SEQUENCE -C token INTEGER < i n i t i a t o r (0), acceptor (1), accChoice (2) > OPTIONAL, e x p l i c i t P t r G.ExplicitPointer > BKRcontent ::= SEQUENCE { token INTEGER { i n i t i a t o r (0), acceptor (1) } OPTIONAL, e x p l i c i t P t r G.ExplicitPointer }• ENQcontent ::= SEQUENCE { actionProposal [0] IMPLICIT BOOLEAN OPTIONAL, — true = "switch", f a l s e = "restore" actionRejectOptions [1] IMPLICIT BOOLEAN OPTIONAL > — true = "retain", f a l s e = "discard" APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 108 ENRcontent ::= SEQUENCE { enr-result [0] IMPLICIT G.Reault3, enr-reason ENR-FailureReason OPTIONAL, --* ET3 actionChoice BOOLEAN OPTIONAL > — true = "switched", f a l s e = "restored" — * ENR-FailureReason ::= CHOICE —ET3 { userFailureReason [1] IMPLICIT PrintableString, providerFailureReason [2] IMPLICIT INTEGER { vte-Incomplete (3)> } NDqcontent ::= SEQUENCE OF VTsdu — * VTsdu ::= CHOICE { echoNow [0] IMPLICIT SEQUENCE OF ObjectUpdate, — * notEchoNow [1] IMPLICIT SEQUENCE OF ObjectUpdate > ObjectUpdate ::= CHOICE { display [0] IMPLICIT DisplaySeq, — X control [1] IMPLICIT G.COupdate } — * DisplaySeq ::= SEQUENCE { doName PrintableString, — * do-Update SEQUENCE OF DOupdate > DOupdate ::= CHOICE { nextXarray [0] IMPLICIT NULL, -ET4 nextYarray [1] IMPLICIT NULL, -* p t r - r e l a t i v e [2] IMPLICIT G.ExplicitPointer ptr-absolute Pointer, -ET5 text [4] IMPLICIT OCTET STRING. repeatText [5] IMPLICIT RepeatTextSeq, --X writeAttr [6] IMPLICIT WriteAttrSeq, -X erase [7] IMPLICIT EraseSeq, -X previousXarray [8] IMPLICIT NULL, previousYarray [9] IMPLICIT NULL > --ET6 RepeatTextSeq ::= SEQUENCE { finishAddress Pointer, content OCTET STRING } WriteAttrSeq ::= SEQUENCE { a t t r i b u t e l d A t t r l d , attributeExt AttrExtent > EraseSeq ::= SEQUENCE { startErase Pointer, endErase Pointer, erase-Attr EraseAttr } A t t r l d ::= CHOICE { graphicCharacterRepertoire [0] IMPLICIT INTEGER, foregroundColour [1] IMPLICIT INTEGER, APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 109 backgroundColour emphasis font [2] IMPLICIT INTEGER, [3] IMPLICIT INTEGER, [4] IMPLICIT INTEGER } AttrExtent ::= CHOICE < global addressExtent modalExtent [0] IMPLICIT NULL, [1] IMPLICIT AddressRange, [2] IMPLICIT NULL > AddressRange SEQUENCE { beginning ending Pointer, Pointer )• EraseAttr BOOLEAN True = erase secondary attributes Pointer ::= CHOICE i current [10] IMPLICIT NULL, sta r t [11] IMPLICIT NULL, startY [12] IMPLICIT NULL, startX [13] IMPLICIT NULL, end [14] IMPLICIT NULL, endY [IS] IMPLICIT NULL, endX [16] IMPLICIT NULL, coords [17] IMPLICIT G.ExplicitPointer > -ET7 -ET8 RLRcontent ::= SEQUENCE { r l r - r e s u l t [0] IMPLICIT G.Result2, rlr - r e a s o n RLR-FailureReason OPTIONAL > RLR-FailureReason ::= CHOICE { uaerFailureReason [1] IMPLICIT PrintableString, providerFailureReason [2] IMPLICIT INTEGER { c o l l i s i o n - d e t e c t e d (0) > > SNRcontent ::= SEQUENCE •C snr-result [0] IMPLICIT G.Result2, snr-reason SNR-FailureReason OPTIONAL, profArgValueList [3] IMPLICIT G.ProfileArgumValueList OPTIONAL > SNR-FailureReason ::= CHOICE •( uaerFailureReason [1] IMPLICIT PrintableString, providerFailureReason [2] IMPLICIT INTEGER {. col l i s i o n - d e t e c t e d (0) , profile-not-supported (4) )• } SPRcontent ::= SEQUENCE APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 110 •C profArgValueLiat [0] IMPLICIT G.ProfileArgumValueList OPTIONAL, apr-result2 [1] IMPLICIT G.Result2, spr-reason SPR-FailureReason OPTIONAL } SPR-FailureReason ::= CHOICE { userFailureReason [2] IMPLICIT PrintableString, providerFailureReason [3] IMPLICIT INTEGER { co l l i s i o n - d e t e c t e d parara-not-supported param-comb-not-supported prof i1e-not-support ed END — of VTP d e f i n i t i o n s G DEFINITIONS ::= BEGIN —********************************************************************** — * General d e f i n i t i o n s used at multiple places i n the rest of the * — * syntax but not s p e c i f i c to a p a r t i c u l a r object * —************************************ (0) . (1) . (2) . (4) } > CollisionWinner ::= INTEGER { i n i t i a t o r (0), --ET9 acceptor (1), acceptorChoice (2) > COupdate ::= SEQUENCE { coName PrintableString, ObjectUpdate ObjUpdateChoice > — X ObjUpdateChoice ::= CHOICE i characterUpdate [0] IMPLICIT PrintableString, booleanUpdate [1] IMPLICIT BoolUpdateSeq, ~ X symbolicUpdate [2] IMPLICIT INTEGER, integerUpdate [3] IMPLICIT INTEGER, bitStringUpdate [4] IMPLICIT BIT STRING > BoolUpdateSeq ::= SEQUENCE { value [0] IMPLICIT BIT STRING, mask [1] IMPLICIT BIT STRING OPTIONAL } E x p l i c i t P o i n t e r ::= SEQUENCE { x [0] IMPLICIT INTEGER OPTIONAL, y [1] IMPLICIT INTEGER OPTIONAL, z [2] IMPLICIT INTEGER OPTIONAL > APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 111 FunctionalUnits ::= BIT STRING { profileSwitch (0), proSwAndMIN (1), negotiatedRelease (2), urgentData (3), destructiveBreak (4) } Implementationldent ::= SEQUENCE { implementationldentifier [0] implementationName [1] implementationVersion [2] IMPLICIT OBJECT IDENTIFIER OPTIONAL, IMPLICIT PrintableString OPTIONAL, IMPLICIT PrintableString OPTIONAL } IntegerOffer ::= SEQUENCE OF IntOffChoice — X IntOffChoice ::= CHOICE { individualValue [0] IMPLICIT INTEGER, range [1] IMPLICIT IntRangeSeq } ~ X IntRangeSeq ::= SEQUENCE { minimum INTEGER, maximum INTEGER } P r o f i l e ::= SEQUENCE { name OBJECT IDENTIFIER OPTIONAL, profArgOfferList ProfileArgumOfferList OPTIONAL > ProfileArgumOfferLiat ::= SEQUENCE OF OffListChoice ~ X OffListChoice ::- CHOICE < specialProfileArgum [0] IMPLICIT OffListSpArgSeq, --ET10 vteParams [1] IMPLICIT ParamOfferList > —ET10 OffListSpArgSeq ::= SEQUENCE { i d e n t i f i e r INTEGER, offeredValue OffValChoice > OffValChoice ::= CHOICE { boolval [0] IMPLICIT BIT STRING < f a l s e (0). true (1) }, i n t v a l [1] IMPLICIT G.IntegerOffer, s t r i n g [2] IMPLICIT SET OF Pri n t a b l e S t r i n g > APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 112 ProfileArgumValueList ::= SET OF ValListChoice — X ValListChoice ::= CHOICE •C BpecialProfileArgum [0] IMPLICIT ValListSpArgSeq, — X ET10 vteParamo [1] IMPLICIT ParamValueList > —ET10 ValListSpArgSeq ::= SEQUENCE < i d e n t i f i e r INTEGER, value ValCboice )• — X ValChoice ::= CHOICE < boolval BOOLEAN, i n t v a l INTEGER, st r i n g PrintableString } ParamldentList ::= SEQUENCE < displayObjects [0] IMPLICIT CDS.CDSidentifier OPTIONAL, — * controlObjects [1] IMPLICIT CSS.CSSidentifier OPTIONAL, — * deviceObjects [2] IMPLICIT DEV.DEVidentifier OPTIONAL, --* deliveryControl [3] IMPLICIT NULL OPTIONAL } ParamDfferList ::= SEQUENCE { displayObjects [0] IMPLICIT CDS.CDSoffer OPTIONAL, — * controlObjects [1] IMPLICIT CSS.CSSoffer OPTIONAL, — * deviceObjects [2] IMPLICIT DEV.DEVoffer OPTIONAL, — * deliveryControl [3] IMPLICIT BIT STRING { none (0), simple (1), quarantine (2) } OPTIONAL } ParamValueList ::= SEQUENCE •C displayObjects [0] IMPLICIT CDS.CDSvalue OPTIONAL, — * controlObjects [1] IMPLICIT CSS.CSSvalue OPTIONAL, — * deviceObjectB [2] IMPLICIT DEV.DEVvalue OPTIONAL, — * deliveryControl [3] IMPLICIT INTEGER { none (0), simpe (1), quarantine (2) > OPTIONAL > ProtocolVersion ::= BIT STRING { ver s i o n l (0) } APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP Result2 ::= INTEGER i f a i l u r e (0), success (1) } 113 Resuit3 ::= INTEGER i f a i l u r e (0), success (1), succesB-with-warning (2) } END — of G d e f i n i t i o n s CDS DEFINITIONS ::= BEGIN --+ Conceptual Data Store Definitions + --+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ —******************************** ~ * CDS I d e n t i f i e r * — * The following are to i d e n t i f y parameters to negotiated * —************************************************************************ CDSidentifier ::= SET OF CDSidentSeq — * X ET11 CDSidentSeq ::= SEQUENCE { objectName PrintableString, objectId DisplayObjectldent > — * DisplayObjectldent : : = SEQUENCE { dimensions [0] IMPLICIT xParamldent [1] IMPLICIT yParamldent [2] IMPLICIT zParamldent [3] IMPLICIT erasure [4] IMPLICIT repertoire [5] IMPLICIT emphasis [6] IMPLICIT foreground [7] IMPLICIT background [8] IMPLICIT obj ectAccessRight [9] IMPLICIT NULL OPTIONAL, DimensionParamldent OPTIONAL, DimensionParamldent OPTIONAL, DimensionParamldent OPTIONAL, NULL OPTIONAL, CompoundRepertoireldent OPTIONAL, CompoundEmphasisIdent OPTIONAL, CompoundColourldent OPTIONAL, CompoundColourldent OPTIONAL, --* NULL OPTIONAL > DimensionParamldent ::= SEQUENCE { bound [0] IMPLICIT NULL OPTIONAL, addressing [1] IMPLICIT NULL OPTIONAL, absolute [2] IMPLICIT NULL OPTIONAL, window [3] IMPLICIT NULL OPTIONAL > CompoundRepertoireldent ::= SEQUENCE •[ c a p a b i l i t y [0] IMPLICIT NULL OPTIONAL, APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 114 repFontldList [1] IMPLICIT SEQUENCE OF RepertoireFontldent OPTIONAL > RepertoireFontldent CHOICE { nullldent NULL, repFontldent RFidentSeq > —X RFidentSeq ::= SEQUENCE { assignment [0] IMPLICIT NULL OPTIONAL, fontCapability [1] IMPLICIT NULL OPTIONAL, fontNames [2] IMPLICIT SEQUENCE OF Assignmentldent OPTIONAL } CompoundEmphasisIdent ::= SEQUENCE •C capability NULL OPTIONAL, assignment SEQUENCE OF Assignmentldent OPTIONAL > CompoundColourldent ::= SEQUENCE < capability NULL OPTIONAL, assignment SEQUENCE OF Assignmentldent OPTIONAL } Assignmentldent ::= CHOICE { c l NULL, c2 PrintableString } —************************************************** ~* CDS Offers * —* The following are for offered values during negotiation * —************************************************************************ CDSoffer ::= SET OF CDSoffSeq —* X ET11 CDSoffSeq ::= SEQUENCE { objectName PrintableString, objOffer DisplayObjectOffer } --* DisplayObjectOffer ::= SEQUENCE —* •C dimensionOffer [0] IMPLICIT BIT STRING { oneDimension (0), twoDimensions (1), threeDimensions (2) } OPTIONAL, xParamOffer [1] IMPLICIT DimensionParamOffer OPTIONAL, yParamOffer [2] IMPLICIT DimensionParamOffer OPTIONAL, zParamOffer [3] IMPLICIT DimensionParamOffer OPTIONAL, erasureOffer [4] IMPLICIT BIT STRING •C yes (0), no (1) > OPTIONAL, repertoireOfferList [5] IMPLICIT CompoundRepertoireOffer OPTIONAL, emphasisOfferList [6] IMPLICIT CompoundEmphasisOffer OPTIONAL, foregroundColourOffer [7] IMPLICIT CompoundColourOffer OPTIONAL, backgroundColourOffer [8] IMPLICIT CompoundColourOffer OPTIONAL, objectAccessRight [9] IMPLICIT BIT STRING < wavar (0), waci (1), APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 115 waca (2) > OPTIONAL > DimensionParamOffer ::= SEQUENCE i bound [0] IMPLICIT DiParOffLimit OPTIONAL, — X addressing [1] IMPLICIT BIT STRING { noConstraint (0), higherOnly (1), notPermitted (2) > OPTIONAL, --ET12 absolute [2] IMPLICIT BIT STRING { yes(O), no (l) } OPTIONAL, —ET13 window [3] IMPLICIT DiParOffLimit OPTIONAL > — X DiParOffLimit ::= SEQUENCE { unbounded NULL OPTIONAL, l i m i t G.IntegerOffer OPTIONAL > CompoundRepertoireOffer ::= SEQUENCE { repertoireCapability [0] IMPLICIT G.IntegerOffer OPTIONAL, repFontOfferList [1] IMPLICIT SEQUENCE OF RepertoireFontOffer OPTIONAL > RepertoireFontOffer ::= CHOICE { n u l l O f f e r NULL, repFontOff RFofferSeq } ~ X RFofferSeq ::= SEQUENCE < repertoire [0] IMPLICIT RepertoireAssignment OPTIONAL, fontCapability [1] IMPLICIT G.IntegerOffer OPTIONAL, fontNameList [2] IMPLICIT SEQUENCE OF FontName OPTIONAL > CompoundEmphaaisOffer ::= SEQUENCE { emphasisCapability [0] IMPLICIT G.IntegerOffer OPTIONAL, emphasisNames SEQUENCE OF PrintableString OPTIONAL > CompoundColourOffer ::= SEQUENCE { colourCapability [0] IMPLICIT G.IntegerOffer OPTIONAL, colourNames SEQUENCE OF PrintableString OPTIONAL } —******************************************************************** — * CDS Values * — * The following are f o r returned values during negotiation * --*********************************************************************** CDSvalue ::= SET OF CDSvalSeq — * X ET11 CDSvalSeq ::= SEQUENCE { objectName PrintableString, objValue DisplayObjectValue )• — * DisplayObjectValue ::= SEQUENCE --* { dimension [0] IMPLICIT INTEGER OPTIONAL. xParamValue [1] IMPLICIT DimensionParamValue OPTIONAL, APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 116 yParamValue zParamValue erasure repertoire emphasis foregroundColour backgroundColour obj ectAccessRight [2] IMPLICIT DimensionParamValue OPTIONAL, [3] IMPLICIT DimensionParamValue OPTIONAL, [4] IMPLICIT BOOLEAN OPTIONAL. — true = "yes", f a l s e = "no" [5] IMPLICIT CompoundRepertoireValue OPTIONAL, [6] IMPLICIT CompoundEmphasisValue OPTIONAL, [7] IMPLICIT CompoundColourValue OPTIONAL, [8] IMPLICIT CompoundColourValue OPTIONAL, [9] IMPLICIT INTEGER • C w a v a r (0), waci (1), waca (2) } OPTIONAL > DimensionParamValue ::= SEQUENCE { bound [0] DiParValLimit OPTIONAL, — X addressing [1] IMPLICIT INTEGER { noConstraint (0), higherOnly (1), notPermitted (2) } OPTIONAL, —ET12 absolute [2] IMPLICIT BOOLEAN OPTIONAL, —ET14 — true = "yes", f a l s e = "no" —ET13 window [3] DiParValLimit OPTIONAL > ~ X DiParValLimit ::= CHOICE { unbounded NULL, l i m i t INTEGER > CompoundRepertoireValue ::= SEQUENCE < rep e r t o i r e C a p a b i l i t y [0] IMPLICIT INTEGER OPTIONAL, repFontValueList [1] IMPLICIT SEQUENCE OF RepertoireFontValue OPTIONAL > RepertoireFontValue ::= CHOICE { nullValue NULL, repFontVal RFvalSeq > — X RFvalSeq ::= SEQUENCE { repertoire [0] IMPLICIT fontCapability [1] IMPLICIT fontNameList [2] IMPLICIT RepertoireAssignment OPTIONAL, INTEGER OPTIONAL, SEQUENCE OF FontName OPTIONAL > CompoundEmphasisValue ::= SEQUENCE { c a p a b i l i t y [0] IMPLICIT INTEGER OPTIONAL, assignments [1] IMPLICIT SEQUENCE OF Printa b l e S t r i n g OPTIONAL > CompoundColourValue ::= SEQUENCE { c a p a b i l i t y [0] IMPLICIT INTEGER OPTIONAL, assignments [1] IMPLICIT SEQUENCE OF Printa b l e S t r i n g OPTIONAL > RepertoireAssignment ::= PrintableString ' (g) oTToqiaXs '(x) xrea-rooq '(o) jaqo«:retp > ONIHIS IIS IIOIldNI [v] iCio8a^BD 'TVNOIIdO i3iiOJ:339^ni-o IIOIldKI [E] "TVNOIIdO { (T)oa '(0)B3iC > S U M S IIS IlOIldWI [e] jr.a88T.:r.q "IVNOIIdTJ JajfoainHBsaooy IlOIldWI [T] q.q8THBB303e 'qnapTadXi JO i a s IlOIldWI [0] «TiT^napiadA > * - - aONaflbaS = =: Jaiioin»J»'dT°*VK>a * — { j:ajjO n r B j : BdT 0- I* n oD JajJOUiBjBd *8nTiq.sa-[qB^trri£ auren y aONaflbaS •»'• • •MJiO!>-:>af<lOTo:t4noO TTI3 * — jaiiO^aafqoioa^noo JO i a s = " «JJ°SSD * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * — * noT.qBT.qo9att 8nTjmp sanTHA i ax;o I O J a.x« 8UT.MOT.TOI aqx * — * sjiajJO SSO *--************************************************************************— { TVNOIIdO TinN IlOIldWI [9] jCqxjoxjd "IVNOIIdO TMN IlOIldWI [9] axxoqaadai "TVNOIIdO TION IlOIldWI [>] Jizo9a%vo "TVNOIIdO TION IlOIldWI [E] a z ™ ' TVNOIIdO TION IlOIldWI [Z] Ja88x.iq 'TVNOIIdO llflN IlOIldWI [T] qq8mBBaDDB 'TVNOIIdO 110N IlOIldWI [0] JaT-mnapiadX* > * - - 30NanbaS=: : q.ttapj.ure:r.B(no:r.quoo * — { q.napiuiBJB,j-[OJl-noO piurezcd • 8nTJcasaxqBq.TiTi <T aureu y aONaflbaS == : quapiqaaCqoioiquoo TTI3 X * - - qnapiqaafqoiojquoo JO I3S == = mnaPTSSD *********************************************************************** — * paq.BTq.o8an aq oq aiaqaureied Xitqnapx oq aj« SUTAOT^OI aqx * — * laxixquapi gSO * — *********************************************************************** — ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++— + snoxqxuxxaa Bnq.uq.g prre TBtfl-tg TOjqxtoQ +— ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++— Nioaa =:: SNOii iNiaaa sso attoTqxntjaa SOO J° — 0N3 SnijqgaxqBq .nTjj =:: aureuquo£ III dXA vc-d snad do SMOixwidda T'MSV a xiamddv APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 118 integer (3), transparent (4) } OPTIONAL, repertoire [5] IMPLICIT SEQUENCE OF PrintableString OPTIONAL, p r i o r i t y [6] IMPLICIT BIT STRING { normal (0), high (1), urgent (2) > OPTIONAL } AccessRuleOffer ::= BIT STRING { wavar (0), waci (1), waca (2), not-subject-to-access-control (3) } —*************************************************** -* CSS Values -* The following are f o r returned values during negotiation —************************************************************************ CSSvalue ::= SET OF ControlObj ectValue ControlObjectValue ::= SEQUENCE {name PrintableString, paramValue ControlParamValue } -* ET11 ControlParamValue : { t y p e l d e n t i f i e r accessRule triggerSelected size category repertoire p r i o r i t y := SEQUENCE [0] Typeldent, [1] IMPLICIT AccessRuleValue OPTIONAL, [2] IMPLICIT BOOLEAN OPTIONAL, — true = "selected", f a l s e = "not selected" [3] IMPLICIT INTEGER OPTIONAL, [4] IMPLICIT INTEGER { character (0), boolean (1), symbolic (2), integer (3), transparent (4) } OPTIONAL, [5] IMPLICIT PrintableString OPTIONAL, [6] IMPLICIT INTEGER { normal (0), high (1), urgent (2) > OPTIONAL > — * — * — * Typeldent ::= CHOICE { c l OBJECT IDENTIFIER, c2 PrintableString > AccessRuleValue ::= INTEGER { wavar (0), waci (1), waca (2), not-subject-to-access-control (3) } APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 119 END — of CSS D e f i n i t i n s DEV DEFINITIONS ::= BEGIN —++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --+ Device Object D e f i n i t i o n s + —++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ —*********************************************** --* DEV I d e n t i f i e r s * — * The following are to i d e n t i f y parameters to be negotiated * —************************************************************************ DEVidentifier ::= SET OF DEVidentSeq — * X ET11 DEVidentSeq ::= SEQUENCE { name PrintableString, devParamld DeviceParamldent } DeviceParamldent ::= SEQUENCE •C defaultAccess [0] IMPLICIT NULL OPTIONAL, deviceRepertoire [1] IMPLICIT CDS.CompoundRepertoireldent OPTIONAL, deviceEmphasis [2] IMPLICIT CDS.CompoundEmphasisIdent OPTIONAL, deviceForeground [3] IMPLICIT CDS.CompoundColourldent OPTIONAL, deviceBackground [4] IMPLICIT CDS.CompoundColourldent OPTIONAL, minimumXarrayLength [5] IMPLICIT NULL OPTIONAL. minimumYarrayLength [6] IMPLICIT NULL OPTIONAL, deviceControlObjectNames [7] IMPLICIT NULL OPTIONAL, deviceDisplayObjectName [8] IMPLICIT NULL OPTIONAL, terminationEventList [9] IMPLICIT NULL OPTIONAL, terminationLength [10] IMPLICIT NULL OPTIONAL, terminationTimeout [11] IMPLICIT NULL OPTIONAL, terminationControlObject [12] IMPLICIT NULL OPTIONAL, defaultCOtrigger [13] IMPLICIT NULL OPTIONAL, defaultCOInitialValue [14] IMPLICIT NULL OPTIONAL > —************************************************************************ — * DEV Offers * — * The following are f o r o f f e r values during negotiation * —************************************************************************ DEVoffer ::= SET OF DEVoffSeq ~ * X ET11 DEVoffSeq ::= SEQUENCE { name PrintableString, paramOffer DeviceParamOffer } — * APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 120 DeviceParamOffer ::= SEQUENCE --* { defaultObjectAccess [0] IMPLICIT CSS.AccessRuleOffer OPTIONAL, deviceRepertoireAssignment [1] IMPLICIT CDS.CompoundRepertoireOffer OPTIONAL, deviceEmphasisABsignment [2] IMPLICIT CDS.CompoundEmphaaisOffer OPTIONAL, devlceForegroundAs8ignment [3] IMPLICIT CDS.CompoundColourOffer OPTIONAL, devie eBackgroundAssignment [4] IMPLICIT CDS.CompoundColourOffer OPTIONAL, minimumXarrayLength [5] IMPLICIT G.IntegerOffer OPTIONAL, minimumYarrayLength [6] IMPLICIT G.IntegerOffer OPTIONAL, deviceControlObj ectNames [7] IMPLICIT SEQUENCE OF PrintableString OPTIONAL, deviceDisplayObj ectName [8] IMPLICIT SEQUENCE OF PrintableString OPTIONAL, t erminat ionEventList [9] IMPLICIT SET OF EventListOffSeq OPTIONAL, ~ X terminationLength [10] IMPLICIT LenOffSeq OPTIONAL, — X terminationTimeout [11] IMPLICIT TimeoutOffSeq OPTIONAL, — X terminationControlObj ectName [12] IMPLICIT SEQUENCE OF PrintableString OPTIONAL, defaultCOtrigger [13] IMPLICIT BIT STRING i notSelected (0), selected (1) > OPTIONAL. defaultCOInitialValue [14] IMPLICIT InitValOffSeq OPTIONAL } EventListOffSeq ::= SEQUENCE { event PrintableString, eventId EventIdSeq } LenOffSeq ::= SEQUENCE { length [0] IMPLICIT G.IntegerOffer, eventld [1] IMPLICIT EventldSeq > ~ X TimeoutOffSeq ::= SEQUENCE { time TimeOffer, eventld EventldSeq )• — X InitValOffSeq ::= SEQUENCE { true BIT STRING, f a l s e BIT STRING } EventldSeq ::= SEQUENCE { s i G.IntegerOffer OPTIONAL, s2 NULL OPTIONAL } TimeOffer ::= SET OF TimeOffChoice — X TimeOffChoice ::= CHOICE < value [0] IMPLICIT ValueSeq, range [1] IMPLICIT RangeValSeq > — X ~ X APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP 121 ValueSeq ::= SEQUENCE { m u l t i p l i e r INTEGER, exponent INTEGER > RangeValSeq ::= SEQUENCE i lowerMultiplier INTEGER, lowerExponent INTEGER, upperMultiplier INTEGER, upperExponent INTEGER } —************************************** — * DEV Values * — * The following are f o r returned values during negotiation * --************************************************************************ DEVvalue ::= SET OF DEVvalSeq — * X ET11 DEVvalSeq ::= SEQUENCE { name PrintableString, --* paramValue DeviceParamValue )• — * DeviceParamValue ::= SEQUENCE --* { defaultObjectAccess [0] IMPLICIT CSS.AcceBsRuleValue OPTIONAL, deviceRepertoireAssignment [1] IMPLICIT CDS.CompoundRepertoireValue OPTIONAL, deviceEmphasisAssignment [2] IMPLICIT CDS.CompoundEmphasisValue OPTIONAL, deviceForegroundAssignment [3] IMPLICIT CDS.CompoundColourValue OPTIONAL, deviceBackgroundAssignment [4] IMPLICIT CDS.CompoundColourValue OPTIONAL, minimumXarrayLength [5] IMPLICIT INTEGER OPTIONAL, minimumYarrayLength [6] IMPLICIT INTEGER OPTIONAL, deviceControlObj ectNames [7] IMPLICIT SEQUENCE OF Printa b l e S t r i n g OPTIONAL, deviceDisplayObj ectName [8] IMPLICIT Print a b l e S t r i n g OPTIONAL, terminationEventList [9] IMPLICIT SET OF EventListValSeq OPTIONAL, — X terminationLength [10] IMPLICIT LenValSeq OPTIONAL, — X terminationTimeout [11] IMPLICIT TimeoutValSeq OPTIONAL, — X terminationControlObj ectName [12] IMPLICIT Print a b l e S t r i n g OPTIONAL, defaultCOtriggerSelected [13] IMPLICIT BOOLEAN OPTIONAL, — true = "selected", f a l s e = "not select" defaultCOInitialValue [14] IMPLICIT InitValValSeq OPTIONAL > — X APPENDIX B. ASN.l DEFINITIONS OF PDUS FOR VTP EventListValSeq ::= SEQUENCE { event eventld PrintableString, INTorNULL } LenValSeq ::= SEQUENCE { length INTEGER, eventld INTorNULL } TimeoutValSeq ::= SEQUENCE < timeMultiplier INTEGER, t imeExponent INTEGER, InitValValSeq ::= SEQUENCE { value [0] IMPLICIT BIT STRING, mask [1] IMPLICIT BIT STRING } INTorNULL ::= CHOICE { c l INTEGER, c2 NULL } END — of DEV D e f i n i t i o n s eventld INTorNULL > A p p e n d i x C S t a t e T r a n s i t i o n D i a g r a m s Legend : + = incoming event - = outgoing event (+) = result of the response or confirm type event i s successful (-) = resul t of the response or confirm type event i s unsuccessful (+/-) = resul t of the response or confirm type event may be successful or unsuccessful (*) = event exists only when VTPM has undelivered VT data and resul t of incoming event i s successful .req = request pr imit ive . ind = indicat ion pr imit ive .resp = response pr imit ive .conf = confirm pr imit ive 123 APPENDIX C. STATE TRANSITION DIAGRAMS 124 Association Establishment and Data Transfer +ASQ -VT-ASSOCIATE.ind^. +VT-ASSOCIATE.resp(-) ASR(-) +VT-ASSOCIATE.req -ASQ + A S R ( - ) ' \ \ -VT-ASSOCIATE.conf(-)\4, \ +VT-ASSOCIATE.resp(+)\ - A S R ( + ) \ +VT-DELIVER.req(ar)^";>--"" -NDQC)/;>'rr;AQ -DLQ(ar) //+VT-ACK-RECEIPT.ind /-VT-ASSOCIATE.conf(+) ^<>,+DLQ(ar ) VT-ACK-RECEIPT.req'\\-VT-DATA-ind(*) -DAQ \\-VT-DELIVER.ind(ar) Data Transfer^ [awaiting ack from] peer Data Transfer/^ [awaiting ack fromj user \ t +VT-ACK-RECEIPT.req \ \ -DAQ +DLQ(a r ) ' \ \ -VT -DATA . i nd (* ) \ -VT-DELIVER.ind(ar) 1 Data Transfer [awaiting ack from)4: ,both direction. +DAQ T VT-ACK-RECEIPT.ind / y / +VT-DELIVER.req(ar) -NDQ(*) -DLQ(ar) APPENDIX C. STATE TRANSITION DIAGRAMS 125 Switch Profile Negotiation and Normal Release Switch Profile, awaiting user Switch Profile, awaiting peer # |+VT-SWITCH-PROFILE.resp(+/-) +SPR(+/-)' f I VNDQC ) -VT-DATA.ind(')/ I VT-DATA.ind(') \ \ Sy'-NDQ(*) " T T -~* ^  -SPQ Data ^ Transfer +RLQ — — -VT-SWITCH-PROFILE.ind \ C -VT-DATA. ind(V> + V T D C I CASE r e » M - V T - R E L E A S E . i n d o i l ' / / -nLH(-) +VT-RELEASE.req +RLR(-)xOs-NDQ(*) -VT-RELEASE.cont(-) \ \ - R L Q +VT-RELEASE.resp(+)\ -NDQ(*)X -RLR(+) " Association J-I y.v ' RLR(+) y -VT-DATA.ind(') " -VT-RELEASE.conf(+) APPENDIX C. STATE TRANSITION DIAGRAMS Abnormal Release 126 +AUQ -VT-U-AROBT.ind +VT-U-Abort.req Interrupt +BKR +VT-BREAK.resp -VT-BREAK.conf -BKR +VT-BREAK.req +BRK -BKR -VT-BREAK.ind 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0051938/manifest

Comment

Related Items