Internet Standards

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

/ Internet Standards / CD1.mdf / nist / oiw / agreemnt / 1993 / 14s_9312.txt < prev next >

Wrap

Text File | 1994-02-09 | 98KB | 3,696 lines

Stable Implementation Agreements for Open Systems Interconnection Protocols: Part 14 - Virtual Terminal Output from the December 1993 Open Systems Environment Implementors' Workshop (OIW) SIG Chair: Michelle Conaway, HFSI SIG Editor: Michelle Conaway, HFSI PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Foreword This part of the Stable Implementation Agreements was prepared by the Virtual Terminal Special Interest Group (VTSIG) of the Open Systems Environment Implementors' Workshop (OIW). See Part 1 - Workshop Policies and Procedures of the "Draft Working Implementation Agreements Document" for the charter. Text in this part has been approved by the Plenary of the above- mentioned Workshop. This part replaces the previously existing chapter on this subject. Three normative annexes are given. Future changes and additions to this version of these Implementor Agreements will be published as change pages. Deleted and replaced text will be shown as struck. New and replacement text will be shown as shaded. ii PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Table of Contents Part 14 - Virtual Terminal . . . . . . . . . . . . . . . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Phase Ia agreements . . . . . . . . . . . . . . . . 1 1.2 Phase Ib agreements . . . . . . . . . . . . . . . . 2 1.3 Phase II agreements . . . . . . . . . . . . . . . . 2 2 Normative references . . . . . . . . . . . . . . . . . . 2 3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Status of phase Ia . . . . . . . . . . . . . . . . . 3 3.2 Status of phase Ib . . . . . . . . . . . . . . . . . 3 3.3 Status of phase II . . . . . . . . . . . . . . . . . 3 4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 Conformance . . . . . . . . . . . . . . . . . . . . . . . 8 6 Protocol . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1 Protocol elements . . . . . . . . . . . . . . . . . 10 6.2 Mapping of protocol elements . . . . . . . . . . . . 10 6.3 Protocol data unit structure . . . . . . . . . . . . 10 7 OIW registered control objects . . . . . . . . . . . . . 10 7.1 Sequenced Application (SA) . . . . . . . . . . . . . 10 7.1.1 Entry number . . . . . . . . . . . . . . . 10 7.1.2 Name of sponsoring body . . . . . . . . . . 11 7.1.3 Date . . . . . . . . . . . . . . . . . . . 11 7.1.4 Identifier . . . . . . . . . . . . . . . . 11 7.1.5 Descriptor value . . . . . . . . . . . . . 11 7.1.6 CO parameters . . . . . . . . . . . . . . . 11 7.1.7 CO Values and Semantics . . . . . . . . . . 11 7.1.8 Additional information . . . . . . . . . . 12 7.1.9 Usage . . . . . . . . . . . . . . . . . . . 12 7.2 Unsequenced Application (UA) . . . . . . . . . . . . 13 7.2.1 Entry number . . . . . . . . . . . . . . . 13 7.2.2 Name of sponsoring body . . . . . . . . . . 13 7.2.3 Date . . . . . . . . . . . . . . . . . . . 13 7.2.4 Identifier . . . . . . . . . . . . . . . . 13 7.2.5 Descriptor value . . . . . . . . . . . . . 13 7.2.6 CO parameters . . . . . . . . . . . . . . . 13 7.2.7 CO values and semantics . . . . . . . . . . 13 7.2.8 Additional information . . . . . . . . . . 14 iii PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 7.2.9 Usage . . . . . . . . . . . . . . . . . . . 14 7.3 Sequenced Terminal (ST) . . . . . . . . . . . . . . 14 7.3.1 Entry number . . . . . . . . . . . . . . . 14 7.3.2 Name of sponsoring body . . . . . . . . . . 14 7.3.3 Date . . . . . . . . . . . . . . . . . . . 14 7.3.4 Identifier . . . . . . . . . . . . . . . . 14 7.3.5 Descriptor value . . . . . . . . . . . . . 14 7.3.6 CO parameters . . . . . . . . . . . . . . . 14 7.3.7 CO values and semantics . . . . . . . . . . 15 7.3.8 Additional information . . . . . . . . . . 17 7.3.9 Usage . . . . . . . . . . . . . . . . . . . 17 7.4 Unsequenced Terminal (UT) . . . . . . . . . . . . . 17 7.4.1 Entry number . . . . . . . . . . . . . . . 17 7.4.2 Name of sponsoring body . . . . . . . . . . 17 7.4.3 Date . . . . . . . . . . . . . . . . . . . 17 7.4.4 Identifier . . . . . . . . . . . . . . . . 17 7.4.5 Descriptor value . . . . . . . . . . . . . 17 7.4.6 CO parameters . . . . . . . . . . . . . . . 17 7.4.7 CO values and semantics . . . . . . . . . . 18 7.4.8 Additional information . . . . . . . . . . 18 7.4.9 Usage . . . . . . . . . . . . . . . . . . . 18 8 OIW defined profiles . . . . . . . . . . . . . . . . . . 18 8.1 Telnet profile . . . . . . . . . . . . . . . . . . . 18 8.1.1 Introduction . . . . . . . . . . . . . . . 18 8.1.2 Association requirements . . . . . . . . . 18 8.1.2.1 Functional units . . . . . . . . . . . . . 18 8.1.2.2 Mode . . . . . . . . . . . . . . . . . . . 19 8.1.3 Profile body . . . . . . . . . . . . . . . 19 8.1.4 Profile arguments . . . . . . . . . . . . . 22 8.1.5 Profile dependent control object information . . . . . . . . . . . . . . . . 22 8.1.6 Profile notes . . . . . . . . . . . . . . . 22 8.1.6.1 Definitive notes . . . . . . . . . . . . . 22 8.1.6.2 Informative notes . . . . . . . . . . . . . 25 8.1.7 Specific conformance requirements . . . . . 26 8.2 Transparent profile . . . . . . . . . . . . . . . . 26 8.3 Forms profile . . . . . . . . . . . . . . . . . . . 26 8.4 X3 profile . . . . . . . . . . . . . . . . . . . . . 26 8.4.1 Introduction . . . . . . . . . . . . . . . 26 8.4.2 Association requirements . . . . . . . . . 27 8.4.2.1 Functional units . . . . . . . . . . . . . 27 8.4.2.2 Mode . . . . . . . . . . . . . . . . . . . 27 8.4.3 Profile body . . . . . . . . . . . . . . . 27 8.4.4 Profile arguments . . . . . . . . . . . . . 34 8.4.5 Profile notes . . . . . . . . . . . . . . . 35 8.4.5.1 Definitive notes . . . . . . . . . . . . . 35 8.4.5.2 Informative notes . . . . . . . . . . . . . 42 8.4.6 Specific conformance requirements . . . . . 46 iv PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 8.5 Generalized Telnet profile . . . . . . . . . . . . . 46 8.6 S-mode paged application profile . . . . . . . . . . 46 Annex A (normative) Specific ASE requirements . . . . . . . . . . . . . . . . . . 47 Annex B (normative) Clarifications . . . . . . . . . . . . . . . . . . . . . . . 48 Annex C (normative) Object identifiers . . . . . . . . . . . . . . . . . . . . . 49 v PART 14 - VIRTUAL TERMINAL December 1993 (Stable) List of Tables Table 1 - Technical errata . . . . . . . . . . . . . . . . . 5 Table 2 - Alignment errata . . . . . . . . . . . . . . . . . 6 Table 3 - Editorial errata . . . . . . . . . . . . . . . . . 7 Table 4 - Conformance Status for VT Facilities . . . . . . . 9 Table 5 - SA/UA CO values and semantics. . . . . . . . . . . 12 Table 6 - ST/UT CO composite values . . . . . . . . . . . . . 15 Table 7 - KB/DI CO value definitions . . . . . . . . . . . . 22 Table 8 - NI/NA CO value definition . . . . . . . . . . . . . 24 Table 9 - PAD CO data element 1 value definition . . . . . . 35 Table 10 - PAD CO data element 3 value definition . . . . . . 36 Table 11 - PAD CO data element 7 value definition . . . . . . 37 Table 12 - BI CO values and semantics . . . . . . . . . . . . 38 Table 13 - BO CO values and semantics . . . . . . . . . . . . 38 Table 14 - PAD CO data element 13 value definition . . . . . 39 Table 15 - PAD CO data element 19 value definitions . . . . . 40 Table 16 - PAD CO data element 20 value definition . . . . . 41 Table 17 - PAD CO data element 21 value definition . . . . . 41 Table 18 - CCITT Simple Standard profile . . . . . . . . . . 43 Table 19 - CCITT Transparent Standard profile . . . . . . . . 45 vi Part 14 - Virtual Terminal 0 Introduction The OSI Implementors' Workshop Virtual Terminal (VT) SIG is making implementation agreements for the OSI Basic Class VT Service and Protocol, ISO 9040 and ISO 9041. These implementation agreements fall into the following categories: Functionality to be implemented, i.e., functional units, etc. Identification and specification of VT profiles to be supported by conforming implementations. Agreements with regard to implementation issues not specified in ISO 9040 and ISO 9041. Resolution of problems with ISO 9040 and ISO 9041 identified during implementation. Statement of requirements to meet conformance to these agreements. 1 Scope 1.1 Phase Ia agreements The Telnet profile is intended to support the following usage: a) a simple line at a time or character at a time dialogue; b) an application level gateway supporting Internet Telnet and ISO VTP interoperation. The Transparent profile supports the exchange of uninterpreted sequences of characters. This includes support of VT-users who wish to control terminals directly through the use of embedded control characters and escape sequences. 1 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 1.2 Phase Ib agreements The Forms profile is intended to support forms-based applications with local entry and validation of data by the terminal system. This profile is now aligned with the EWOS VT EG Functional Standard. 1.3 Phase II agreements The X.3 profile supports functionality similar to the CCITT recommendations and could be used to implement an X.3 to ISO-VT gateway. The S-mode Paged Application profile is intended to provide a Forms capability for the existing base of block mode terminals. It contains a subset of the functionality provided by the Forms profile. See Working Agreements regarding other Phase II profiles. 2 Normative references ISO 9040:1990, Information technology - Open Systems Interconnection - Virtual Terminal Basic Class Service. ISO 9041-1:1990, Information technology - Open Systems Interconnection - Virtual Terminal Basic Class Protocol - Part 1: Specification. ISO 9834-4, Information technology - Open Systems Interconnection - Procedures for the Operation of OSI Registration Authorities - Part 4: Register of VTE Profiles. ISO 9834-5, Information technology - Open Systems Interconnection - Procedures for the Operation of OSI Registration Authorities - Part 5: Register of VT Control Object Definitions. 2 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 3 Status This version of the agreements was completed in December 1991. 3.1 Status of phase Ia Phase Ia of the VT Agreements was stabilized May 5, 1988. This phase covers the Telnet and Transparent profiles. No future enhancements will be made to this phase. 3.2 Status of phase Ib Phase Ib of the VT Agreements was first stabilized December 16, 1988. This phase covers the Forms profile. Alignment with EWOS required substantial modifications which were ratified September 15, 1989. On March 11, 1993, the text for the forms profile was removed from the Stable Agreements and replaced with a reference to PDISP 11187-3 (AVT-22 S-mode Forms Profile). NOTE - PDISP 11187-3 contains significant technical differences from the earlier forms profile contained within these agreements. Implementors of the Forms Profile should reference PDISP 11187-1. 3.3 Status of phase II Phase II is still in progress and includes the remaining profile work for the Scroll profile. The S-mode Paged Application Profile is being progressed as PDISP 11187-4 (AVT-23 S-mode Paged Application Profile). The X.3 profile of phase II was stabilized December 15, 1989. The Generalized Telnet profile of phase II was stabilized December 13, 1991. It is intended that Phase II agreements be compatible with Phase I agreements. 3 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 4 Errata Editor's Note - "Defect Report" material may be included here, including versions of implementor agreements to which it applies. 4 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Table 1 - Technical errata 06/90-1 Forms Profile. The "FEICO Update Syntax" ASN.1 comment which follows the definition of the PriValue type was corrected to support multi-octet repertoires. 06/90-2 Forms Profile. The descriptive text for the Field Entry Instruction Violation FEE was corrected to indicate that both an entry-control index and a FEPR index are required to identify the FEPR concerned. 06/90-3 Forms Profile. The descriptive text and update syntax for the Violation FEC were corrected to indicate that both a FEICO-name and an index are required to identify a FEIR. 06/90-4 Forms Profile. The update syntax for the writeString FER was corrected to align with the descriptive text for this FER. 06/90-5 Forms Profile. The descriptive text for the repertoire assignment profile argument was corrected to properly identify the default value as the GL set ISO 2375 Reg. No. 6 (ASCII). 06/90-6 Forms Profile. The concept of a "current keystroke" was inserted into the definition of the FEICO to remove ambiguity in the use of the ST and UT COs. Various FEEs, FECs and FERs were redefined. 12/91-1 Telnet Profile. Change x-absolute value from "no" to "yes." 03/92-1 Generalized Telnet Profile. Add conformance statement regarding the requirement to accept negotiation of Suppress GoAhead. 03/92-2 Generalized Telnet Profile. Rework Definitive Note 8, expanding the repertoire negotiation capability to allow negotiation for the use any one of a number of non-binary repertoires. 03/92-3 X.3 Profile. Correct processing of terminal break so that it aligns with the procedures of ccitt X.29. 12/92-1 Generalized Telnet Profile. Rework Definitive Note 8, to clarify repertoire negotiation capability. 5 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 12/92-2 Generalized Telnet Profile. Add Informative Note 4, to clarify situations where repertoire negotiation capability beyond switching to binary would be used. 12/92-3 Generalized Telnet Profile. Remove item C from Definitive Note 3. 12/92-4 Generalized Telnet Profile. Clarify action of VT- BREAK in Informative Note 3. Table 2 - Alignment errata 06/90-7 Forms Profile. A definitive note was added to define how the host is notified of the current entry location when data entry terminates and the VTE- parameter access-outside-fields has the value "allowed." 06/90-8 Forms Profile. Three font-assignment profile arguments were added to accommodate INTAP requirements. 09/90-1 Forms Profile. The emphasis subattribute "h" was added with values "F" (Framed) and "C" (Encircled). 09/90-2 Telnet Profile. Four editorial comments were incorporated to align with the corresponding EWOS Functional Standard. 6 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Table 3 - Editorial errata 06/90-9 Forms Profile. Two definitive notes were added to clarify the secondary attributes comparison mechanisms for the FEIs and FECs that test equality of characters. 06/90- Forms Profile. A definitive note was added to 10 clarify the effect of associating multiple Character-oriented FEIs of the same type with the same field. 06/90- Forms Profile. An introductory paragraph in the 11 section "Field Entry Condition Definitions" was rewritten for clarification. 06/90- Forms Profile. The descriptive text for the Write 12 String field entry reaction was modified to indicate precisely how and where the associated string is to be written. 09/90-3 X3 Profile. The reference to COs P3 and P4 contained in comments relating to DEVICE-1 were corrected to reference elements 3 and 4 of the PAD CO. 12/90-1 X3 Profile. Changes were made to correct editorial errors discovered during the progression of the EWOS X3 Profile Functional Standard. 09/91-1 Scope, Status, and References clauses were updated. 09/92-1 Status clause was updated. 12/92-1 Scope and Status clauses were updated. 12/92-2 Headings and Table entries were updated. 12/92-3 S-mode Paged Application profile. Created Section 8.6 to reference the S-mode Paged Application Profile. 12/92-4 Telnet-1988 profile. A note was added to clarify the future of the profile. 03/93-1 Replaced Forms profile with reference to the ISP. 12/93-1 Replaced Transparent profile with reference to the ISP. 12/93-2 Replaced Generalized Telnet profile with reference to the ISP. 7 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 5 Conformance Conformant VT implementations are required to support the ISO 9041 Clause 13 requirements plus the additional conformance requirements identified below. Table 4 shows conformance status for VT facilities which are optional in the ISO VT standard. The terms used in the figure are defined as indicated below: a) "Mandatory" indicates that the facility must be provided by all implementations which conform to these agreements; b) "Optional" indicates that the VT facility is not required to meet minimum conformance requirements but has been identified as providing additional useful capabilities; c) "Profile Dependent" indicates that the requirement for the facility, if any, is included in the profile definitions; d) "Not Addressed" indicates that the VT facility is outside the scope of these agreements. 8 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Table 4 - Conformance Status for VT Facilities Conformance Mandato Optiona Profile Not Status ry l Dependen Addresse t d Switch Profile2) X Multiple Interaction X Negotiation2) Negotiated Release2) X Urgent Data2) X Break2) X Delivery Control1) X Enhanced Access X Rules2) Structured COs2) X Blocks2) X Fields2) X RIOs2) X S-mode X A-mode X Mode Switching X Capability 1) It is not anticipated that new profiles will use quarantined delivery control. 2) Functional Units. For each mode of operation (A-mode and S-mode) which is implemented, the default profile for that mode as defined in ISO 9040 must be supported. Implementations that support A-mode must support the A-mode default profile and at least one additional Workshop approved A-mode profile. The Transparent profile does not count as an additional A-mode profile. Implementations that support S-mode must support the S-mode default profile and at least one additional Workshop approved S-mode profile. For each profile implemented, VTE parameter ranges or values specified in the Workshop-agreed profile and associated notes 9 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) must be supported. 6 Protocol 6.1 Protocol elements All protocol elements required by the ISO 9040 VT kernel and Break functional units are selected. All protocol elements required by the Switch Profile functional unit are selected if this functional unit is used. See Table 4. All protocol elements required by the Urgent Data functional unit are selected if this functional unit is used. See Table 4. 6.2 Mapping of protocol elements Mapping of protocol elements on to ACSE or Presentation Services is as defined in ISO 9041. 6.3 Protocol data unit structure Protocol data unit structure is as defined in ISO 9041. 7 OIW registered control objects The following Control Objects are used by more than one profile. Some of the CO parameters are left with undefined values that must be assigned by the profile in which the Control Object is used. 7.1 Sequenced Application (SA) This is a Control object used to convey signals from the application to the terminal in sequence with other updates. 7.1.1 Entry number To be supplied by Registration Authority. 10 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 7.1.2 Name of sponsoring body OSI Implementors' Workshop (OIW), VTSIG. 7.1.3 Date The date of submission of this proposal is September 15, 1989. 7.1.4 Identifier oiw-vt-co-misc-sa OBJECT IDENTIFIER ::= {oiw-vt-co-misc sa(0)} 7.1.5 Descriptor value "OIW VT CO for conveying Sequenced Application Signals" 7.1.6 CO parameters CO-structure 1 CO-priority "normal" CO-category "symbolic" CO-size 11 7.1.7 CO Values and Semantics Table 5 lists the allowed symbolic values together with the integers used to reference these values in the ASN.1 update syntax of ISO 9041: 11 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Table 5 - SA/UA CO values and semantics. Symbolic Value Integer Value audible_alarm 0 newlines_enabl 1 ed newlines_disab 2 led restore 3 visual_alarm 4 keypad_enabled 5 keypad_disable 6 d keyboard_locke 7 d keyboard_unloc 8 ked device_disconn 9 ect break_signal 10 The semantics of each value must be specified in the VTE profile which references this CO. 7.1.8 Additional information None. 7.1.9 Usage Defined in profile. 12 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 7.2 Unsequenced Application (UA) This is a Control object used to convey urgent signals from the application to the terminal. 7.2.1 Entry number To be supplied by Registration Authority. 7.2.2 Name of sponsoring body OSI Implementors' Workshop (OIW), VTSIG. 7.2.3 Date The date of submission of this proposal is September 15, 1989. 7.2.4 Identifier oiw-vt-co-misc-ua OBJECT IDENTIFIER::= {oiw-vt-co-misc ua(1)} 7.2.5 Descriptor value "OIW VT CO for conveying Unsequenced Application Signals" 7.2.6 CO parameters CO-structure 1 CO-priority "urgent" CO-category "symbolic" CO-size 11 7.2.7 CO values and semantics Same as in SA. 13 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 7.2.8 Additional information None. 7.2.9 Usage Defined in profile. 7.3 Sequenced Terminal (ST) A keyboard can generate many signals that may be given special meaning to the application. This CO is general enough to convey any keyboard event. 7.3.1 Entry number To be supplied by Registration Authority. 7.3.2 Name of sponsoring body OSI Implementors Workshop (OIW), VTSIG. 7.3.3 Date The date of submission of this proposal is September 15, 1989. 7.3.4 Identifier oiw-vt-co-misc-st OBJECT IDENTIFIER ::= {oiw-vt-co-misc st(2)} 7.3.5 Descriptor value "OIW VT CO for conveying Sequenced Terminal Signals" 7.3.6 CO parameters CO-structure 1 CO-priority "normal" CO-category "integer" CO-size 65535 14 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 7.3.7 CO values and semantics The values of the CO are composite, with values from Table 6 giving meaning to the values in the hex range 00-FF when added to them. Table 6 - ST/UT CO composite values hex meaning value 100 special key - labeled1) 200 function key depressed 400 control key depressed 800 shift key depressed 1000 alt key depressed 1) possible special key values are as defined by the STCO ASN.1 module. The special key and the function key are mutually exclusive. If neither the function keys nor the special keys are pressed, then the value in the hex range 00-FF will be that of the normal, unshifted code combination generated by the alpha-numeric key. Values in the hex range 00-FF are not valid values for the data element of this Control Object. The control, shift, and alt keys may appear in any combination with the special or function keys. The shift key must occur in combination with at least one of the other keys in the above table to cause the value to fall outside the repertoire of the display object. When the special key is depressed, the value of the CO content will be as given in the ASN.1 module below for the value in the hex range of 00-FF. Otherwise, the value will be defined to be the IA5 value associated with the key. 15 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) STCO DEFINITIONS ::= BEGIN Key ::= INTEGER { break (0), bell (1), backSpace (2), tab (3), backTab (4), lineFeed (5), carReturn (6), cancel (7), substitute (8), escape (9), plus (10), minus (11), multiply (12), divide (13), leftArrow (14), rightArrow (15), upArrow (16), downArrow (17), insert (18), delete (19), insertLine (20), deleteLine (21), home (22), end (23), pageUp (24), pageDown (25), pa1 (26), pa2 (27), pa3 (28), help (29), statusProc (30), interruptPr (31), terminatePro (32), ess (33), ocess (34), cess (35), abortOutpu (36), formFeed (37), clear (38), t (39), refresh (40), systemReques (41) print endOfFile t endOfRecor suspendProce d ss -- Names for combination keystrokes are formed by converting the -- initial letter to upper case and prefixing with `ctrl', `shift' or -- `alt', which adds 1024, 2048 or 4096 respectively to the value. -- These prefixes may be used in combination with one another by a -- repetition of this conversion process, provided that they appear -- from left to right in the order `ctrl', `shift', `alt'. ASN.1 -- formally does not allow such descriptive additions but it would be -- very lengthy to write them all in full -- } END *(STCO DEFINITIONS)* VTE profile definitions may refer to this module for convenience in describing semantics. 16 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 7.3.8 Additional information None. 7.3.9 Usage Defined in profile. 7.4 Unsequenced Terminal (UT) Keyboard events may need to be conveyed urgently, out of sequence with normal updates. This CO is used to signal such events from the terminal to the application. 7.4.1 Entry number To be supplied by the Registration Authority. 7.4.2 Name of sponsoring body OSI Implementors Workshop (OIW), VTSIG 7.4.3 Date The date of submission of this proposal is September 15, 1989. 7.4.4 Identifier oiw-vt-co-misc-ut OBJECT IDENTIFIER ::= {oiw-vt-co-misc ut(3)} 7.4.5 Descriptor value "OIW VT CO for conveying Unsequenced Terminal Signals" 7.4.6 CO parameters CO-structure 1 CO-priority "urgent" CO-category "integer" CO-size 65535 17 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 7.4.7 CO values and semantics Same as in ST. 7.4.8 Additional information None. 7.4.9 Usage Defined in profile. 8 OIW defined profiles These profiles are defined using the conventions specified in Annex A of ISO 9040. 8.1 Telnet profile OIW VTE-Profile Telnet-1988 (r1, r2) 8.1.1 Introduction This profile provides support for TELNET-like operation for users of the ISO Virtual Terminal Service. It is based on the IS version of ISO 9040 and ISO 9041. Note: This profile is superseded by the Generalized-Telnet profile. The text for this profile will not be maintained beyond its current state. 8.1.2 Association requirements 8.1.2.1 Functional units The Urgent Data Functional Unit is optional, but should be used whenever available. 18 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 8.1.2.2 Mode This is an A-mode profile. 8.1.3 Profile body Display-objects = *(double occurrence)* { { display-object-name = D, *(DISPLAY)* do-access = "WACA", dimensions = "two", x-dimension = { x-bound = "unbounded", x-addressing = "no constraint", x-absolute = "yes", *(See Definitive Note 4)* x-window = profile-argument-r1 }, y-dimension = { y-bound = "unbounded", y-addressing = "higher only", y-absolute = "no", y-window = 1 }, erasure-capability = "yes", repertoire-capability = 2, repertoire-assignment = profile-argument-r2, repertoire-assignment = <ESC> 2/5 2/15 4/2 }, { display-object-name = K, *(KEYBOARD)* do-access = "WACI", dimensions = "two", x-dimension = { x-bound = "unbounded", x-addressing = "no constraint", x-absolute = "yes", *(See Definitive Note 4)* x-window = profile-argument-r1 }, y-dimension = { y-bound = "unbounded", y-addressing = "higher only", y-absolute = "no", y-window = 1 19 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) }, erasure-capability = "yes", repertoire-capability = 2, repertoire-assignment = profile-argument-r2, repertoire-assignment = <ESC> 2/5 2/15 4/2 } }, Control-objects = *(multiple occurrence)* { { *(SYNCHRONIZE)* CO-name = SY, CO-access = "NSAC", CO-category = "symbolic", CO-size = 1, CO-priority = "urgent" }, { *(DISPLAY-SIGNAL)* CO-name = DI, CO-access = "WACA", CO-category = "boolean", CO-size = 5, CO-priority = "normal", CO-trigger = "selected" }, { *(KEYBOARD-SIGNAL)* CO-name = KB, CO-access = "WACI", CO-category = "boolean", CO-size = 5, CO-priority = "normal", CO-trigger = "selected" }, { *(NEGOTIATION BY INITIATOR)* CO-name = NI, CO-access = "WACI", CO-category = "boolean", CO-size = 4, CO-priority = "normal", CO-trigger = "selected" }, { *(NEGOTIATION BY ACCEPTOR)* CO-name = NA, CO-access = "WACA", CO-category = "boolean", CO-size = 4, CO-priority = "normal", CO-trigger = "selected" }, 20 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) { *(GO-AHEAD)* CO-name = GA, CO-access = "NSAC", CO-category = "boolean", CO-size = 1, CO-priority = "normal", CO-trigger = "selected" } }, Device-objects = *(double occurrence)* { { device-name = DISPLAY-DEVICE, device-display-object = D, device-default-CO-initial-value = 1."true",*("on")* device-minimum-X-array-length = 1,*(no constraint)* device-minimum-Y-array-length = 1,*(no constraint)* device-control-object = SY, device-control-object = NA, device-control-object = DI, device-control-object = GA, *(SYNC,NEGOTIATE-ACCEPTOR,DISPLAY-SIGNAL, GO-AHEAD)* device-default-CO-access = "WACA", device-default-CO-priority = "normal" *(other device object parameters assume corresponding DO values)* }, { device-name = KEYBOARD-DEVICE, device-display-object = K, device-default-CO-access = "WACI", device-default-CO-priority = "normal", device-default-CO-initial-value = 1."true",*("on")* device-minimum-X-array-length = 1,*(no constraint)* device-minimum-Y-array-length = 1,*(no constraint)* device-control-object = SY, device-control-object = NI, device-control-object = KB, device-control-object = GA, *(SYNC,NEGOTIATE-INITIATOR,KEYBOARD-SIGNAL, GO-AHEAD)* *(other device object parameters assume corresponding DO values)* } }, Type of delivery control = "simple-delivery-control." 21 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 8.1.4 Profile arguments r1 - is used to represent the line length as the value of VTE parameter x-window for both display objects. This argument is mandatory and takes a nonnegative integer value. This argument is identified by the identifier for x-window for display object D. r2 - is used to designate the default repertoire for both display objects. This argument is optional, if not present the full US ASCII set is the default. This argument is identified by the identifier for repertoire assignment for the display object D. 8.1.5 Profile dependent control object information This profile does not reference any Control Objects which are not defined within this profile. 8.1.6 Profile notes 8.1.6.1 Definitive notes 1. Booleans in the KB and DI control objects are used in this profile to correspond to TELNET commands as follows: Table 7 - KB/DI CO value definitions Control Boolean TELNET Object DI/KB 1 IP DI/KB 2 AO DI/KB 3 AYT DI/KB 4 DM DI/KB 5 BREAK The equivalent of a TELNET command is achieved by selecting the boolean that corresponds to the desired TELNET command. Selecting a boolean in the DI or KB control object means setting the value of the desired boolean to "true." The usage of the mask element of the boolean update is as specified in ISO 9041. 22 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 2. The equivalent of a TELNET SYNCH command is achieved by updating the SY control object with the single symbolic value of "SYNCH" (which is mapped onto the integer value 1), and immediately updating the DI (or KB) control object selecting the DM boolean. IP, AO, AYT, or BREAK commands may be accompanied by a SYNCH command by updating the SY control object and then updating the DI or KB control object selecting both the DM and the other desired boolean. When an update to the SY control object is received subsequent display object updates are discarded until an update to the DI or KB control object is received selecting the DM bit. If a VT-BREAK is received after an SY CO update has been received and prior to the corresponding DI or KB CO update selecting the DM boolean, the discarding of updates is terminated. This is necessary because the VT-BREAK may have caused the DI or KB CO update to be purged. 3. The NI and NA control objects are used to emulate the TELNET option negotiation facility. The facility is symmetric, allowing either party to open negotiation for a change of mode, and every negotiation must be accepted or rejected by the opposite party. The rules for negotiation for each of the option controls are as stated in RFC 854 and as given below: a. Only open negotiation for a change from the current state; b. Only acknowledge negotiation for a change from the current state; c. Do not send any object updates with a negotiation outstanding except an update to the NI (or NA) control object to acknowledge negotiation. For full symmetry, both the NI and NA control objects have the same value definition and consist of 4 booleans with the semantics given in Table 8. 23 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Table 8 - NI/NA CO value definition BIT Option Value 1 Remote Echo "false" Echo is Local; "true" Echo is remote 2 Suppress Go "false" GO Ahead; Ahead "true" Suppress Go Ahead 3 Binary WACA "true" use binary WACA; "false" use default or negotiated repertoire for WACA display object 4 Binary WACI "true" use binary WACI; "false" use default or negotiated repertoire for WACI display object Booleans 3 and 4 control the use of the Transparent character set for the D and K display objects respectively. A value of "true" indicates the use of the binary repertoire; "false" indicates the use of the negotiated repertoire. When a party wants to change a repertoire assignment, it must complete a successful TELNET negotiation to change the option control. Then the party with the access rights to the display object in question is required to perform the corresponding secondary attribute modal update. 4. The TELNET EC (erase character) command will be mapped to a pointer relative (x:= x-1) update and an erase current update. This is the only instance when backward explicit addressing is permitted. The TELNET EL (erase line) command will be mapped to an erase-full-x-array update (an erase operation where the extent is defined as <"start-x,"(Yc,Xc-1)> and a pointer update to set x = 1. This is the only instance when absolute explicit addressing is permitted. 5. The X address of the pointer can be moved forward only by implicit pointer addressing. Addressing of the Y dimension is limited to the next X-array update operation. 6. The VT next X-array update operation will be sent in place of the TELNET NVT "CR,LF" sequence. 24 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 7. While the "binary" repertoire is being used no mapping to pointer addressing or erase operations will be done. 8. The repertoire designation "7-bit ASCII (G0+C0)" refers to the repertoire invoked by ISO 2022 defined character set designating escape sequences <ESC> 2/8 4/2, "void," <ESC> 2/1 4/0. The repertoire designation "7-bit ASCII (G0 only)" refers to the repertoire invoked by the ISO 2022 defined character set designating escape sequence <ESC> 2/8 4/2. The designation "binary" refers to the "Virtual Terminal Service Transparent Set" registered in the International Register under ISO 2375 register value 125 and invoked by the escape sequence <ESC> 2/5 2/15 4/2. 9. No termination event list is specified so that data buffering and delivery can be controlled according to context. If local echoing is enabled, the local newline or enter event shall trigger a VT-DELIVER request. With remote echo a timeout or buffer length may be used to trigger a VT- DELIVER request. This buffer length may be 1. 8.1.6.2 Informative notes 1. Users of this profile should refer to the TELNET specification (MIL-STD-1782) and RFCs 854 and 855 for semantics of the TELNET commands. These documents can be obtained by contacting SRI International, DDN Network Information Center, 333 Ravenswood Ave., Menlo Park, CA 94025, (415) 859-3695. 2. An update to the GA control object is equivalent to the TELNET Go Ahead command. 3. If the "go ahead" facility has been negotiated then following a VT-BREAK, only the association acceptor has the right to send data. In the event of VT-BREAK the echo control objects are reinitialized to "false," meaning local echo. If remote echo is desired it must be re-negotiated following VT-BREAK. 4. Negotiation of TELNET options other than echo, transmit binary, and SUPPRESS GO AHEAD is not supported by this profile. Negotiations for these three options can take place at any time during a session. 25 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 8.1.7 Specific conformance requirements The following character sets are required: The G0 character set for U.S. 7-bit ASCII (values 32-126); The full U.S. 7-bit ASCII (values 0-127). The transparent character set, see Definitive Note 8 in clause 8.1.6.1. 8.2 Transparent profile See PDISP 11187-6 (AVT15 A-mode Transparent Application profile). 8.3 Forms profile See PDISP 11187-3 (AVT22 S-Mode Forms Application Profile). PDISP 11187-3 contains significant technical differences from the earlier forms profile contained within these agreements. 8.4 X3 profile OIW VTE-Profile X3-1989 ( r1, r2, r3, r4, r5, r6 ) 8.4.1 Introduction This profile provides support for CCITT X.3 PAD compatible operation. The purpose of this profile is two-fold: a) to provide a transitional environment for applications that assume the availability of X.3 parameters with which to control the behavior of the terminal-system; b) to facilitate a gateway function between ISO-VTP and X.3. 26 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 8.4.2 Association requirements 8.4.2.1 Functional units The Structured CO Functional Unit is mandatory. The Urgent Data Functional Unit is optional. 8.4.2.2 Mode This is an A-mode profile. 8.4.3 Profile body Display-objects = { { display-object-name = D1, DO-access = profile-argument-r1, dimensions = "one", x-dimension = { x-bound = "unbounded", x-addressing = "not-permitted", x-absolute = "no", x-window = 0 }, 27 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) repertoire-assignment = <ESC> 2/5 2/15 4/2 *( VTS Transparent Set )* }, { display-object-name = D2, DO-access = opposite of profile-argument-r1, dimensions = "one", x-dimension = { x-bound = "unbounded", x-addressing = "not-permitted", x-absolute = "no", x-window = 0 }, repertoire-assignment = <ESC> 2/5 2/15 4/2 *( VTS Transparent Set )* }, }, Control-objects = { { *( PAD - Each element of the PAD CO represents a CCITT PAD parameter. The CO-element-id of each element has been chosen so that it would be the same value as the CCITT PAD parameter number that it represents. The PAD CO is used both to set CCITT PAD parameter-equivalent values and to reply to an update to the READ CO. See Definitive Note 25 for conventions concerning updates to this CO. )* CO-name = PAD, CO-structure = 22, CO-access = "NSAC", CO-priority = "normal", CO-trigger = "not-selected", { *( X.3 parameter 1 -- PAD recall )* CO-element-id = 1, CO-category = "transparent", CO-size = 8 }, { *( X.3 parameter 2 -- PAD echo )* CO-element-id = 2, CO-category = "boolean", CO-size = 1 }, { *( X.3 parameter 3 -- Data Forwarding Character )* CO-element-id = 3, CO-category = "boolean", CO-size = 7 }, 28 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) { *( X.3 parameter 4 -- Idle Timer Delay )* CO-element-id = 4, CO-category = "integer", CO-size = 255 }, { *( X.3 parameter 5 -- Ancillary Device Control )* CO-element-id = 5, CO-category = "boolean", CO-size = 1 }, { *( X.3 parameter 6 -- Control of PAD Signals )* CO-element-id = 6, CO-category = "transparent", CO-size = 4 }, { *( X.3 parameter 7 -- PAD action on receipt of Break )* CO-element-id = 7, CO-category = "boolean", CO-size = 5 }, { *( X.3 parameter 8 -- Discard Output )* CO-element-id = 8, CO-category = "boolean", CO-size = 1 }, { *( X.3 parameter 9 -- Padding After <CR> )* CO-element-id = 9, CO-category = "integer", CO-size = 7 }, { *( X.3 parameter 10 -- Line Folding )* CO-element-id = 10, CO-category = "integer", CO-size = 255 }, { *( X.3 parameter 11 -- Device Speed )* CO-element-id = 11, CO-category = "symbolic", CO-category = 19 }, { *(X.3 parameter 12 -- Flow Control by Device )* CO-element-id = 12, CO-category = "boolean", CO-size = 1 }, { *( X.3 parameter 13 -- Insert <LF> after <CR> )* CO-element-id = 13, CO-category = "boolean", CO-size = 3 }, { *( X.3 parameter 14 -- Linefeed Padding )* CO-element-id = 14, CO-category = "integer", CO-size = 7 }, { *( X.3 parameter 15 -- Editing )* CO-element-id = 15, CO-category = "boolean", CO-size = 1 }, { *( X.3 parameter 16 -- Character Delete )* 29 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) CO-element-id = 16, CO-category = "character", CO-repertoire-assignment *( any from C0 )* = "void", "void", <ESC> 2/1 4/0, CO-size = 1 }, { *( X.3 parameter 17 -- Line Delete )* CO-element-id = 17, CO-category = "character", CO-repertoire-assignment *( any from C0 )* = "void", "void", <ESC> 2/1 4/0, CO-size = 1 }, { *( X.3 parameter 18 -- Line Display )* CO-element-id = 18, CO-category = "character", CO-repertoire-assignment *( any from C0 )* = "void", "void", <ESC> 2/1 4/0, CO-size = 1 }, { *( X.3 parameter 19 -- Editing Service Signals )* CO-element-id = 19, CO-category = "transparent", CO-size = 8 }, { *( X.3 parameter 20 -- Echo Mask )* CO-element-id = 20, CO-category = "boolean", CO-size = 8 }, { *( X.3 parameter 21 -- Parity Treatment )* CO-element-id = 21, CO-category = "boolean", CO-size = 2 }, { *( X.3 parameter 22 -- Page Wait )* CO-element-id = 22, CO-category = "integer", CO-size = 256 } }, { *( READ - Each boolean of the READ CO represents an element-id of the PAD CO with the same identifying value. The READ CO is used to request the current values of PAD CO, which may have been changed by some local agent. See the description of the PAD CO for how the update to this CO modifies the access to the PAD CO. )* CO-name = READ, CO-structure = 1, CO-access = opposite of profile-argument-r1, CO-priority = "normal", CO-trigger = "not-selected", CO-category = "boolean", CO-size = 22 30 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) }, { *( Break Out-of-Band - receipt of this control object represents "X.25 Interrupt"; use is applicable when boolean 1 of element-id 7 in PAD CO has the value "true." )* CO-name = BO, CO-structure = 1, CO-access = "NSAC", CO-priority = "urgent", CO-trigger = "not-selected", CO-category = "symbolic", CO-size = 2 }, { *( Break In-Band - receipt of this control object represents "indication of break"; use is applicable when boolean 3 of element-id 7 in PAD CO has the value "true." )* CO-name = BI, CO-structure = 1, CO-access = "NSAC", CO-priority = "normal", CO-trigger = "selected", CO-category = "symbolic", CO-size = 2 }, 31 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) { *( CUD - This CO is used to optionally convey Call User Data which is normally carried in the CCITT PAD call. The CO is not updatable, but may be given initial content value by special profile arguments r2 and r3. The CO is parametric, with two elements, one representing the protocol identifier field, and the other representing the call data field containing user data. )* CO-name = CUD, CO-structure = 2, CO-access = "no-access", { *( Protocol Identifier )* CO-element-id = 1, CO-category = "character", CO-repertoire-assignment *( VTS Transparent Set )* = <ESC> 2/5 2/15 4/2, CO-size = 4 }, { *( User Data )* CO-element-id = 2, CO-category = "character", CO-repertoire-assignment *(VTS Transparent Set )* = <ESC> 2/5 2/15 4/2, CO-size = 124 } }, { *( DTE - This CO is used to optionally indicate the calling and called DTE addresses which are normally available in a true CCITT PAD environment. They may not be updated, but may be given initial content values by special profile arguments r4 and r5. )* CO-name = DTE, CO-structure = 2, CO-access = "no-access", { *( Calling DTE address )* CO-element-id = 1, CO-category = "character", CO-repertoire-assignment *(VTS Transparent Set )* = <ESC> 2/5 2/15 4/2, CO-size = 15 }, { *( Called DTE address )* CO-element-id = 2, CO-category = "character", CO-repertoire-assignment *(VTS Transparent Set )* = <ESC> 2/5 2/15 4/2, CO-size = 15 } }, 32 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) { *( FAC - This CO is used to optionally indicate the CCITT facilities which are normally negotiable during the establishment of a PAD virtual circuit. The negotiation takes place via special profile argument r6, where the initiator may propose the initial content value, and the acceptor may return other values. )* CO-name = FAC, CO-structure = 1, CO-access = "no-access", CO-category = "character", CO-repertoire-assignment *(VTS Transparent Set )* = <ESC> 2/5 2/15 4/2, CO-size = 127 }, }, Device-objects *(double occurrence)* = { { device-name = DEVICE-1, device-default-CO-access = profile-argument-r1, device-default-CO-priority = "normal", device-default-CO-trigger = "not-selected", device-default-CO-initial-value = 1."true", device-minimum-X-array-length = 1, *(no constraint)* device-control-object = { BI, BO, PAD }, device-display-object = D1 *(termination parameters are controlled explicitly through the values assigned to elements 3 and 4 of the PAD Control Object)* }, { device-name = DEVICE-2, device-default-CO-access = opposite of profile-argument-r1, device-default-CO-priority = "normal", device-default-CO-trigger = "not-selected", device-default-CO-initial-value = 1."true", device-minimum-X-array-length = 1, *(no constraint)* device-control-object = { READ, PAD }, device-display-object = D2 } }, Type of delivery control = "simple-delivery-control." 33 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 8.4.4 Profile arguments r1 - is mandatory, and is used to establish the access rules for the display objects and several of the control objects. If the terminal-system, i.e., that which includes the equivalent of the PAD function, establishes the VTE-profile then the value of r1 should be "WACI." If the system not including the PAD function establishes the VTE-profile then the value of r1 should be "WACA." This argument takes one of the values "WACI" or "WACA." It is identified by the identifier for DO-access for display object D1. r2 - is an optional special profile argument, and is used to set the initial content value of element 1 of the CUD CO. The value is encoded from the binary form to the ASN.1 type PrintableString according to the algorithm described in Definitive Note 24. This argument is assigned the identifier "Pp-1." r3 - is an optional special profile argument, and is used to set the initial content value of element 2 of the CUD CO. The value is encoded from the binary form to the ASN.1 type PrintableString according to the algorithm described in Definitive Note 24. This argument is assigned the identifier "Pp-2." r4 - is an optional special profile argument, and is used to set the initial content value of element 1 of the DTE CO. The value is encoded from the binary form to the ASN.1 type PrintableString according to the algorithm described in Definitive Note 24. This argument is assigned the identifier "Pp-3." r5 - is an optional special profile argument, and is used to set the initial content value of element 2 of the DTE CO. The value is encoded from the binary form to the ASN.1 type PrintableString according to the algorithm described in Definitive Note 24. This argument is assigned the identifier "Pp-4." r6 - is an optional special profile argument, and is used to set the initial content value of the FAC CO. The value is encoded from the binary form to the ASN.1 type PrintableString according to the algorithm described in Definitive Note 24. This argument is assigned the identifier "Pp-5." 34 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 8.4.5 Profile notes 8.4.5.1 Definitive notes 1. The value assigned to element 1 of PAD CO selects the character used to return control to the terminal-system. The valid values and associated meanings are: Table 9 - PAD CO data element 1 value definition value meaning 0 not-permitted 1 1/0 character (DLE) 32- graphic 126 character 2. The value assigned to element 2 of PAD CO determines whether or not characters are echoed at the terminal-system. When the value of this boolean is "true," then the characters are echoed at the terminal-system. 3. The values assigned to element 3 of PAD CO control the forwarding of characters from the terminal-system to the application-system based on the character value. The defined booleans and associated meanings are: 35 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Table 10 - PAD CO data element 3 value definition boolea meaning n 1 alphanumeric (A-Z, a-z, 0-9) 2 character 0/13 (CR) 3 characters 1/11 (ESC), 0/7 (BEL), 0/5 (ENQ), 0/6 (ACK) 4 characters 7/15 (DEL), 1/8 (CAN), 1/2 (DC2) 5 characters 0/3 (ETX), 0/4 (EOT), 6 characters 0/9 (HT), 0/10 (LF), 0/11 (VT), 0/12 (FF) 7 all others in column 0 and 1 not already included above 4. The value assigned to element 4 of PAD CO controls the forwarding of characters from the terminal-system to the application-system based on the duration of idle time elapsed between consecutive characters received by the terminal-system from the device. The valid values include any non-negative integer 0-255; a value between 1 and 255 indicates the time-out in twentieths of a second; a value of 0 means that a time-out is not a forwarding condition. 5. The value assigned to element 5 of PAD CO determines whether the XON/XOFF flow-control characters (1/1 and 1/3) are available for use by the terminal-system. When the value of this element is "true," then the flow-control characters are available, and the terminal-system may use them to indicate to the device its readiness to accept characters from it. 6. The value assigned to element 6 of PAD CO determines whether the terminal-system issues messages, called PAD service signals, to the device during the association. The specific service signals are not a part of this profile definition, only the control of their issue. 7. The values assigned to element 7 of PAD CO determine the behavior at the terminal-system when a Break is received 36 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) from the device. The defined booleans and associated meanings are: Table 11 - PAD CO data element 7 value definition boolea meaning n 1 update BO CO 2 release the association 3 update BI CO 4 return control to terminal- system 5 discard data from application- system When all booleans have the value "false," there is no action at the terminal-system when a Break is received. When boolean 1 is "true" and booleans 3 and 5 are "false" and a Break is received from the device, the terminal system updates the BO CO with the symbolic value "alone." When booleans 1 and 3 are "true" and boolean 5 is "false" and a Break is received from the device, the terminal system updates the BO CO with the symbolic value "prepare" followed by an update to the BI CO with the symbolic value "unconfirmed." When booleans 1, 3 and 5 are all "true" and a Break is received from the device, the terminal system updates the BO CO with the symbolic value "prepare" followed by an update to the BI CO with the symbolic value "confirmed" and discards all display object updates from the application system until it receives an update to the PAD CO selecting element-id 8. If boolean 1 is "false," then booleans 3 and 5 must be "false." If boolean 3 is "false," then boolean 5 must be "false." 37 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Table 12 - BI CO values and semantics Symbolic Integer Value Value unconfirmed 0 confirmed 1 Table 13 - BO CO values and semantics Symbolic Integer Value Value alone 0 prepare 1 8. The value assigned to element 8 of PAD CO determines whether or not the terminal-system discards data from the application-system. This element works with element 7 to acknowledge the receipt of the Break and resume normal processing of display-object updates. The only valid value of this boolean in an update is "false." 9. The value assigned to element 9 of PAD CO indicates the number of padding characters to be generated by the terminal-system to the device following a carriage return character. The valid values are integers in the range 0-7. 10. The value assigned to element 10 of PAD CO indicates the number of graphic characters sent to the device after which the terminal-system will insert a carriage return. The valid values are integers in the range 0-255, where a value of 0 means that this function is not performed. 11. The value assigned to element 11 of PAD CO indicates the bit-transmission speed of the device. This element may only appear in an update sent to the application-system in response to an update of the READ CO when boolean 11 has the value "true." 12. The value assigned to element 12 of PAD CO determines whether the XON/XOFF flow-control characters (1/1 and 1/3) are available for use by the device. When the value of this element is "true," then the flow-control characters are 38 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) available, and the device may use them to indicate to the terminal-system its readiness to accept characters from it. 13. The values assigned to element 13 of PAD CO determine under which situations a linefeed is inserted following a carriage return character. The valid values and associated meanings are: Table 14 - PAD CO data element 13 value definition boolea meaning n 1 insert linefeed after carriage return sent to device 2 insert linefeed after carriage return received from device 3 insert linefeed after carriage return echoed to the device 14. The values assigned to element 14 of PAD CO determine the number of padding characters generated by the terminal- system to the device following a linefeed character. The valid values are any number in the range 0-7. 15. The value assigned to element 15 of PAD CO determines whether or not the terminal-system performs data-editing. When this CO has value "true," the values of the elements 3 and 4 of the PAD CO are ignored. 16. The value assigned to element 16 of PAD CO determines which character is used in editing the line to signify the function "delete character." The valid values are the IA5 characters, decimal value 0-127. Only applicable if the value of element 15 of PAD CO is "true." 17. The value assigned to element 17 of PAD CO determines which character is used in editing to signify the function "delete line." The valid values are the IA5 characters, decimal value 0-127. Only applicable if the value of element 15 of PAD CO is "true." 18. The value assigned to element 18 of PAD CO determines which character is used in editing to signify the function "display line." The valid values are the IA5 characters, decimal value 0-127. Only applicable if the value of 39 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) element 15 of PAD CO is "true." 19. The value assigned to element 19 of PAD CO determines whether the terminal-system provides for editing of PAD service signals. The valid values and meanings are as follows: Table 15 - PAD CO data element 19 value definitions value meaning 0 no editing 1 editing as for a paper device 2 editing as for a glass device 8 editing using one editing character 32- editing using one editing 126 character 20. The values assigned to element 20 of PAD CO determines which characters are NOT to be echoed to the device by the terminal-system. If no bits are set, then all characters are to be echoed, assuming that element 2 has the value "true." The defined booleans and associated meanings are: 40 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Table 16 - PAD CO data element 20 value definition boolea meaning n 1 Do not echo 0/13 (CR) 2 Do not echo 0/10 (LF) 3 Do not echo 0/11 (VT), 0/9 (HT), 0/12 (FF) 4 Do not echo 0/7 (BEL), 0/8 (BS) 5 Do not echo 1/11 (ESC), 0/5 (ENQ) 6 Do not echo 0/6 (ACK), 1/5 (NAK), 0/2 (STX), 0/1 (SOH), 0/4 (EOT), 1/7 (ETB), 0/3 (ETX) 7 Do not echo the editing characters defined by data elements 16, 17, and 18 of the PAD CO 8 Do not echo 7/15 (DEL) or any of the other characters belonging to C0 or C1 which are not already mentioned above 21. The value assigned to element 21 of PAD CO determines the treatment of parity on the characters received from and sent to the device from the terminal-system. The defined booleans and associated meanings are: Table 17 - PAD CO data element 21 value definition boolea meaning n 1 parity is checked on characters received from the device 2 parity is generated on characters sent to the device 22. The value assigned to element 22 of PAD CO determines the number of linefeeds that the terminal-system may send to the 41 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) device before it must wait for input from the device to request it to continue displaying characters. The range of valid values is 0-255, where a value of 0 indicates that the terminal-system need never wait. 23. The TEXT operation is the only operation allowed on the display objects. 24. Special profile arguments r2-r6 have binary values. However, due to a restriction in the standards 9040 and 9041, those binary values must be conveyed in the ASN.1 type PrintableString. This is accomplished by mapping the value of each semi-octet in the string of binary octets to an octet whose value falls in the value range of a PrintableString. The semi-octet values in the range 0000 - 1001 are mapped into the PrintableString values `0' - `9', whereas the semi-octet values in the range 1010 - 1111 are mapped into the PrintableString values `A' - `F'. The result is a string of characters which is exactly twice the length of the original string of binary octets. 25. The value of CO-access for the PAD CO is "NSAC," however a convention is followed that determines when a VT-user may update the PAD CO. Only the VT-user with access to the Display Object D2 may update the PAD CO except immediately after it has updated the READ CO. When the READ CO update is received by the opposite VT-user, it is treated as a request to update the PAD CO with the parameter values it is currently using, at which point that VT-user is required to respond. 26. The application system can update the BI CO and the terminal system shall send a Break to the device. If the symbolic value of the update is "confirmed," the terminal system shall respond with an update to the PAD CO selecting element-id 8. 8.4.5.2 Informative notes 1. Users of this profile should refer to CCITT Recommendations X.3, X.28 and X.29 for the original model for this profile. 2. The following values for the elements of the PAD CO are taken from the CCITT Simple standard profile and may prove useful: 42 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Table 18 - CCITT Simple Standard profile data value meaning element 1 1 possible to return control to terminal-system using 0/1 (DLE) 2 1."true" echo performed at the terminal- system 3 1."false", forward on receipt of any 2."true", character in C0 and C1 3."true", 4."true", 5."true", 6."true", 7."true" 4 0 no time-out used for forwarding condition 5 1."true" terminal-system may use XON/XOFF to flow-control the device 6 1."true" service signals are sent 7 2."true", all release the association when a others "false" Break is received from the device 8 1."false" deliver data to device 9 0 do not pad after CR 10 0 do not fold the line 11 read-only 12 1."true" device may use XON/XOFF to flow- control the terminal-system 13 0 do not insert LF after CR 14 0 do not pad after LF 15 1."false" do not edit data 16 7/15 (DEL) character delete 17 1/8 (CAN) line delete 18 1/2 (DC2) line display 19 1 edit as for paper 43 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 20 0 echo all characters 21 0 no parity checking or generation 22 0 no page wait 3. The following values for the elements of the PAD CO are taken from the CCITT Transparent standard profile and may prove useful. 44 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Table 19 - CCITT Transparent Standard profile data value meaning element 1 0 control may not be returned to the terminal-system 2 1."false" terminal-system does not perform character echo 3 all booleans no forwarding on character value "false" 4 20 forward on time-out of 1 second 5 1."false" terminal-system may not flow- control the device 6 1."false" service signals are never sent 7 2."true", all release the association when a others "false" Break is received from the device 8 1."false" deliver data to device 9 0 do not pad after CR 10 0 do not fold the line 11 read-only 12 1."false" device may not flow-control the terminal-system 13 0 do not insert LF after CR 14 0 do not pad after LF 15 1."false" do not edit data 16 7/15 (DEL) character delete 17 1/8 (CAN) line delete 18 1/2 (DC2) line display 19 1 edit as for paper 20 0 echo all characters 21 0 no parity checking or generation 22 0 no page wait 45 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) 8.4.6 Specific conformance requirements None. 8.5 Generalized Telnet profile See PDISP 11187-5 (AVT16 A-mode Generalized Telnet Application profile). 8.6 S-mode paged application profile See PDISP 11187-4 (AVT23 S-mode Paged Application profile). 46 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Annex A (normative) Specific ASE requirements For specific ASE Requirements identified by the Upper Layer SIG for Virtual Terminals, see Stable Implementation Agreements for Open Systems Interconnection Protocols: Part 5 - Upper Layers. 47 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Annex B (normative) Clarifications Defaults When a profile argument is not present in either the offer or value list, the default for the corresponding VTE parameter is specified by ISO 9040 if it is not given by the argument description in the profile. 48 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) Annex C (normative) Object identifiers General identifiers: oiw-vt OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) vtsig(12) } oiw-vt-pr OBJECT IDENTIFIER ::= { oiw-vt vteProfile(1) } oiw-vt-co OBJECT IDENTIFIER ::= { oiw-vt controlObject(0) } oiw-vt-co-misc OBJECT IDENTIFIER ::= { oiw-vt-co cotypemisc(0) } oiw-vt-co-tcco OBJECT IDENTIFIER ::= { oiw-vt-co cotypetcco(4) } Profiles defined by OIW VT SIG: oiw-vt-pr-telnet-1988 OBJECT IDENTIFIER ::= { oiw-vt-pr telnet-1988(0) } oiw-vt-pr-transparent-1988 OBJECT IDENTIFIER ::= { oiw-vt-pr transparent-1988(1) } oiw-vt-pr-forms-1989 OBJECT IDENTIFIER ::= { oiw-vt-pr forms-1989(2) } oiw-vt-pr-x3-1989 OBJECT IDENTIFIER ::= { oiw-vt-pr x3-1989(4) } oiw-vt-pr-generalizedTelnet OBJECT IDENTIFIER ::= { oiw-vt-pr generalizedTelnet(5) } Control Objects defined by OIW VT SIG: oiw-vt-co-misc-sa OBJECT IDENTIFIER ::= { oiw-vt-co-misc sa(0) } oiw-vt-co-misc-ua OBJECT IDENTIFIER ::= { oiw-vt-co-misc ua(1) } oiw-vt-co-misc-st OBJECT IDENTIFIER ::= { oiw-vt-co-misc st(2) } 49 PART 14 - VIRTUAL TERMINAL December 1993 (Stable) oiw-vt-co-misc-ut OBJECT IDENTIFIER ::= { oiw-vt-co-misc ut(3) } 50