home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / nist / oiw / agreemnt / 1993 / 14w_9309.txt < prev    next >
Text File  |  1993-11-04  |  68KB  |  2,574 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.           Working Implementation
  9.           Agreements for Open Systems
  10.           Interconnection Protocols:
  11.           Part 14 - Virtual Terminal
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.           Output  from   the  September   1993  Open   Systems  Environment
  25.           Implementors' Workshop (OIW)
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.           SIG Chair:          Michelle Conaway, HFSI
  60.           SIG  Editor:   Scott Wattum,  Digital  Equipment Corp.,  Workshop
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  75.  
  76.           Editor: Brenda Gray
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.                                           ii
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.           Foreword
  157.  
  158.           This part of  the Working Implementation Agreements  was prepared
  159.           by  the Virtual Terminal  Special Interest  Group (VTSIG)  of the
  160.           Open  Systems   Environment  Implementors'  Workshop (OIW).   See
  161.           Procedures Manual for Workshop charter.
  162.  
  163.           Text in this part has been approved  by the Plenary of the above-
  164.           mentioned Workshop.   This part replaces the  previously existing
  165.           chapter on this subject.
  166.  
  167.           Only the  pages that  were changed  in  December  1992 are  being
  168.           printed.   Please refer to  the  September 1992  Working Document
  169.           for additional information.
  170.  
  171.           Three normative annexes are given.
  172.  
  173.           Future changes and additions to this version of these Implementor
  174.           Agreements will be published as  a new part. Deleted and replaced
  175.           text will be shown as strikeouts.   New and replacement text will
  176.           be shown as shaded.
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.                                          iii
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.                                           iv
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  273.  
  274.                                   Table of Contents
  275.  
  276.  
  277.           Part 14 ISO Virtual Terminal Protocol . . . . . . . . . . . .   1
  278.  
  279.           0   Introduction  . . . . . . . . . . . . . . . . . . . . . .   1
  280.  
  281.           1   Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   1
  282.               1.1  Phase Ia agreements  . . . . . . . . . . . . . . . .   1
  283.               1.2  Phase Ib agreements  . . . . . . . . . . . . . . . .   1
  284.               1.3  Phase II agreements  . . . . . . . . . . . . . . . .   1
  285.  
  286.           2   Normative references  . . . . . . . . . . . . . . . . . .   1
  287.  
  288.           3   Status  . . . . . . . . . . . . . . . . . . . . . . . . .   2
  289.               3.1  Status of phase Ia . . . . . . . . . . . . . . . . .   2
  290.               3.2  Status of phase Ib . . . . . . . . . . . . . . . . .   2
  291.               3.3  Status of phase II . . . . . . . . . . . . . . . . .   2
  292.  
  293.           4   Errata  . . . . . . . . . . . . . . . . . . . . . . . . .   2
  294.  
  295.           5   Conformance . . . . . . . . . . . . . . . . . . . . . . .   3
  296.  
  297.           6   Protocol  . . . . . . . . . . . . . . . . . . . . . . . .   3
  298.  
  299.           7   OIW registered control objects  . . . . . . . . . . . . .   3
  300.               7.1  Sequenced Application (SA) . . . . . . . . . . . . .   3
  301.               7.2  Unsequenced Application (UA) . . . . . . . . . . . .   3
  302.               7.3  Sequenced Terminal (ST)  . . . . . . . . . . . . . .   3
  303.               7.4  Unsequenced Terminal (UT)  . . . . . . . . . . . . .   3
  304.               7.5  Termination Conditions CO (TC) . . . . . . . . . . .   4
  305.                    7.5.1    Entry number  . . . . . . . . . . . . . . .   4
  306.                    7.5.2    Name of sponsoring body . . . . . . . . . .   4
  307.                    7.5.3    Date  . . . . . . . . . . . . . . . . . . .   4
  308.                    7.5.4    Identifier  . . . . . . . . . . . . . . . .   4
  309.                    7.5.5    Descriptor value  . . . . . . . . . . . . .   4
  310.                    7.5.6    CO VTE-parameters . . . . . . . . . . . . .   4
  311.                    7.5.7    CO values, semantic and update syntax . . .   5
  312.                    7.5.8    Additional information  . . . . . . . . . .   6
  313.                    7.5.9    Usage . . . . . . . . . . . . . . . . . . .   6
  314.  
  315.           8   OIW defined VTE-profiles  . . . . . . . . . . . . . . . .   6
  316.               8.1  Telnet profile . . . . . . . . . . . . . . . . . . .   6
  317.               8.2  Transparent profile  . . . . . . . . . . . . . . . .   6
  318.               8.3  Forms profile  . . . . . . . . . . . . . . . . . . .   6
  319.               8.4  X3 profile . . . . . . . . . . . . . . . . . . . . .   6
  320.               8.5  Generalized Telnet profile . . . . . . . . . . . . .   6
  321.               8.6  Scroll profile . . . . . . . . . . . . . . . . . . .   7
  322.                    8.6.1    Introduction  . . . . . . . . . . . . . . .   7
  323.  
  324.  
  325.                                           v
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  339.  
  340.                    8.6.2    Association requirements  . . . . . . . . .   7
  341.                    8.6.2.1  Functional units  . . . . . . . . . . . . .   7
  342.                    8.6.2.2  Mode  . . . . . . . . . . . . . . . . . . .   7
  343.                    8.6.3    Profile body  . . . . . . . . . . . . . . .   7
  344.                    8.6.4    Profile argument definitions  . . . . . . .  12
  345.                    8.6.5    Profile dependent CO information  . . . . .  13
  346.                    8.6.6    Profile notes . . . . . . . . . . . . . . .  13
  347.                    8.6.6.1  Definitive notes  . . . . . . . . . . . . .  13
  348.                    8.6.6.2  Informative notes . . . . . . . . . . . . .  13
  349.                    8.6.7    Specific conformance requirements . . . . .  15
  350.               8.7  S-mode Paged Application profile . . . . . . . . . .  15
  351.  
  352.           Annex A (normative)
  353.  
  354.           Specific ASE requirements . . . . . . . . . . . . . . . . . .  16
  355.  
  356.           Annex B (normative)
  357.  
  358.           Clarifications  . . . . . . . . . . . . . . . . . . . . . . .  17
  359.  
  360.           Annex C (normative)
  361.  
  362.           Object identifiers  . . . . . . . . . . . . . . . . . . . . .  18
  363.  
  364.           Annex D (informative)
  365.  
  366.           Recommended  practice_Operating X  Window System  over  OSI upper
  367.           layers  . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
  368.               D.1  Background . . . . . . . . . . . . . . . . . . . . .  19
  369.               D.2  Mapping specification  . . . . . . . . . . . . . . .  20
  370.                    D.2.1    Summary of mapping  . . . . . . . . . . . .  20
  371.                    D.2.2    Association establishment . . . . . . . . .  20
  372.                    D.2.3    Data exchange . . . . . . . . . . . . . . .  21
  373.                    D.2.4    Connection termination  . . . . . . . . . .  21
  374.               D.3  Required OSI upper layer facilities. . . . . . . . .  22
  375.                    D.3.1    X client mOSI compliance  . . . . . . . . .  22
  376.                    D.3.2    X server mOSI compliance  . . . . . . . . .  23
  377.               D.4  Object identifiers . . . . . . . . . . . . . . . . .  23
  378.               D.5  Recommended encoding . . . . . . . . . . . . . . . .  24
  379.               D.6  Differences from ETG13 . . . . . . . . . . . . . . .  24
  380.                    D.6.1    Abstract and transfer syntax names  . . . .  24
  381.                    D.6.2    Application  process  title and  application
  382.                             entity qualifier  . . . . . . . . . . . . .  25
  383.  
  384.           Annex E (normative)
  385.  
  386.           (ANNEX E  WAS FORMALLY  ANNEX D. THE  WORKSHOP STYLES  CHANGE THE
  387.           NUMBERING AUTOMATICALLY.)  OIW XOSI contributions . . . . . .  26
  388.               E.1  XDMCPOSI . . . . . . . . . . . . . . . . . . . . . .  26
  389.                    E.1.1    Introduction  . . . . . . . . . . . . . . .  26
  390.  
  391.                                           vi
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  405.  
  406.                    E.1.2    Functional overview . . . . . . . . . . . .  26
  407.                    E.1.2.1  ACSE requirements . . . . . . . . . . . . .  26
  408.                    E.1.2.2  Presentation requirements . . . . . . . . .  26
  409.                    E.1.2.3  Session requirements  . . . . . . . . . . .  27
  410.                    E.1.2.4  Abstract and transfer syntaxes  . . . . . .  27
  411.                    E.1.2.5  XDMCP to OSI mapping  . . . . . . . . . . .  27
  412.                    E     .     1     .     2     .     5     .     1
  413.                             Query - display to manager  . . . . . . . .  27
  414.                    E     .     1     .     2     .     5     .     2
  415.                             IndirectQuery - display to manager  . . . .  28
  416.                    E     .     1     .     2     .     5     .     3
  417.                             IndirectQuery - manager to manager  . . . .  28
  418.                    E     .     1     .     2     .     5     .     4
  419.                             Indirect query - manager to display . . . .  29
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.                                          vii
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.           Part 14 ISO Virtual Terminal Protocol
  471.  
  472.                Editor's Note  -  References  to Stable  Agreements in  this
  473.                part refer to Version 5. 
  474.  
  475.  
  476.           0   Introduction
  477.  
  478.           See Stable Agreements.
  479.  
  480.  
  481.           1   Scope
  482.  
  483.  
  484.           1.1    Phase Ia agreements
  485.  
  486.           See Stable Agreements.
  487.  
  488.  
  489.           1.2    Phase Ib agreements
  490.  
  491.           See Stable Agreements regarding Forms profile.
  492.  
  493.           The  Scroll   profile  is  intended  to   support  line-at-a-time
  494.           applications and has colour and text attribute capabilities.
  495.  
  496.  
  497.           1.3    Phase II agreements
  498.  
  499.           See  Stable Agreements regarding X.3 profile,  Generalized Telnet
  500.           profile and the S-mode Paged Application Profile.
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.                                           1
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  537.  
  538.  
  539.  
  540.           2   Normative references
  541.  
  542.           See Stable Agreements.
  543.  
  544.           3   Status
  545.  
  546.           These agreements are being done in phases.  Below is the  current
  547.           status of each phase.
  548.  
  549.  
  550.           3.1    Status of phase Ia
  551.  
  552.           The Phase Ia  Agreements, which include  the profiles for  Telnet
  553.           and  Transparent operation, are  complete and were  stabilized in
  554.           May, 1988.  See Stable Agreements.
  555.  
  556.  
  557.           3.2    Status of phase Ib
  558.  
  559.           The Forms profile of  Phase 1b  was stabilized in December, 1988.
  560.           Alignment  with EWOS  Forms profile  was  achieved in  September,
  561.           1989.  See Stable Agreements.
  562.  
  563.  
  564.           3.3    Status of phase II
  565.  
  566.           Phase II is still in  progress and includes the remaining profile
  567.           work for the Scroll profile.
  568.  
  569.           The S-mode Paged Application Profile is being progressed as PDISP
  570.           11187-2 (AVT-23 S-mode Paged Application Profile).
  571.  
  572.           The X.3 profile was stabilized in December 15, 1989.
  573.  
  574.           The Generalized  Telnet profile  was stabilized  in December  13,
  575.           1991.
  576.  
  577.           It is intended that Phase  II agreements be compatible with Phase
  578.           I agreements.
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.                                           2
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  603.  
  604.           4   Errata
  605.  
  606.           See Stable Agreements.
  607.  
  608.           5   Conformance
  609.  
  610.           See Stable Agreements.
  611.  
  612.  
  613.           6   Protocol
  614.  
  615.           See Stable Agreements.
  616.  
  617.  
  618.           7   OIW registered control objects
  619.  
  620.  
  621.           7.1    Sequenced Application (SA)
  622.  
  623.           See Stable Agreements.
  624.  
  625.  
  626.           7.2    Unsequenced Application (UA)
  627.  
  628.           See Stable Agreements.
  629.  
  630.  
  631.           7.3    Sequenced Terminal (ST)
  632.  
  633.           See Stable Agreements.
  634.  
  635.  
  636.           7.4    Unsequenced Terminal (UT)
  637.  
  638.           See Stable Agreements.
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.                                           3
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  669.  
  670.  
  671.  
  672.           7.5    Termination Conditions CO (TC)
  673.  
  674.           This CO  is an instance of the standard  type TCCO, as defined in
  675.           ISO 9040.  It  is initially designed for use with  the OIW Scroll
  676.           VT profile, though  as a registered CO it is available for use by
  677.           other VT profiles.
  678.  
  679.           In addition to the three standardized data elements,  it provides
  680.           a definition and  update syntax for further types  of Termination
  681.           Condition.    Each  additional  type  is  available  for  use  in
  682.           additional data elements  of the CO.  The number and type of such
  683.           additional data elements is defined in the profile using this CO.
  684.  
  685.  
  686.           7.5.1   Entry number
  687.  
  688.           To be supplied by the Registration Authority.
  689.  
  690.  
  691.           7.5.2   Name of sponsoring body
  692.  
  693.           OSI Implementors' Workshop for Implementors of OSI, VTSIG.
  694.  
  695.  
  696.           7.5.3   Date
  697.  
  698.           The date of submission of this proposal is September 15, 1989.
  699.  
  700.  
  701.           7.5.4   Identifier
  702.  
  703.           oiw-vt-co-tcco-tc    OBJECT  IDENTIFIER ::=  {  oiw-vt-co-tcco   
  704.           tc(0) }
  705.  
  706.  
  707.           7.5.5   Descriptor value
  708.  
  709.           "OIW VT CO for Termination Conditions"
  710.  
  711.  
  712.           7.5.6   CO VTE-parameters
  713.           CO-structure   =  , *(not defined in  this registration, see note
  714.                               1 in 14.7.5.8)*
  715.           CO-priority    = "normal"
  716.                {
  717.                CO-element-id  = 1, *(termination length)*
  718.                CO-category    = "integer",
  719.                CO-size   = 65535 },
  720.  
  721.                                           4
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  735.  
  736.                {
  737.                CO-element-id  = 2, *(time-out mantissa)*
  738.                CO-category    = "integer",
  739.                CO-size   = 65535 },
  740.                {
  741.                CO-element-id  = 3, *(time-out exponent)*
  742.                CO-category    = "integer",
  743.                CO-size   = 65535 },
  744.           *(the  following represents  possibly  multiple invocations  of a
  745.           generic data element type, according to the value of CO-structure
  746.           for the instance of this CO. )*
  747.                FOR N=4 to CO-structure
  748.                {
  749.                CO-element-id  = N, *(acts  as  integer identifier  for  the
  750.                                    events in this element)*
  751.                CO-category    = "transparent",
  752.                CO-size   =    *(not defined in  this registration, see note
  753.                               2 in 14.7.5.8)* }
  754.  
  755.           7.5.7   CO values, semantic and update syntax
  756.  
  757.           The value fields for data elements  1,2 and 3 are defined in  ISO
  758.           9040.
  759.  
  760.           The value  field for each  additional data element is  defined by
  761.           the  following  ASN.1  construct which  also  defines  the update
  762.           syntax.
  763.  
  764.           TermCondList   ::= SEQUENCE OF CHOICE {
  765.                     void           [0] IMPLICIT NULL,
  766.                     x3ForwardingCond    [1] IMPLICIT INTEGER,
  767.                     stEventList         [2] IMPLICIT Range,
  768.                     anySTUpdate         [3] IMPLICIT NULL,
  769.                     stEventMasks        [4] IMPLICIT MaskValues,
  770.                     dOChars        [5] IMPLICIT DOCharacters }
  771.  
  772.           Range          ::= SEQUENCE OF SEQUENCE {
  773.                                    [1] IMPLICIT LogEvent,
  774.                                    [2] IMPLICIT LogEvent OPTIONAL }
  775.           -- each pair represents an interval of  values as defined for the
  776.           value field of
  777.           --CO ST, see 14.7.3.7.   The second value in each  pair shall not
  778.           be smaller than
  779.           --the first value.   If the second value is omitted, the interval
  780.           contains only 
  781.           --the specified first value.
  782.  
  783.           LogEvent  ::= INTEGER
  784.           -- values as defined for value field of CO ST, see 14.7.3.7.
  785.  
  786.  
  787.                                           5
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  801.  
  802.           MaskValues     ::= SEQUENCE OF SEQUENCE {
  803.                     mask           [1] IMPLICIT LogEvent,
  804.                     value               [2] IMPLICIT LogEvent }
  805.  
  806.           DOCharacters   ::= SEQUENCE OF SEQUENCE {
  807.                                    [1] IMPLICIT Repref,
  808.                                    [2] IMPLICIT INTEGER,
  809.                                    [3] IMPLICIT INTEGER OPTIONAL }
  810.  
  811.           Repref         ::= INTEGER
  812.           -- index to the list of repertoires for the Display Object
  813.  
  814.           7.5.8   Additional information
  815.  
  816.                NOTE - The  value of CO-structure is defined  in the profile
  817.                to   be  the  number  of  types  of  termination  conditions
  818.                available for use within the profile.
  819.  
  820.                NOTE - The value of CO-size for each additional data element
  821.                of this  CO must  be defined within  the profile  definition
  822.                which uses those additional termination conditions.
  823.  
  824.  
  825.           7.5.9   Usage
  826.  
  827.           Defined in profile.
  828.  
  829.  
  830.           8   OIW defined VTE-profiles
  831.  
  832.  
  833.           8.1    Telnet profile
  834.  
  835.           See Stable Agreements.
  836.  
  837.  
  838.           8.2    Transparent profile
  839.  
  840.           See Stable Agreements.
  841.  
  842.  
  843.           8.3    Forms profile
  844.  
  845.           See Stable Agreements.
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.                                           6
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  867.  
  868.           8.4    X3 profile
  869.  
  870.           See Stable Agreements.
  871.  
  872.  
  873.           8.5    Generalized Telnet profile
  874.  
  875.           See Stable Agreements
  876.  
  877.  
  878.  
  879.           8.6    Scroll profile
  880.  
  881.           OIW VTE-Profile Scroll-1989 (r1,r2,...r9)
  882.  
  883.  
  884.           8.6.1   Introduction
  885.  
  886.           This  Scrolling  A-mode   VTE-profile  is  designed  to   support
  887.           line-at-a-time interactions between a terminal and a host system,
  888.           the type of operation typified by operating system command entry.
  889.  
  890.           Scrolling is bi-directional, forward and backward.
  891.  
  892.           The  profile also  provides a  facility for switching  local echo
  893.           "on" or "off".
  894.  
  895.           This   VTE-Profile  supports  what   is  often  referred   to  as
  896.           "type-ahead", so input from the terminal user is available to the
  897.           host application as  soon as the application is  ready for input,
  898.           thus providing efficiency by minimizing communication delays.
  899.  
  900.           This VTE-profile supports  the definition of "input"  termination
  901.           events  by the  "Application  VT-user"  so  the  application  can
  902.           specify what  events will cause  "input" data to be  forwarded to
  903.           the "Application VT-user".
  904.  
  905.  
  906.           8.6.2   Association requirements
  907.  
  908.  
  909.           8.6.2.1   Functional units
  910.  
  911.           The Urgent Data Functional  Unit is optional, and will be used if
  912.           available.
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.                                           7
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  933.  
  934.           8.6.2.2   Mode
  935.  
  936.           This profile operates in A-mode.
  937.  
  938.  
  939.           8.6.3   Profile body
  940.  
  941.           Display-objects =
  942.           {
  943.                {
  944.                display-object-name = DOA,  
  945.                DO-access = profile-argument-rl,
  946.                dimension = "two",
  947.                     x-dimension =
  948.                     {
  949.                          x-bound = profile-argument-r2, 
  950.                          x-addressing = "no-constraint", 
  951.                          x-absolute = "no", 
  952.                          x-window = x-bound 
  953.                     }, 
  954.                     y-dimension = 
  955.                     {
  956.                          y-bound = "unbounded", 
  957.                          y-addressing = "no-constraint",
  958.                          y-absolute = "no", 
  959.                          y-window = profile-argument-r10 
  960.                     },
  961.  
  962.                erasure-capability = "yes",
  963.  
  964.                *(  repertoire-capability  is  implied   by  the  number  of
  965.                occurrences of profile-argument-r4 )*
  966.  
  967.                repertoire-assignment = profile-argument-r4, 
  968.  
  969.                DO-emphasis = profile-argument-r5, 
  970.  
  971.                foreground-colour-capability = profile-argument-r6, 
  972.                foreground-colour-assignment = profile-argument-r7, 
  973.                background-colour-capability = profile-argument-r6, 
  974.                background-colour-assignment = profile-argument-r8 
  975.                }, 
  976.                {
  977.                display-object-name = DOB, 
  978.                DO-access = opposite of profile-argument-rl, 
  979.                dimension = "two", 
  980.                     x-dimension = 
  981.                     {
  982.                          x-bound = profile-argument-r2, 
  983.                          x-addressing = "no-constraint", 
  984.  
  985.                                           8
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  999.  
  1000.                          x-absolute = "no",
  1001.                          x-window = x-bound 
  1002.                     }, 
  1003.                     y-dimension = 
  1004.                     {
  1005.                          y-bound = "unbounded", 
  1006.                          y-addressing = "higher only", 
  1007.                          y-absolute = "no",
  1008.                          y-window = 1 
  1009.                     }, 
  1010.                erasure capability = "yes",
  1011.                *(  repertoire-capability  is  implied  by   the  number  of
  1012.                occurrences of profile-argument-r4 )*
  1013.  
  1014.                repertoire-assignment = profile-argument-r4,
  1015.  
  1016.                DO-emphasis = profile-argument-r5, 
  1017.  
  1018.                foreground-colour-capability = profile-argument-r6, 
  1019.                foreground-colour-assignment = profile-argument-r7, 
  1020.                background-colour-capability = profile-argument-r6,  
  1021.                background-colour-assignment = profile-argument-r8 
  1022.                } 
  1023.           }, 
  1024.             
  1025.           Control-objects =
  1026.           {
  1027.                {
  1028.                CO-name        = E, *(standard Echo CO)*
  1029.                CO-type-identifier  = vt-b-sco-echo, 
  1030.                CO-access      = profile-argument-r1, 
  1031.                CO-priority         = "normal", 
  1032.                CO-trigger          = "selected", 
  1033.                CO-category         = "boolean", 
  1034.                CO-size             = 1 
  1035.                }, 
  1036.                IF r9 = "TE" THEN
  1037.                {
  1038.                CO-name        = TE, *(Termination Event CO)*
  1039.                CO-type-identifier  = vt-b-sco-tco, 
  1040.                CO-access      = opposite of profile-argument-r1, 
  1041.                CO-priority         = "normal", 
  1042.                CO-trigger          = "selected", 
  1043.                CO-category         = "integer" 
  1044.                },
  1045.                     {
  1046.                CO-name        = SA, *(NIST Registered CO)*
  1047.                CO-type-identifier  = nist-vt-co-misc-sa, 
  1048.                CO-access      = profile-argument-r1, 
  1049.                CO-priority         = "normal", 
  1050.  
  1051.                                           9
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1065.  
  1066.                CO-trigger          = "not selected",  
  1067.                CO-category         = "integer", 
  1068.                CO-size        = 65535 
  1069.                }, 
  1070.                          {
  1071.                CO-name        = UA, *(NIST Registered CO)*
  1072.                CO-type-identifier  = nist-vt-co-misc-ua,  
  1073.                CO-access      = profile-argument-r1, 
  1074.                CO-priority         = "urgent",          
  1075.                CO-category         = "integer",    
  1076.                CO-size        = 65535    
  1077.                }, 
  1078.                          {
  1079.                CO-name        = ST, *(NIST Registered CO)*
  1080.                CO-type-identifier  = nist-vt-co-misc-st,  
  1081.                CO-access      = opposite of profile-argument-r1, 
  1082.                CO-priority         = "normal", 
  1083.                CO-category         = "integer", 
  1084.                CO-size        = 65535 
  1085.                }, 
  1086.            
  1087.                {
  1088.                CO-name        = UT, *(NIST Registered CO)*
  1089.                CO-type-identifier  = nist-vt-co-misc-ut,
  1090.                CO-access      = opposite of profile-argument-r1, 
  1091.                CO-priority         = "urgent", 
  1092.                CO-category         = "integer", 
  1093.                CO-size        = 65535
  1094.                }, 
  1095.                {
  1096.                CO-name        = TC, *(Termination conditions CO)*
  1097.                CO-type-identifier  = nist-vt-co-tcco-tc,  
  1098.                CO-structure        = N, *( defined with TCCO)* 
  1099.                CO-access      = profile-argument-r1, 
  1100.                CO-priority         = "normal", 
  1101.                     { 
  1102.                     CO-element-id  = 1, *(termination length)*
  1103.                     CO-category    = "integer", 
  1104.                     CO-size   = 65535 }, 
  1105.                     { 
  1106.                     CO-element-id  = 2, *(time-out mantissa)* 
  1107.                     CO-category    = "integer", 
  1108.                     CO-size   = 65535 }, 
  1109.                     { 
  1110.                     CO-element-id  = 3, *(time-out exponent)* 
  1111.                     CO-category    = "integer", 
  1112.                     CO-size   = 65535 }, 
  1113.                     { 
  1114.                     CO-element-id  = 4-N, *(from registered TCCO)*
  1115.  
  1116.  
  1117.                                           10
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127.  
  1128.  
  1129.  
  1130.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1131.  
  1132.                     CO-category    = ???, 
  1133.                     CO-size   = ??? }
  1134.           The NIST Workshop VT SIG is defining this registered TCCO.  This 
  1135.           TCCO is a reference to that registered control object.
  1136.                }
  1137.           }
  1138.  
  1139.                Device-objects =
  1140.                { 
  1141.                     {
  1142.                     device-name = DVA,  *("output" device object)* 
  1143.                     device-default-CO-access = profile-argument-rl, 
  1144.                     device-default-CO-initial-value = 1."true",
  1145.                     device-display-object = DOA, 
  1146.                     device-minimum-X-array-length = profile-argument-r2, 
  1147.                     device-minimum-Y-array-length = profile-argument-r3, 
  1148.                     device-control-object = {SA,UA} 
  1149.                     },  
  1150.                     {
  1151.                     device-name = DVB,  *("input" device object)* 
  1152.                     device-default-CO-access       =       opposite      of
  1153.           profile-argument-r1, 
  1154.                     device-default-CO-initial-value = 1."true",
  1155.                     device-display-object = DOB, 
  1156.                     device-minimum-X-array-length = profile-argument-r2, 
  1157.                     device-control-object = profile-argument-r9,
  1158.                     device-control-object = {ST,UT},
  1159.                     device-control-object = TE 
  1160.                     } 
  1161.                },
  1162.  
  1163.                type-of-delivery-control = "simple-delivery-control".
  1164.  
  1165.  
  1166.           8.6.4   Profile argument definitions
  1167.  
  1168.           r1   - is mandatory and enables negotiation of which  VT-user has
  1169.                update  access  to display  object  DOA.    It takes  values
  1170.                "WACI",  "WACA".   It implies  the asymmetric  roles  of the
  1171.                VT-users as "Application  VT-user" and  "Terminal  VT-user".
  1172.                If  the  value  for  DOA  is  "WACI", then  the  association
  1173.                initiator is the "Application VT-user"; if the value of  DOA
  1174.                is "WACA", then  the association initiator is  the "Terminal
  1175.                VT-user".  This  profile argument is also  used to determine
  1176.                which VT-user has  access to other  VT objects as  described
  1177.                above.  Reference in the profile definition to  "opposite of
  1178.                profile-  argument-r1" means that the alternative of the two
  1179.                possible  values for  profile- argument-r1  is  to be  used.
  1180.                This  argument is identified by the identifier for DO-access
  1181.                for display object DOA.
  1182.  
  1183.                                           11
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.  
  1193.  
  1194.  
  1195.  
  1196.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1197.  
  1198.           r2   - is  optional and  enables negotiation of  a value  for the
  1199.                VTE-parameter x-bound for  the display objects DOA  and DOB.
  1200.                It takes an integer value  greater than zero.  This argument
  1201.                is  identified by  the identifier  for  x-bound for  display
  1202.                object DOA.  Default is 80.
  1203.  
  1204.           r3   - is optional and enables the negotiation of a value for the
  1205.                VTE-parameter   device-minimum-Y-array-length   for   device
  1206.                object DVA.  It takes an integer value greater than zero; if
  1207.                absent, a device of any length will  be satisfactory.
  1208.  
  1209.                NOTE - Indicates screen length.
  1210.  
  1211.           r4   - is optional and provides  for the negotiation of  value(s)
  1212.                for the  VTE-parameter repertoire-assignment.  The  value of
  1213.                repertoire-capability  is   implied   by   the   number   of
  1214.                occurrences of this argument.  Default is specified by 9040.
  1215.  
  1216.           r5   - is  optional and provides  for the negotiation of  a value
  1217.                for the  VTE-parameter DO-emphasis.   The  default value  is
  1218.                that given  in ISO 9040, B.17.3.   Refer to  ISO 9040 B.17.4
  1219.                for rules governing the selection of non-default values.
  1220.  
  1221.           r6   - is  optional and provides for the  negotiation of value(s)
  1222.                for    VTE-parameters    foreground-colour-capability    and
  1223.                background-colour-capability.  Default is 8.
  1224.  
  1225.           r7   - is  optional and provides  for the negotiation of  a value
  1226.                for VTE-parameter foreground-colour-assignment.   Default is
  1227.                {"white", "black", "red", "cyan", "blue", "yellow", "green",
  1228.                "magenta"}.
  1229.  
  1230.           r8   - is  optional and provides  for the negotiation of  a value
  1231.                for VTE-parameter background-colour-assignment.   Default is
  1232.                {"black",   "white",   "cyan",  "red",   "yellow",   "blue",
  1233.                "magenta","green"}.
  1234.  
  1235.           r9   -  is  optional  and enables  negotiation  of  a termination
  1236.                control object.  The value for this argument is the value of
  1237.                CO-name  for the termination  control object, i.e.  "TE"; if
  1238.                absent, no termination control is defined.
  1239.  
  1240.           r10  - is  optional and provides  for the negotiation of  a value
  1241.                for the VTE-parameter  y-window of the DOA   Display Object.
  1242.                Default is 24.
  1243.  
  1244.  
  1245.  
  1246.  
  1247.  
  1248.  
  1249.                                           12
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1263.  
  1264.           8.6.5   Profile dependent CO information
  1265.  
  1266.           This profile makes  use of five  OIW  registered Control Objects,
  1267.           SA,  UA, ST, UT and  TCCO.  The  CO-access in each  CO is defined
  1268.           within this profile.
  1269.  
  1270.  
  1271.           8.6.6   Profile notes
  1272.  
  1273.  
  1274.           8.6.6.1   Definitive notes
  1275.  
  1276.           Only the first boolean of the default control object contained in
  1277.           each device object  is defined.   This boolean is defined  as the
  1278.           "on/off" switch for  the device where the value  "true" ="on" and
  1279.           "false" = "off".  These values  were chosen so the initial  value
  1280.           of the  boolean, "true", means  the device is initially  "on" and
  1281.           data to/from the display objects is being mapped to the device.
  1282.  
  1283.           Only one boolean is defined  in the standard echo control object,
  1284.           E.   The semantics of this  boolean is defined  such that "false"
  1285.           means  "local echo off" and "true" means  "local echo on";  these
  1286.           values  were chosen so  echoing is  initially "off"  (which would
  1287.           provide  security when a  password is entered  at the  start of a
  1288.           terminal session).
  1289.  
  1290.  
  1291.           8.6.6.2   Informative notes
  1292.  
  1293.           This profile  models  a  scrolling device  which  is  capable  of
  1294.           scrolling both forwards and backwards. The display pointer may be
  1295.           moved backwards  to modify earlier lines.  A typical use for this
  1296.           profile  is for applications where type-ahead may be advantageous
  1297.           and control over local echo "on"/"off" is required, e.g. the type
  1298.           of application  where  a conventional  teletypewriter  device  or
  1299.           `teletype-compatible'   video   device   having   `full   duplex'
  1300.           capability is often  used.  Display object DOA  referred to above
  1301.           is typically mapped to the display or printing device and display
  1302.           object DOB is typically mapped to the keyboard.
  1303.  
  1304.           Use of A-mode  enables "typed-ahead"into display object  DOB, and
  1305.           such updates can  be delivered immediately  to the peer  VT-user,
  1306.           potentially  reducing transmission delays.  Such delivery will be
  1307.           forced, and marked,  by a termination condition  or a VT-DELIVER.
  1308.           Type-ahead is at the discretion of the terminal user.
  1309.  
  1310.           Display object DOB has an  unbounded y-dimension so as to provide
  1311.           a blank line for each new line entered.
  1312.  
  1313.           Line-at-a-time forward scrolling is  mapped onto an update-window
  1314.  
  1315.                                           13
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1329.  
  1330.           (value zero) which allows NO backward updates to  preceding lines
  1331.           (x-arrays).    The  device-minimum-Y-array-length  negotiated  by
  1332.           profile-argument-r3  can be used to  indicate the number of lines
  1333.           (x-arrays) which should remain visible to the human terminal user
  1334.           although specifically NOT available for update.
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346.  
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.                                           14
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1395.  
  1396.  
  1397.           The ability to switch local echo "on" or "off" is always present;
  1398.           the ECHO control object is used for this purpose.
  1399.  
  1400.  
  1401.           8.6.7   Specific conformance requirements
  1402.  
  1403.           None.
  1404.  
  1405.  
  1406.           8.7    S-mode Paged Application profile
  1407.  
  1408.           See Stable Agreements.
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422.  
  1423.  
  1424.  
  1425.  
  1426.  
  1427.  
  1428.  
  1429.  
  1430.  
  1431.  
  1432.  
  1433.  
  1434.  
  1435.  
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.                                           15
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458.  
  1459.  
  1460.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1461.  
  1462.           Annex A (normative)
  1463.  
  1464.           Specific ASE requirements
  1465.  
  1466.           See Stable Agreements.
  1467.  
  1468.  
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480.  
  1481.  
  1482.  
  1483.  
  1484.  
  1485.  
  1486.  
  1487.  
  1488.  
  1489.  
  1490.  
  1491.  
  1492.  
  1493.  
  1494.  
  1495.  
  1496.  
  1497.  
  1498.  
  1499.  
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.                                           16
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.  
  1523.  
  1524.  
  1525.  
  1526.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1527.  
  1528.           Annex B (normative)
  1529.  
  1530.           Clarifications
  1531.  
  1532.           See Stable Agreements.
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539.  
  1540.  
  1541.  
  1542.  
  1543.  
  1544.  
  1545.  
  1546.  
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570.  
  1571.  
  1572.  
  1573.  
  1574.  
  1575.  
  1576.  
  1577.  
  1578.  
  1579.                                           17
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.  
  1589.  
  1590.  
  1591.  
  1592.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1593.  
  1594.           Annex C (normative)
  1595.  
  1596.           Object identifiers
  1597.  
  1598.           See  Stable Agreements for Object Identifiers assigned to objects
  1599.           in the Stable  Agreements.   Object Identifiers  below have  been
  1600.           assigned to objects for which work is still in progress.
  1601.  
  1602.           General Identifiers:
  1603.  
  1604.              oiw-vt-rep OBJECT IDENTIFIER ::= { oiw-vt repertoire(2) }
  1605.  
  1606.              oiw-vt-font OBJECT IDENTIFIER ::= { oiw-vt font(3) }
  1607.  
  1608.              oiw-vt-colour OBJECT IDENTIFIER ::= { oiw-vt colour(4) }
  1609.  
  1610.              oiw-vt-directory    OBJECT    IDENTIFIER    ::=    {    oiw-vt
  1611.           useOfDirectory(5) }
  1612.  
  1613.           Profiles defined by OIW VT SIG:
  1614.  
  1615.              oiw-vt-pr-scroll-1989    OBJECT  IDENTIFIER  ::=  {  oiw-vt-pr
  1616.           scroll-1989(3) }
  1617.  
  1618.           Control Objects defined by OIW VT SIG:
  1619.  
  1620.              oiw-vt-co-tcco-tc    OBJECT  IDENTIFIER  ::= {  oiw-vt-co-tcco
  1621.           tc(0) }
  1622.  
  1623.  
  1624.  
  1625.  
  1626.  
  1627.  
  1628.  
  1629.  
  1630.  
  1631.  
  1632.  
  1633.  
  1634.  
  1635.  
  1636.  
  1637.  
  1638.  
  1639.  
  1640.  
  1641.  
  1642.  
  1643.  
  1644.  
  1645.                                           18
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.  
  1655.  
  1656.  
  1657.  
  1658.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1659.           
  1660.           Annex D (informative)
  1661.  
  1662.           Recommended  practice_Operating X  Window  System over  OSI upper
  1663.           layers
  1664.  
  1665.           This annex provides a "recommended practice" for the operation of
  1666.           the  X Window  System  (X) over  an  OSI upper  layer stack.  The
  1667.           "recommended  practice" provides an interim1 solution for an area
  1668.           not  addressed by  base  standards  or  existing  profiles.  This
  1669.           recommended practice reflects OIW agreement.
  1670.            
  1671.           It is recommended that this interim solution be used when mapping
  1672.           X  over an  OSI upper  layer stack. However,  implementors should
  1673.           note   the  following_future   specifications  of   the  regional
  1674.           workshops may possibly  result in different solutions  than those
  1675.           proposed in this recommended practice.
  1676.  
  1677.  
  1678.           D.1    Background
  1679.  
  1680.           X is a graphical  user interface standard which enables a user to
  1681.           view  and gain  access to  multiple computer applications  from a
  1682.           single window or multiple windows on a display screen. X is based
  1683.           on  a client/server  architecture  which allows  applications and
  1684.           resources to be distributed across a network.
  1685.  
  1686.           The X server is  a software program that is resident  on a user's
  1687.           display unit  that acts as  an intermediary between  the user and
  1688.           applications running  on a local  or remote system.  The X server
  1689.           also  maintains complex data structures such as specific windows,
  1690.           cursors  and fonts  which  can  be  referenced  and  utilized  by
  1691.           applications. Input from  the keyboard and/or mouse  is collected
  1692.           by the X-server  and passed to  local and/or remote  applications
  1693.           for processing.
  1694.  
  1695.           Applications are  referred to  as X  clients. These  applications
  1696.           access the display unit by sending messages to the X server which
  1697.           is then able to perform two dimensional drawing  of lines, shapes
  1698.           and text. 
  1699.  
  1700.           X products are based on a de facto standard (MIT-X) maintained by
  1701.           the  MIT X  Consortium.  However,  this  specification  does  not
  1702.           provide for the operation of X over OSI-based networks.
  1703.            
  1704.           Two  OSI  mapping  specifications  were  created  to  define  the
  1705.  
  1706.                               
  1707.  
  1708.           1    It  is intended  that  this  Recommended  Practice  will  be
  1709.           progressed as an RWS technical report.
  1710.  
  1711.                                           19
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.  
  1721.  
  1722.  
  1723.  
  1724.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1725.  
  1726.           operation  of X  over an  OSI upper  layer stack:  EWOS Technical
  1727.           Guide 13 (ETG13) and part  4 of ANSI dpANS X.196 (X3.196).  Parts
  1728.           1-3 were intended to  define the X protocol. Part 4  was based on
  1729.           ETG13.  .X3.196 never progressed beyond the draft proposal stage.
  1730.           ETG13 was approved by EWOS in 05/91.
  1731.  
  1732.           ETG13 explicitly defines:
  1733.  
  1734.                a)  the required OSI upper layer facilities;
  1735.  
  1736.                b)  the mapping  of the OSI upper layer services for sending
  1737.                and receiving X protocol.
  1738.  
  1739.           Since the creation of these documents, the ISO ISP 11188-3 Common
  1740.           Upper  Layer   Requirements_Part  3:  Minimal  OSI   upper  layer
  1741.           requirements  (CULR-3) came  into  existence. CULR-3  defines the
  1742.           minimal  set   of  OSI   upper  layer     facilities   for  basic
  1743.           communications applications such as X.
  1744.  
  1745.           Unlike  ETG13, this  specification does  not  itself specify  the
  1746.           required  upper layer facilities. Rather, it references CULR-3 to
  1747.           indicate the  required OSI upper  layer facilities. On  the other
  1748.           hand, like ETG13, it specifies the mapping of X to the  OSI upper
  1749.           layers  services (ACSE,  Presentation and  Session). The  mapping
  1750.           specified is compatible with that in ETG13.
  1751.  
  1752.           This specification is intended to  be as brief as possible. ETG13
  1753.           includes  additional   guidance  and  explanatory   material  for
  1754.           implementors.
  1755.  
  1756.  
  1757.           D.2    Mapping specification
  1758.  
  1759.           This clause  defines the mapping of  the OSI ACSE (ISO  8649) and
  1760.           Presentation  Layer (ISO 8822) services for sending and receiving
  1761.           X messages. This mapping uses the following ACSE and presentation
  1762.           services:
  1763.  
  1764.                a)  ASSOCIATE;
  1765.  
  1766.                b)  RELEASE;
  1767.  
  1768.                c)  ABORT;
  1769.  
  1770.                d)  A-P-ABORT;
  1771.  
  1772.                e)  P-DATA.
  1773.  
  1774.           The required ACSE, presentation and supporting session facilities
  1775.           are discussed in clause D.3
  1776.  
  1777.                                           20
  1778.  
  1779.  
  1780.  
  1781.  
  1782.  
  1783.  
  1784.  
  1785.  
  1786.  
  1787.  
  1788.  
  1789.  
  1790.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1791.  
  1792.           For the purposes  of this specification, the operation  of X over
  1793.           the OSI upper layers is referred to as X-osi.
  1794.  
  1795.  
  1796.           D.2.1   Summary of mapping
  1797.  
  1798.           All  the X  protocol  Request, Reply,  Error  and Event  messages
  1799.           (i.e., the  "X messages") use  the encodings specified  in MIT-X.
  1800.           The X messages are treated by this mapping as unstructured stream
  1801.           of octets.  Any arbitrary sequence  of consecutive octets  can be
  1802.           treated as a single octet-aligned presentation data value this is
  1803.           transmitted as the  user data on a Presentation P-DATA primitive.
  1804.           The OPEN  DISPLAY Request and  Reply messages are treated  in the
  1805.           same way, and  are carried on  P-DATA. This mapping does  not use
  1806.           the user data of the ACSE services.
  1807.  
  1808.           The  OSI  upper  layer  stack  supporting  X-osi  shall  be  mOSI
  1809.           compliant as defined in clause D.3.
  1810.  
  1811.  
  1812.           D.2.2   Association establishment
  1813.  
  1814.           The initiative  for connection and  association establishment  is
  1815.           always  with  the  X  client.  The X  client  establishes  a  new
  1816.           association with the desired  X server by issuing an  A-ASSOCIATE
  1817.           request. As part of the  A-ASSOCIATE procedure, an OSI transport-
  1818.           connection is  established to the  X server system. The  class of
  1819.           Transport  protocol is out of scope  of this specification. There
  1820.           is  no  requirement for  X  clients or  X servers  to  re-use OSI
  1821.           Transport connections.
  1822.  
  1823.           Once the transport-connection is established, an AARQ PDU carried
  1824.           in  a Presentation  Connect request  (CP  PPDU) that  is in  turn
  1825.           carried   in  a  Session  Connect  request  (CONNECT  SPDU).  The
  1826.           parameters shall include:
  1827.            
  1828.                a)  Application Context  Name : This shall be  the value "x-
  1829.                application context", defined in ETG13 and shown below:
  1830.  
  1831.                b)  Presentation Context Definition List : Shall include the
  1832.                ACSE  presentation   context  and  the   X-osi  presentation
  1833.                context,  using  the  abstract  and  transfer  syntax  names
  1834.                defined in  ETG13 and  shown below.  Other  contexts may  be
  1835.                offered (these may include synonyms or alternative names for
  1836.                X abstract or transfer syntax);
  1837.  
  1838.                c)  Presentation  context identifiers shall be  integers not
  1839.                greater than  255.  This  is a more severe  restriction than
  1840.                ISO ISP  11188-1,  Common Upper  Layer Requirements_Part  1:
  1841.                Basic   connection-oriented   requirements   (CULR-1),  that
  1842.  
  1843.                                           21
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850.  
  1851.  
  1852.  
  1853.  
  1854.  
  1855.  
  1856.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1857.  
  1858.                permits 2-octet integers.
  1859.  
  1860.                d)  The  user information field  of the A-ASSOCIATE  request
  1861.                shall be absent.
  1862.  
  1863.           All other parameters are subject only to the requirements of mOSI
  1864.           compliance (see clause D.3).
  1865.  
  1866.           If the X server accepts the  association, the Application Context
  1867.           Name parameter  on the A-ASSOCIATE  response shall have  the same
  1868.           value  as that  received on  the indication.  The ACSE  and X-osi
  1869.           presentation  contexts  shall be  accepted.  If  synonym abstract
  1870.           syntax  or  transfer syntax  names  for  X-osi were  offered  and
  1871.           recognized,  only one  shall be  accepted  (i.e., following  this
  1872.           exchange,   there  shall   be  a   unique  presentation   context
  1873.           established for  X-osi). The  user information  field  of the  A-
  1874.           ASSOCIATE response shall be absent.
  1875.  
  1876.  
  1877.           D.2.3   Data exchange
  1878.  
  1879.           As  stated  in  the  summary   above,  once  the  association  is
  1880.           established,  all X-messages are  carried as user  data on P-DATA
  1881.           primitives,  each carrying a single PDV-list element containing a
  1882.           single "octet-aligned"  presentation data  value,  which is  some
  1883.           sequence of  consecutive octets from  one or more  X-messages. No
  1884.           correlation  is   required  between   the  pdv's  (i.e.   between
  1885.           successive P-DATAs) and the division between the X-messages : the
  1886.           division  into  pdv's   is  entirely  at  the   sender's  option.
  1887.           (Obviously, in practice there will be some correlation, but there
  1888.           is no requirement  to achieve this, nor should  receivers rely on
  1889.           it.)
  1890.  
  1891.  
  1892.           D.2.4   Connection termination
  1893.  
  1894.           A CLOSE  DISPLAY request  from an  X client  is mapped  to an  A-
  1895.           RELEASE request. After  receiving an A-RELEASE indication,  the X
  1896.           server responds with  an A-RELEASE response. Neither  the request
  1897.           or response primitive shall contain any User Information.
  1898.  
  1899.           A KILL CLIENT request from another client results in the issue of
  1900.           an  A-ABORT request  by  the  X server.  A  protocol or  internal
  1901.           procedural error  in either  the X  client or  the X server  also
  1902.           results  in  the  issue  of  an   A-ABORT  request.  The  A-ABORT
  1903.           indication will conatin the Abort Source parameter with the value
  1904.           "ACSE service-user".
  1905.  
  1906.           The  receipt  of an  A-ABORT  indication  with the  Abort  Source
  1907.           parameter having  the value  "ACSE service-provider"  indicates a
  1908.  
  1909.                                           22
  1910.  
  1911.  
  1912.  
  1913.  
  1914.  
  1915.  
  1916.  
  1917.  
  1918.  
  1919.  
  1920.  
  1921.  
  1922.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1923.  
  1924.           failure in either  the local or peer ACSE. The receipt of an A-P-
  1925.           ABORT   indication  indicates   a   failure  in   the  supporting
  1926.           Presentation Layer or below.
  1927.  
  1928.  
  1929.           D.3    Required OSI upper layer facilities.
  1930.  
  1931.           X is a basic communications application as defined in the CULR-3.
  1932.           That  is,  it simply  requires  the  ability  to open  and  close
  1933.           communications with a peer and  to send and receive messages with
  1934.           the peer.  The  required  facilities  of  the  OSI  upper  layers
  1935.           (Session,  Presentation, and ACSE)   are specified by stating the
  1936.           minimal mOSI compliance requirements as defined in the CULR-3.
  1937.  
  1938.           mOSI  compliance requirements depend on whether a system supports
  1939.           one  or more  X clients  (requests an  association) or  X servers
  1940.           (accepts an association request).
  1941.  
  1942.  
  1943.           D.3.1   X client mOSI compliance
  1944.  
  1945.           An upper  layer  stack  that supports an  X client shall  be mOSI
  1946.           compliant category I or category II.
  1947.            
  1948.           An   X  client  stack   has  the  following   minimal  compliance
  1949.           requirement based on Table 2 in the CULR-3.
  1950.  
  1951.                a)  "Establishment role" shall have the value "Initiator" or
  1952.                "Both".  An X client is always the association initiator; it
  1953.                is never an association-responder.
  1954.  
  1955.                b)  "Normal  data role" shall have  the value "Both".   An X
  1956.                client shall be able to send or receive data.
  1957.  
  1958.                c)   "Release role"  shall have the  value "Requestor",   or
  1959.                "Both".  A CLOSE DISPLAY request is mapped to A-RELEASE.
  1960.  
  1961.                d)   "Authentication" shall  have the  value "Supported"  or
  1962.                "Not supported".   The X client - X  server association does
  1963.                not use the ACSE Authentication functional unit.
  1964.  
  1965.                e)   "AC  negotiation" shall have  the value  "Supported" or
  1966.                "Not supported".   The X client - X  server association does
  1967.                not use the ACSE Application context negotiation  functional
  1968.                unit.
  1969.  
  1970.                f)  "All "m" parms sent and received and CULR-1 compliance?"
  1971.                shall  have the  value "Yes".   If the  value is  "Yes", the
  1972.                stack is mOSI compliant, category I or category II.
  1973.  
  1974.  
  1975.                                           23
  1976.  
  1977.  
  1978.  
  1979.  
  1980.  
  1981.  
  1982.  
  1983.  
  1984.  
  1985.  
  1986.  
  1987.  
  1988.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  1989.  
  1990.                g)  "All "o" parms sent  and received?" shall have the value
  1991.                "Yes" or "No."  If the value is "Yes", the stack is category
  1992.                I. If the  value is "No",  the stack is  of category II.  In
  1993.                this case,  the X client  stack is only required  to support
  1994.                the following features for sending(see Table 3).
  1995.  
  1996.                _Called AE title
  1997.  
  1998.                _ Form1 (Directory name)
  1999.  
  2000.  
  2001.           D.3.2   X server mOSI compliance
  2002.  
  2003.           An  upper layer   stack that supports  an X server  shall be mOSI
  2004.           compliant category I or  category II. The X server  stack has the
  2005.           following compliance requirement based on Table 2 in the CULR-3.
  2006.  
  2007.                a)  "Establishment role" shall have the value "Responder" or
  2008.                "Both".  An X server is always the association responder; it
  2009.                is never an association-initiator.
  2010.  
  2011.                b)  "Normal  data role" shall have  the value "Both".   An X
  2012.                server shall be able to send or receive data.
  2013.  
  2014.                c)   "Release  role" shall  have the  value "Acceptor",   or
  2015.                "Both".  The receipt of  an A-RELEASE indication indicates a
  2016.                CLOSE DISPLAY request from the X client.
  2017.  
  2018.                d)   "Authentication" shall  have the  value "Supported"  or
  2019.                "Not supported".   The X client - X  server association does
  2020.                not use the ACSE Authentication functional unit.
  2021.  
  2022.                e)   "AC  negotiation" shall have  the value  "Supported" or
  2023.                "Not supported".   The X client - X  server association does
  2024.                not use the ACSE Application context  negotiation functional
  2025.                unit.
  2026.  
  2027.                f)  "All  "m" parms sent and received?" shall have the value
  2028.                "Yes".  If the value is  "Yes", the stack is mOSI compliant,
  2029.                category I or category II.
  2030.  
  2031.                g)  "All "o" parms sent and received?" shall have the  value
  2032.                "Yes" or "No".  If the value is "Yes", the stack is category
  2033.                I.  If the value  is "No", the  stack is of  category II. No
  2034.                category II features are required for sending.
  2035.  
  2036.  
  2037.  
  2038.  
  2039.  
  2040.  
  2041.                                           24
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.  
  2051.  
  2052.  
  2053.  
  2054.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  2055.  
  2056.           D.4    Object identifiers
  2057.  
  2058.           Object  identifiers used for  this specification are  assigned in
  2059.           ETG13.2 
  2060.  
  2061.                Application context for X-osi : 
  2062.                  {iso(1) identified-organization(3) ewos(16) eg(2) vt(7)
  2063.                      x-osi(10) application-context(1) }
  2064.  
  2065.                Abstract syntax name:
  2066.                  {iso(1) identified-organization(3) ewos(16) eg(2) vt(7)
  2067.                      x-osi(10) abstract-syntax-version-1(2) }
  2068.  
  2069.                Transfer syntax name:
  2070.                  {iso(1) identified-organization(3) ewos(16) eg(2) vt(7)
  2071.                      x-osi(10)
  2072.                   binary-transfer-syntax-version-1(3) }
  2073.  
  2074.  
  2075.           D.5    Recommended encoding
  2076.  
  2077.           It is recommended  that the encoding of the  Presentation PCI for
  2078.           the P-DATA follow a particular set of choices, among the optional
  2079.           features allowed by  BER. This makes the P-DATA  a (nearly) fixed
  2080.           header and allows implementations to be optimized to process this
  2081.           encoding.  An implementation must  be able to  handle alternative
  2082.           encodings (i.e. any allowed by  BER, subject to the restraints of
  2083.           CULR-1),  within  the  mapping  specification  that  each  P-DATA
  2084.           carries  a  single  octet-aligned presentation  data  value.  The
  2085.           recommended encoding is :
  2086.  
  2087.                a)   the fully-encoded-data  (SEQUENCE  OF  PDV-list)  shall
  2088.                contain exactly one PDV-list;
  2089.  
  2090.                b)   both the SEQUENCE OF PDV-list and  the  PDV-list  shall
  2091.                have  indefinite  length,  but shall  contain  no  levels of
  2092.                construction  other than   those   required   by  the   data
  2093.                types;
  2094.  
  2095.                c)  the length of  the presentation-context-identifier value
  2096.                shall be expressed in short form;
  2097.  
  2098.                d)   the  presentation-context-identifier  value  shall   be
  2099.                encoded in one octet;
  2100.  
  2101.                e)    the  OCTET  STRING  of  presentation-data-values  will
  2102.                               
  2103.  
  2104.           2    These  EWOS based object identifiers were also referenced in
  2105.           the last draft of X3.196_part 4.
  2106.  
  2107.                                           25
  2108.  
  2109.  
  2110.  
  2111.  
  2112.  
  2113.  
  2114.  
  2115.  
  2116.  
  2117.  
  2118.  
  2119.  
  2120.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  2121.  
  2122.                contain a   single presentation  data value  and shall  have
  2123.                primitive encoding and
  2124.  
  2125.                f)  the  (definite) length of this  OCTET  STRING shall   be
  2126.                expressed  in exactly four  octets (i.e., the  length itself
  2127.                will occupy  three octets, prefixed  by   one  octet   which
  2128.                defines the length of this length).
  2129.  
  2130.           These encoding choices mean that  each TSDU user data consists of
  2131.           16  octets of  header,  the  X-message octets,  and  4 octets  of
  2132.           trailer (all zero). The length of the X-message segment is in the
  2133.           last three octets of the header.
  2134.  
  2135.           This recommendation is identical to  that in ETG13 except for the
  2136.           length field in  (6). In ETG13 this  is for a length  of 1+4, not
  2137.           1+3. This gives a 17-octet header. Since the X protocol, and many
  2138.           implementations  go  to  some  effort to  get  things  on  4-byte
  2139.           boundaries, it is better to make this  apply to X-osi as well. If
  2140.           a truly enormous P-DATA is  needed i) the implementation is being
  2141.           very clever with its buffering; ii) it will have to use  a longer
  2142.           length field; iii)  the receiver is required to  handle any legal
  2143.           encoding anyway.
  2144.  
  2145.  
  2146.           D.6    Differences from ETG13
  2147.  
  2148.  
  2149.           D.6.1   Abstract and transfer syntax names
  2150.  
  2151.           In ETG13  the abstract and  transfer syntax names are  defined as
  2152.           names for the syntaxes  defined in part  II of X3.196, and  ETG13
  2153.           includes a copy  of the April 1990  text for this. Since  this is
  2154.           just a definition of the X data formats, there will be no problem
  2155.           in  using  them  for  X  protocol  as  defined  in  MIT-X.  ETG13
  2156.           explicitly  allows the  extensibility features  of X  to be  used
  2157.           without altering the syntax names.
  2158.  
  2159.           Strictly speaking,  X uses  two transfer syntaxes,  and the  OPEN
  2160.           DISPLAY  request defines  which one  will be  used.  The transfer
  2161.           syntax  name defined  in  ETG13 covers  both  the "MSBfirst"  and
  2162.           "LSBfirst" forms.
  2163.  
  2164.  
  2165.           D.6.2   Application   process   title  and   application   entity
  2166.                   qualifier
  2167.  
  2168.           ETG13  requires  that   the  Called  Application  Process   Title
  2169.           parameter on the  A-ASSOCIATE request be  a Directory Name  (i.e.
  2170.           form1) in  which the  last RDN is  the attribute  value assertion
  2171.           CommonName=<displaynumber>,  where  <displaynumber> is  a  string
  2172.  
  2173.                                           26
  2174.  
  2175.  
  2176.  
  2177.  
  2178.  
  2179.  
  2180.  
  2181.  
  2182.  
  2183.  
  2184.  
  2185.  
  2186.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  2187.  
  2188.           representing the  X Window System  server number  (and thus  most
  2189.           commonly "0"), and  that the Called Application  Entity Qualifier
  2190.           be CommonName  = "X-Window-System". The requirement  was intended
  2191.           to facilitate  X-osi : X-other  relays, but this  really requires
  2192.           integration with RFC 1275 to be general.
  2193.  
  2194.           Although  ETG13 requires  these values  it  also recommends  that
  2195.           implementations  accept other  values  (or  no value).  Therefore
  2196.           there  should  be  no  interworking  problems  by  omitting  this
  2197.           requirement here.
  2198.  
  2199.  
  2200.  
  2201.  
  2202.  
  2203.  
  2204.  
  2205.  
  2206.  
  2207.  
  2208.  
  2209.  
  2210.  
  2211.  
  2212.  
  2213.  
  2214.  
  2215.  
  2216.  
  2217.  
  2218.  
  2219.  
  2220.  
  2221.  
  2222.  
  2223.  
  2224.  
  2225.  
  2226.  
  2227.  
  2228.  
  2229.  
  2230.  
  2231.  
  2232.  
  2233.  
  2234.  
  2235.  
  2236.  
  2237.  
  2238.  
  2239.                                           27
  2240.  
  2241.  
  2242.  
  2243.  
  2244.  
  2245.  
  2246.  
  2247.  
  2248.  
  2249.  
  2250.  
  2251.  
  2252.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  2253.           
  2254.           Annex E (normative)
  2255.  
  2256.           (ANNEX E  WAS FORMALLY ANNEX  D. THE  WORKSHOP STYLES CHANGE  THE
  2257.           NUMBERING AUTOMATICALLY.)  OIW XOSI contributions
  2258.  
  2259.           The following sections describe  contributions by the OIW  VT SIG
  2260.           to further XOSI.  Contributions in this section are  not meant to
  2261.           replace any existing standards, but are meant to  fill gaps where
  2262.           standards   may  not  exist,  or   where  they  are  still  under
  2263.           development.   Whenever possible, contributions  in this  section
  2264.           will be kept technically aligned with any developing standards.
  2265.  
  2266.  
  2267.           E.1    XDMCPOSI
  2268.  
  2269.  
  2270.           E.1.1   Introduction
  2271.  
  2272.           This section  describes a  means by  which the  protocol commonly
  2273.           known as XDMCP (X Display Manager Control Protocol) may be mapped
  2274.           over  the OSI  Upper Layers.     This specification  is  meant to
  2275.           provide  one  solution  to  the  problem  of  establishing  an  X
  2276.           connection in a pure-OSI environment.
  2277.  
  2278.           In general,  the mapping of  XDMCP to OSI  relies on much  of the
  2279.           information already present in the XOSI Part IV  document, and as
  2280.           such, that information will not be duplicated here.
  2281.  
  2282.  
  2283.           E.1.2   Functional overview
  2284.  
  2285.           XDMCP provides  for three  different types  of query  operations:
  2286.           Query,  IndirectQuery  and  BroadcastQuery.   The  nature  of the
  2287.           BroadcastQuery operation is  such that is requires  a connection-
  2288.           less environment, and so will not be considered here.
  2289.  
  2290.           In addition to the three query types, XDMCP provides for a number
  2291.           of other  operations: ForwardQuery, Willing,  Unwilling, Request,
  2292.           Accept,   Decline,  Manage,  Refuse,  and  Failed.    The  actual
  2293.           semantics of these operations  will not be discussed here  except
  2294.           with regard to how they map to various OSI services.   Additional
  2295.           information  on  XDMCP  operations  may  be found  in  the  XDMCP
  2296.           protocol specification provided by the MIT X Consortium.
  2297.  
  2298.  
  2299.           E.1.2.1   ACSE requirements
  2300.  
  2301.           The  ACSE requirements for XDMCPOSI are  the same as specified by
  2302.           XOSI Part  IV, with the  exception of  the abstract and  transfer
  2303.  
  2304.  
  2305.                                           28
  2306.  
  2307.  
  2308.  
  2309.  
  2310.  
  2311.  
  2312.  
  2313.  
  2314.  
  2315.  
  2316.  
  2317.  
  2318.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  2319.  
  2320.           syntaxes.
  2321.  
  2322.  
  2323.           E.1.2.2   Presentation requirements
  2324.  
  2325.           XDMCPOSI has the  same presentation requirements as  specified by
  2326.           XOSI Part IV.
  2327.  
  2328.  
  2329.           E.1.2.3   Session requirements
  2330.  
  2331.           XDMCPOSI  has the same session  requirements as specified by XOSI
  2332.           Part IV.
  2333.  
  2334.  
  2335.           E.1.2.4   Abstract and transfer syntaxes
  2336.  
  2337.           Note:  We  basically have two possible  options here:  one  is to
  2338.           utilize the existing XOSI object identifiers as currently defined
  2339.           by EWOS, and request that  EWOS register an abstract syntax which
  2340.           defines  XDMCP, which would resemble:  XDMCP-abstract-syntax :: =
  2341.           OBJECT IDENTIFIER { xosi, abstract-syntax(4) }.  The other option
  2342.           would  be to define  the application context  and abstract syntax
  2343.           under OIW, leaving the transfer syntax as specified by EWOS.
  2344.  
  2345.  
  2346.           E.1.2.5   XDMCP to OSI mapping
  2347.  
  2348.           The  following  sections  outline   how  various  XDMCP  protocol
  2349.           elements are  mapped to  specific OSI services.   The  mapping is
  2350.           divided into four  broad catagories, each describing  mapping for
  2351.           specific operations based on the type of query.
  2352.  
  2353.           Note: that  the following discussion  includes a possible  way to
  2354.           map  the IndirectQuery  function  to  OSI,  however,  with  X.500
  2355.           IndirectQuery may become an unneccessary feature.
  2356.  
  2357.  
  2358.           E.1.2.5.1  Query - display to manager
  2359.  
  2360.           An  implementation claiming to support XDMCPOSI must support this
  2361.           minumum  functionality.  The Query functionality allows a display
  2362.           to query a specific manager for willingness to provide management
  2363.           services.
  2364.  
  2365.           A display  may initiate an  association with either the  Query or
  2366.           IndirectQuery  operation.  Once the association is established, a
  2367.           display may  request additional Query or IndirectQuery operations
  2368.           via P-Data regardless of the operation in the initial association
  2369.           request.
  2370.  
  2371.                                           29
  2372.  
  2373.  
  2374.  
  2375.  
  2376.  
  2377.  
  2378.  
  2379.  
  2380.  
  2381.  
  2382.  
  2383.  
  2384.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  2385.  
  2386.           Table 1 - XDMCP mapping for query/display to manager
  2387.  
  2388.  
  2389.            A-Associate Request &           Query
  2390.            Indication
  2391.            A-Associate Response & Confirm  Willing, Unwilling
  2392.  
  2393.            A-Release Request & Indication  <null>, Unwilling, Decline,
  2394.            (manager initiates)             Failed
  2395.  
  2396.            A-Release Response & Confirm
  2397.            P-Data (Display)                Query, IndirectQuery, Request,
  2398.                                            Manage
  2399.  
  2400.            P-Data (Manager)                Willing, Unwilling, Accept,
  2401.                                            Decline, Refuse, Failed 
  2402.  
  2403.  
  2404.  
  2405.           E.1.2.5.2  IndirectQuery - display to manager
  2406.  
  2407.           A  display or  manager may  optionally  support IndirectQuery  in
  2408.           addition to Query.  Managers which receive IndirectQuery requests
  2409.           in the  A-Associate request  which do  not support  IndirectQuery
  2410.           should refuse the association.
  2411.  
  2412.           The  manager which  receives the  IndirectQuery is  known  as the
  2413.           primary   manager.    The   primary  manager  will   forward  the
  2414.           IndirectQuery to secondary managers via a ForwardQuery operation.
  2415.           Optionally, the primary  manager may also indicate  a willingness
  2416.           to perform  the display management.   As with  secondary managers
  2417.           which indicate a  willingness to manage, the display  is under no
  2418.           obligation to accept the  primary managers offer, and  may simply
  2419.           release the association.  The primary manager may also choose not
  2420.           to  send a  Willing,  in which  case it  may  simply release  the
  2421.           association.   However,  it  may be  desirable  for  the  primary
  2422.           manager  and/or the  display to  maintain the  association for  a
  2423.           period of time, so as to potentially be available for  additional
  2424.           requests from the display.
  2425.  
  2426.           Table 2 - XDMCP mapping for indirectquery/display to manager
  2427.  
  2428.  
  2429.  
  2430.  
  2431.  
  2432.  
  2433.  
  2434.  
  2435.  
  2436.  
  2437.                                           30
  2438.  
  2439.  
  2440.  
  2441.  
  2442.  
  2443.  
  2444.  
  2445.  
  2446.  
  2447.  
  2448.  
  2449.  
  2450.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  2451.  
  2452.  
  2453.            A-Associate Request &           IndirectQuery
  2454.            Indication
  2455.            A-Associate Response & Confirm  <null>, Willing
  2456.  
  2457.            A-Release Request & Indication  <null>, Unwilling, Decline,
  2458.            (manager initiates)             Failed
  2459.  
  2460.            A-Release Response & Confirm
  2461.            P-Data (Display)                Query, IndirectQuery, Request,
  2462.                                            Manager
  2463.  
  2464.            P-Data (Manager)                Willing, Unwilling, Accept,
  2465.                                            Decline, Refuse, Failed
  2466.  
  2467.  
  2468.  
  2469.           E.1.2.5.3  IndirectQuery - manager to manager
  2470.  
  2471.           This section  specifies the  mapping specifically  for a  primary
  2472.           manager  to communicate  a ForwardQuery  request  to a  secondary
  2473.           manager.
  2474.  
  2475.           The IndirectQuery is sent by the display to a well-known  manager
  2476.           (or primary  manager), which  in turn forwards  the request  to a
  2477.           larger  collection  of   secondary  managers  using  ForwardQuery
  2478.           packets.
  2479.  
  2480.           If associations haven't  been previously established  between the
  2481.           primary manager and the secondary manager, an A-Associate will be
  2482.           sent with  the ForwardQuery operation.  If an association already
  2483.           exists, the  primary manager  will simply  send the  ForwardQuery
  2484.           operation  via a  P-DATA.   It  is  up to  the  implementation to
  2485.           determine how long an association between a primary and secondary
  2486.           manager  should  be  maintained  as  various  tradeoff's  between
  2487.           association  establishment  overhead  and   maintaining  an  idle
  2488.           association exist and have not been examined in this guide.
  2489.  
  2490.           Either the primary manager or a number of secondary managers  may
  2491.           respond to  the query  by by  sending a  Willing response to  the
  2492.           display  which initiated the  request.  Secondary  managers which
  2493.           are willing will notify the requesting display by establishing an
  2494.           association with the display with the WIlling operation in the A-
  2495.           Associate.
  2496.  
  2497.           Table 3 - XDMCP mapping for indirectquery/manager to manager
  2498.  
  2499.  
  2500.  
  2501.  
  2502.  
  2503.                                           31
  2504.  
  2505.  
  2506.  
  2507.  
  2508.  
  2509.  
  2510.  
  2511.  
  2512.  
  2513.  
  2514.  
  2515.  
  2516.           PART 14 - VIRTUAL TERMINAL               September 1993 (Working)
  2517.  
  2518.  
  2519.            A-Associate Request &           ForwardQuery
  2520.            Indication
  2521.            A-Associate Response & Confirm
  2522.  
  2523.            P-Data                          ForwardQuery
  2524.  
  2525.  
  2526.  
  2527.           E.1.2.5.4  Indirect query - manager to display
  2528.  
  2529.           This section specifies the mapping for a secondary  manager which
  2530.           has received a ForwardQuery request, and wishes to respond with a
  2531.           WIlling to the requesting display.  To perform this function, the
  2532.           secondary  manager must first  establish an association  with the
  2533.           Willing operation in  the A-Associate request.   The display  may
  2534.           accept the A-associate yet not immediately respond to the Willing
  2535.           indication.   If the display  subsequently decides not  to accept
  2536.           the Willing  from the manager in question, it will simply release
  2537.           the association.
  2538.  
  2539.           Table 4 - XDMCP mapping for indirectquery/manager to display
  2540.  
  2541.  
  2542.            A-Associate Request &           Willing
  2543.            Indication
  2544.  
  2545.            A-Associate Response & Confirm  <null>, Request
  2546.            A-Release Request & Indication  <null>, Failed
  2547.            (manager initiates)
  2548.  
  2549.            A-Release Request & Indication
  2550.            (display initiates)
  2551.  
  2552.            P-Data (manager)                Accept, Decline, Refuse
  2553.            P-Data (display)                Request, Manage
  2554.  
  2555.  
  2556.  
  2557.  
  2558.  
  2559.  
  2560.  
  2561.  
  2562.  
  2563.  
  2564.  
  2565.  
  2566.  
  2567.  
  2568.  
  2569.                                           32
  2570.  
  2571.  
  2572.  
  2573.  
  2574.