Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/thinosi/thinosi-minutes-92nov.txt

Text File | 1993-02-17 | 8KB | 188 lines

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:
[e-mail] with [e-mail] as the place to send
requests to join.

Attendees

Richard Colella          [e-mail]
John Dale                [e-mail]
Richard desJardins       [e-mail]
Peter Furniss            [e-mail]
Steve Hardcastle-Kille   [e-mail]
Susan Hares              [e-mail]
Triet Lu                 [e-mail]
David Piscitello         [e-mail]
James Quigley            [e-mail]
Keith Sklower            [e-mail]
Brien Wheeler            [e-mail]
Cathy Wittbrodt          [e-mail]

                                   3








4