exxpwj@gdr.bath.ac.uk (Phil Jones) (01/11/90)
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 KINGDOMklee@chico.pa.dec.com (Ken Lee) (01/12/90)
In case you missed it, here is the original MAP/TOP statement. MAP/TOP
is a U.S. consortium of industrial computer users, including General
Motors, Boeing, etc. They are one of the largest groups of OSI users
in the U.S. and are very influential with U.S. and computer networking
international standards.
ANSI, the U.S. standards organization, is standardizing the X Window
System protocol. Part of this work may include an OSI protocol
mapping. There is currently a debate (including theoretical work and
prototyping) within ANSI as to whether this mapping should be at the
ACSE level or Transport level. Detailed protocol mapping for each
have been submitted.
If you have comments on this issue, please contact me this week. The
ANSI window systems committee will be meeting next week (Jan. 12-16) to
try to resolve this issue.
Ken Lee
Secretary, ANSI X3H3.6 (Computer Graphics - Window Systems)
klee@decwrl.dec.com
==============================================================
Manufacturing Automation Protocol &
Technical and Office Protocol Users Group
89-00-002-ARC
December 13, 1989
MAP/TOP LIAISON TO ANSI X3H3.6
A high priority requirement of the MAP/TOP Users Group is to use X-Window
over OSI networks. As the MAP/TOP Users Group is committed to use interna-
tional or national standards whenever possible, it welcomes the work X3H3
is doing to standardize the X-Data Stream.
However, the MAP/TOP Users Group not only needs a Data Stream standard, but
also needs a standardized mapping of the X-Data Stream Definition onto OSI.
Without a standardized mapping, there is no way of ensuring interoperabil-
ity of implementations of the X-Data Stream from different vendors over OSI
networks.
To promote the timely adoption of such a mapping, the MAP/TOP Users Group
sent X3H3 a position statement in September 1989 (see 89-00-0002 USG)
encouraging X3H3 to include in the X-Data Stream standard a mapping at the
ACSE/Presentation level of OSI. As X3H3 has not yet made a decision on the
type of mapping to incorporate in the X-Data Stream definition, the MAP/TOP
Users Group wishes to reiterate its position that the mapping should be on
the ACSE/Presentation level of OSI. We hope the following will help X3H3
understand the reasons behind this position:
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.
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.
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.
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.
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
- 2 -
the same level of OSI (i.e., ACSE).
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.
X-Data Stream on OSI Prototyping
In discussing the X-Data Stream Definition/OSI mapping at the Technical
Forum meeting of December 11, 1989, it was reported that X3H3 is awaiting
the results of prototyping work to help make the decision as to which map-
ping to choose. We see prototyping as a valuable tool to determine if a
mapping candidate is correct. It is far better to ensure accuracy before
the standard goes to Public Review.
However, a few implementors at our meeting cautioned against attaching too
much weight on these results with regard to efficiency. As these implemen-
tations are just prototypes and not finished products, they will probably
not receive the attention and tuning for efficiency a finished product
would receive. Therefore, we feel performance figures from these proto-
types probably are not indicative of the performance levels which can be
expected of X-Window products based on the X-Data Stream Definition. For
example, a prototype may utilize the user interface to gain access to OSI
services, whereas an X-Product may bypass such an interface and use a fas-
ter internal OSI service interface.
CONCLUSION
In view of the above, the MAP/TOP Users Group urges X3H3 to adopt an
ACSE/Presentation mapping and to progress this mapping with the X-Data
Stream Definition as quickly as possible.
Ken Lee
DEC Western Software Laboratory, Palo Alto, Calif.
Internet: klee@decwrl.dec.com
uucp: uunet!decwrl!klee