Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!gdt!gdr!exxpwj From: exxpwj@gdr.bath.ac.uk (Phil Jones) Newsgroups: comp.protocols.iso Subject: X/Windows and OSI Message-ID: <1990Jan11.115009.27548@gdt.bath.ac.uk> Date: 11 Jan 90 11:50:09 GMT Reply-To: iso-xwindows@uk.ac.rutherford Organization: University of Bath, England Lines: 177 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