Editor's Note: Minutes received 11/28/92 CURRENT_MEETING_REPORT_ Reported by Peter Furniss/PFC Minutes of the XWindows over OSI and Skinny Stack BOF (THINOSI) Following the previous BOF meeting, a draft working group Charter had been put into IESG by Peter Furniss. However, the aim of the Charter had not been sufficiently clear, and the BOF met again to clarify what was wanted and what it was appropriate to do in the IETF arena, if anything. Peter Furniss suggested that the (or just his) overall objective was to show that the OSI upper-layer protocols were, or could be, lightweight. The documents are certainly heavy, and the OSI model is liable to lead to implementations that are heavyweight. A fully general-purpose implementation will be large, but an implementation designed for a particular purpose need not be. This was the essence of the ``skinny stack'' approach, which could also be summarised as an implementation of the protocols but not of the OSI documents. In the skinny stack: o The OSI layers are merged. o Pre-coded octet sequences are used for sending, where possible. o In received protocol, only the values needed are looked for. Additional principles are that only protocol conformant to the OSI standards is sent, and *any* conformant protocol can be received. Consequently a skinny implementation can interwork with a `full' (non- skinny) implementation *that is supporting the same application*. It is implicit in the skinny approach that there is some kind of specialisation. The possibility of light-weight implementations had contributed to the choice of mapping to OSI specified for the X Windows System protocol in an EWOS [European Workshop on Open Systems] Technical Guide (ETG 13) and in the draft ANSI standard dpANS X3.196 part IV. These define use of the full 7-layers of OSI, sending the separately defined X byte stream (as would be sent over TCP) over Presentation, with connection establishment using ACSE (Association Control Service Element). It was pointed out by Keith Sklower that it would be perfectly feasible to carry X directly on OSI Transport, without the addition of Session, Presentation and ACSE. Possibly some additional specification would be needed to provide the equivalent of TCP graceful close. From the following discussion: o Possibly no work would be needed for graceful close (it can be treated as a local matter). o The whole point of the skinny approach was that the cost of the 1 additional layers was minimal. o The additional layers made X into a ``normal'' OSI application - it could use whatever support facilities became available for such. o The most appropriate mapping rather depended on the anticipated environment - there were those who wanted to use X in an all-OSI environment A pilot implementation of the EWOS ETG13 mapping, using skinny techniques, was available at the University of London Computer Centre. There were versions for different interfaces to OSI Transport service, not all available yet. Brien Wheeler/Mitre had an independent implementation using the ISODE upper-layers. Peter suggested there were two possible directions to take the skinny approach from X - ``wider'' and ``higher''. ``Wider'' would be to extend it to support other TCP-using application protocols - this could be just to other ``simple byte stream'' protocols, or to provide equivalence of all TCP features, or to specific (standardised) applications. ``Higher'' would be to include the skinny implementation of OSI protocols - Directory Access Protocol, ROSE, CMIP, Transaction Processing. The BOF then considered what the worthwhile future activities for a working group in this area were. The possibilities were: 1. Promote the deployment of X/osi, including interworking experiments. 2. Extend the skinny stack as an alternative carrier for other TCP-using protocols. 3. Produce specifications of skinny stack for some OSI application protocols. The questions for 2 were how far to take the extension, and what exactly, if anything, needed to be done within the IETF. Specification of a profile for ``migrant applications'' is being progressed in the OSE Implementors Workshop (OIW). The possibility of defining the use of the Berkeley socket API for access to skinny stack OSI was considered - this had been the basis of the previous draft Charter, which had met problems. It was perceived that what was needed was a re-specification of the OSI protocols in simpler terms - the definition of the ``skinny bits'', the octet sequences that must be sent and received to conform to the protocol specifications. The re-specification would not be concerned with which (OSI) document required the particular bits, but just what they were. This could be limited to the octet sequences required for X, but it would be a minimal addition to extend this for other simple byte-stream protocols. It would not be extended to cover the full equivalence to TCP, nor for specific standardised protocols. Most of the details of this have already been worked out in developing 2 the ULCC/Furniss X/osi pilot. The specification would also be usable as the supporting layers for OSI application protocols that only use the kernel and duplex session functional units and a single presentation context (apart from that for ACSE) -- however, for these some other component of the system will be handling the ASN.1 encoding/decoding of the application protocol. The development of implementations using this specification and their deployment would be encouraged in the usual way. The existing X/osi implementations are essentially using this specification. For 3, various candidate application protocols were discussed, but the obvious example was the Directory Access Protocol. Again a specification of the ``skinny bits'' would be the best way to facilitate implementation. This would be an effective test of the skinny approach -- it might not be possible to produce a useful, concise specification, or an efficient and reasonably small implementation. The level of functionality would be a deciding factor - an increasing scale would be: o Look up P-address given application-entity title. o Look up O/R name. o Provide equivalent function to LDAP (lightweight directory access protocol). o Everything in DAP. If a lightweight DAP implementation is possible it will have the virtue of being able to interwork with a standard DSA, without requiring intervening converters or special DSAs. Peter Furniss agreed to produce a draft Charter on these lines. The development tasks would be the ``skinny bits'' for simple byte-stream applications and the ``skinny bits'' for DAP. A mailing list for the Working Group has now been set up: thinosi@ulcc.ac.uk with thinosi-request@ulcc.ac.uk as the place to send requests to join. Attendees Richard Colella colella@osi.ncsl.nist.gov John Dale jdale@cos.com Richard desJardins desjardi@boa.gsfc.nasa.gov Peter Furniss p.furniss@ulcc.ac.uk Steve Hardcastle-Kille s.kille@isode.com Susan Hares skh@merit.edu Triet Lu triet@cseic.saic.com David Piscitello dave@sabre.bellcore.com James Quigley jim_quigley%YO@hp6600.desk.hp.com Keith Sklower sklower@cs.berkeley.edu Brien Wheeler blw@mitre.org Cathy Wittbrodt cjw@nersc.gov 3 4