🚀 go-pugleaf

A colleague has asked me to post the following.
(A small addition in square brackets ([]) has been added to the original,  
near the end.)
As an alternative to posting follow-up messages to this newsgroup,
email to the list 'iso-xwindows@uk.ac.rutherford' would be welcome.



++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


MAP/TOP  have  sent  a  liaison statement to ANSI X3H3 regarding the
      mapping of X Windows onto an ISO/OSI stack.  They  have  detailed  6
      reasons why they feel that a mapping to ACSE is preferable. They are
      listed below with my response.
 
      I  would  like to make it clear that the JNT view is NOT "It must be
      COTS", but "There are a sufficient number of problem areas which may
      make the adoption of ACSE solutions untenable.  Until  they  can  be
      shown to be adequately solved by the ACSE proposal, the JNT sees the
      COTS  proposal  as  the  only viable solution. The JNT urges that NO
      decision be made without reference to some performance data".
 
      To re-iterate the JNTs areas of concern :
 
      *   There  are  extreme worries about the efficiency aspect of using
          ACSE.  If  X/ACSE  performs  noticeably   worse   than   current
          implementations  such  as X/TCP etc, then users will not want to
          know.
 
      *   Interworking  between TCP and ISO versions is more viable if the
          COTS proposal is adopted.
 
      *   There  are  extreme  worries about when X/ACSE products would be
          available - I cannot  recall  seeing  too  many  efficient  full
          ISO/OSI  stacks  in  catalogues. These products will take a long
          while  to  produce.  There  are   however   Transport   products
          available. - Users want X/ISO now.
 
      *   There are worries about the financial costs. Full stacks are not
          cheap to develop. I suspect they will not be cheap to buy.
 
                                 -----------------
 
Here are the MAP/TOP reasons for choosing ACSE and my responses.
 
 >1.   OSI Naming and Addressing (See ISO 7498-2) comprises all seven layers.
 >     Addressing at the ACSE level will enable an X-Client to address an X-
 >     Server in a standard manner, but some ad hoc addressing mechanism
 >     would have to be invented to handle client addressing at a lower
 >     level.                                                                   
 
Response :
 
      It  is  true  that  above  the  network  layer  there  are selectors
      available  for  each  of  layer  eg  for  Transport,   Session   and
      Presentation.  The  use  of these selectors IS NOT MANDATORY. Indeed
      the intention is to use just NSAPs for addressing on  JANET.   Using
      the  Connection Oriented Transport Service DOES NOT IMPLY THE USE OF
      AD-HOC ADDRESSING MECHANISMS. The standard  OSI  mechanisms  can  be
      used.
 
 
 >2.   OSI Security is provide by functions in the Application Layer of OSI.
 >     Thus, OSI access control facility will not be available below the
 >     Application Layer.
 
Response :
 
      There seems to be some confusion about what we are trying to achieve
      in the X Window System forward through ISO. It is true that by using
      the  Application  Layer  any  ISO  security could be used, but I was
      under  the   impression   that   the   current   X   Window   System
      standardisation  was  only  to be regarded as an interim, to support
      users before the full ISO standard capable of  supporting  Windowing
      environments  (eg  Terminal  Management)  become  available. What is
      being suggested here is an enhancement of X , not how to accommodate
      X  in  the ISO/OSI environment. X was not written with the intention
      of putting it on a full ISO/OSI stack and cannot really fit.  If  we
      intend  X  to  be  a  truly ISO/OSI standard we must adopt the early
      Bellcore suggestion of re-writing  X with  ISO/OSI  in  mind.  If  a
      re-write or other new Windowing Standard is NOT what is intended, we
      should  seek  to  adopt  the  best  fit possible - ie use an ISO/OSI
      service that most closely resembles what X expects  as  a  transport
      service - ie COTS.
 
 
 >3.   OSI Directory services is an Application Layer function.  It is highly
 >     desirable that X-Applications be able to locate X-Servers through a
 >     standard use of X-500 Directories.
 
Response :
     
      It   is  true  that  the  ISO  Directory  Service  (ISO9594)  is  an
      Application layer Standard, however that does NOT prevent  it  being
      used  to  provide  information  on  or  for other services, such the
      Transport Service. It IS allowable to  register  Transport  Services
      without  using  the slots available for the Session and Presentation
      selectors. An alternative would be to define the X  processes  as  a
      different Object Class.
 
 >4.   In the event of loss of communication, re-establishment to a particu-
 >     lar instance of a process is available only in OSI if ACSE is
 >     employed.
  
Response :
 
      Transport  Protocol Class 4 (ISO 8073 section 12.1 - Error Detection
      and Recovery) gives  resilience  against  network  failure.  The  UK
      Academic  Community  experience  is  however that this is not needed
      over an X.25 network for example and a simple basic class  (TP0)  is
      adequate to provide a reliable connection.
 
 >5.   If a Client application or a Server using the X-Data Stream Definition
 >     is also going to use other OSI protocols (e.g., VT for process selec-
 >     tion or FTAM for down loading fonts), implementation consistency (sin-
 >     gle OSI interface) will be achieved only if these protocols operate at
 >     the same level of OSI (i.e., ACSE).
 
Response :
 
      This  is  confusing  what  is  in the  standard  with implementation
      details. I feel it unlikely that manufacturers will  implement  full
      ISO  stacks  as  monolithic  blocks,  without  any  hooks.  It would
      therefore be quite  reasonable to  expect  an  X  implementation  to
      co-exist in a machine with full ISO applications.
 
 >6.   Mapping to the ACSE/Presentation level of OSI is architecturally (for
 >     OSI) correct.  We believe that if X-Data Stream is not mapped to use
 >     OSI at this level, there may be some negative reaction from the OSI
 >     committees in ISO and ISO National Bodies.  This could hinder the
 >     fast-track process for the X-Data Stream Definition standard.  As our    
 >     goal is to get an international X-Data Stream Definition as quickly as
 >     possible, we strongly advise against doing anything which could jeop-
 >     ardize the rapid progression of your standard in ISO.
 
Response :
 
      ISO have indicated by their liaison statement from SC21/WG5 Terminal
      Management  Group  to SC24/WG1 (Graphics Group) they support ANSI in
      waiting  for  the  results  of  investigation  of  the   comparative
      performances before making any decision about the mapping. They have
      NOT said it must be ACSE.
 
                           ------------------------
 
      In  conclusion,  the  JNT are proposing X/COTS as a means to solving
      the problem in  hand  ie:  that  of  bringing  X  into  the  ISO/OSI
      environment [pending the general availability of 
      ISO OSI Terminal Management products]
      in  a standard way quickly so as to avoid multiple ways
      of implementing X/ISO. We must also ensure that the standards permit
      affordable efficient products come to the market place quickly.
 
      If prototyping shows that only COTS will provide suitable solutions,
      then  we must surely adopt the Connection Oriented Transport Service
      solution. If ACSE works well then the counter would be true. We will
      not know what the case is until the prototyping has been done and we
      have REAL comparative DATA on which to base the decision. As MAP/TOP
      point out all data will  be  implementation  dependent,  however  by
      doing  comparative  measurements  of X/ACSE and X/COTS with parts of
      the same stack we are likely to get some meaningful indications.
 
 
                                                                               
                               JOHN DYER
 
                        The  JOINT NETWORK TEAM
                  of the UNITED KINGDOM ACADEMIC COMMUNITY
 
 
Tel +44 235 445433            Postal Address : The Joint Network Team
Fax +44 235 445808                             The Atlas Centre
Telex 83159 RUTHLB G                           Rutherford Appleton Laboratory
telex 83414 RUTHLB G                           Chilton
                                               Didcot   OXFORDSHIRE  OX11 0QX
                                               UNITED KINGDOM