Minutes from Amsterdam meeting

[Peter Furniss <[e-mail]>]

This  is what I am sending in to the secretariat. Hope it's true !

Reported by Peter Furniss/consultant

Minutes of the Minimal OSI Upper-layers Working Group 
(thinosi)

The thinosi Working Group met on 15th July at the Amsterdam IETF. 
Most of the time was devoted to reviewing the upper-layer cookbook.

1. Upper-layer cookbook

Various issues were discussed in the review of the cookbook. A 
point that came up more than once was how the cookbook should 
relate to the parallel work in the OSI regional workshops (the 
Common Upper-Layer Requirements Part 3 : Minimal OSI 
profile(CULR3)) and in X/Open (specification of use of the XTI 
interface for minimal OSI(XTI/mOSI)).

The three (or four) categories of application that the cookbook can 
support need to be further clarified, making the distinctions purely on 
which OSI facilities are used and not the use of ASN.1. Examples of 
application protocols in each category would be useful. If possible 
the categories should be linked to those in CULR-3 and XTI/mOSI. 
This may not be straightforward due to the different approaches of 
the three documents : OSI-style profile, API definition and 
implementor's profile/respecification. Josee Auber will attempt to 
compare/contrast the three approaches in a message for the thinosi 
list.

The possibility of the cookbook having a formal statement of 
compliance to CULR-3 was discussed. CULR-3 defines compliance 
statements by which another specification (e.g. the cookbook) can 
state that its use and support of the OSI facilities complies with 
CULR-3. However, CULR-3 is being developed in the OSI regional 
workshops (OIW leading, EWOS involved) and will probably have to 
follow the conformance requirements of the base OSI standards. 
Some of the base standards have over-enthusiastic conformance 
requirements, which go beyond the cookbook target, which is 
"interworking with conformant implementations". This is especially 
true for Presentation. Moves are afoot in ISO/IEC to get this sorted 
out, but for the time being at least the cookbook should not be 
committed to comply with CULR-3. 

The cookbook specifies the use of indefinite lengths where possible 
for sending the Presentation PCI (this is equivalent to the "Canonical 
Encoding Rules", a newly-defined subset of BER). There had been 
suggestion that the opposite choice (Distinguished Encoding Rules - 
definite-length throughout) would be a preferable simplification. 
Which is found to be the easier to encode or decode is considerably 
a matter of the coding approach taken. Peter claimed that for these 
supporting layers (as distinct from the encoding of application 
protocol) the canonical choice was best.

Peter will attempt to get a new draft of the cookbook out by the end 
of July and will submit it for posting as an Internet-Draft.

The eventual status of the cookbook was discussed, and it was 
believed it should be targetted for the standards track, as the 
specification of the supporting protocol layers for the relevant 
applications.

2. Revision of charter

Since the charter was written (following the Washington BOF), the 
coverage of the cookbook has changed to more than just "byte-
stream" (although the amount of new text is small), and the charter 
needs to be changed to reflect this. Other possible changes were 
discussed,. It was concluded that the intended thinDAP document 
should stay in the plan, but the dates may need revision. Given the 
nature of the cookbook, it will be worth considering the production of 
some very brief "mapping specifications", that would state precisely 
how particular applications (Z39.50 for example) would use the 
cookbook.

Peter Furniss will work up a draft revision and post it to the list

3 Over the fence : activities in other arenas

CULR-3 has been revised again (June 1993) and it is intended to be 
submitted for ballot to become an ISP early next year.

The XTI/mOSI specification will shortly be published by X/Open as a 
"Preliminary Specification". A Preliminary Specification is valid for a 
year, and may change subsequently.

4 Implementation plans

Peter Furniss was expecting to start extending the X/osi code to a 
more general thinosi implementation, with XTI/mOSI as the upper 
interface. Terry Sullivan of Florida is very keen to start something to 
support Z39.50.