Minutes of thinosi wg, columbus

[Peter Furniss <[e-mail]>]

THINOSI Working Group Minutes - 1st April 1993,
26th IETF meeting, Columbus, Ohio

This was our first meeting as a working group. Most of the time was
spent reviewing the first draft of the bytestream cookbook and
especially the technical choices of what OSI upper-layers features
should be included.

Some guiding principles emerged:

	- interworking with "full" OSI implementations was a key
purpose of the thinosi approach and must be maintained, even at the
cost of some complexity

	- inclusion or exclusion of features is determined by (and
determines) the set of application protocols that can be supported

	- it will be little trouble to add additional features (thus
widening the application range) once the basic format and style is
worked out - these could be alternatives in the same document or in
separate ones.

	- if at all possible the set of supported application
protocols should include DAP and X.400 P7 protocol. (These are not
actually byte-stream in the sense we have now, but at least DAP should
be possible with only a two octet change. P7 to be investigated.  PRF)

The following conclusions were reached (most of these are
confirmations of what is in the first draft):

	- expect to receive any of the various allowed encodings of
lengths etc.

	- describe sending of one application abstract-syntax and
transfer syntax name (in addition to the ACSE as & ts), but also
describe how, as responder, to locate and reply when these are one of
number of offered abstract syntaxes and/or transfer syntaxes (how to
send and use multiple as and ts is one of the extension possibilites)

	- do not use the invocations ids or the responding AP-title,
AE-qualifier (ignore happily on receipt)

	- do not use the userdata field on ACSE A-ASSOCIATE or
A-RELEASE exchanges

	- do allow the user data on the ACSE user abort to be u sed by
the application (typically to carry application- or
implementation-specific error/explanation messages)

	- use Session version 2 (with the Common Upper-Layer
Requirements limits on userdata)

	- include the correct procedure to follow when a release
collision occurs (this is different for the association initiator and
responder)

	- identify more clearly where the cookbook is taking advantage
of a CULR part 1 restriction

	- do not include re-use of transport (although this can
improve efficiency, it is always *additional* to starting with new
T-connections, and thus makes the implementation more complex.)

	- do not shorten the explanatory text at the beginning or move
it to another document (clarify it by all means)

	- change the layout of the octet sequences to a more rigid
tag-length-value column format, with the datatype of primitive values
in a fourth column. Indent to show the nesting if feasible. E.g.
	30  80  {4                . list of transfer syntaxes
	06  02  5101    oid       . BER transfer syntax
	00  00  }4                . e-o-c for ts list

The group was uncertain on whether the lengths of constructed elements
should all be indefinite, all definite, or follow a pattern of
whatever is convenient. For interworking all possibilities must be
understood on receipt, but various performance payoffs are possible.
The views of the mailing list will be sought.

There was also some discussion of related work in other circles.

	- A profile for "minimal OSI functionality" is being developed
in the OIW and EWOS regional workshops (these are the OSI profiling
bodies for North America and Europe). This is intended to be part
three of Common Upper-Layer Requirements.  The mOSI profile and
thinosi work have a common origin. At present, the upper-layer
facilities supported in mOSI and in thinosi are not quite the same. It
will be highly desirable for there to be one single selection of
features for both.  Attempts will be made to align these - in
particular the new draft of the cookbook should be made available to
the EWOS technical liaison group (TLG) in time for their next meeting
in April.

	- Within X/Open, a new appendix for the XTI interface is being
developed that defines the use of this interface for minimal OSI.

The group will meet in Amsterdam.