home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / thinosi / thinosi-minutes-93mar.txt < prev    next >
Text File  |  1993-05-04  |  5KB  |  146 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Peter Furniss/Consultant
  5.  
  6. Minutes of the Minimal OSI Upper-Layers Working Group (THINOSI)
  7.  
  8. This was our first meeting as a Working Group.  Most of the time was
  9. spent reviewing the first draft of the bytestream cookbook and
  10. especially the technical choices of what OSI upper-layers features
  11. should be included.
  12.  
  13. Some guiding principles emerged:
  14.  
  15.  
  16.    o Interworking with ``full'' OSI implementations was a key purpose of
  17.      the thinosi approach and must be maintained, even at the cost of
  18.      some complexity.
  19.  
  20.    o Inclusion or exclusion of features is determined by (and
  21.      determines) the set of application protocols that can be supported.
  22.  
  23.    o It will be little trouble to add additional features (thus widening
  24.      the application range) once the basic format and style is worked
  25.      out - these could be alternatives in the same document or in
  26.      separate ones.
  27.  
  28.    o If at all possible the set of supported application protocols
  29.      should include the DAP and X.400 P7 protocol.  (These are not
  30.      actually byte-stream in the sense we have now, but at least DAP
  31.      should be possible with only a two octet change.  P7 to be
  32.      investigated.  PRF)
  33.  
  34.  
  35. A number of conclusions were reached (most of these are confirmations of
  36. what is in the first draft). 
  37.  
  38.    o Expect to receive any of the various allowed encodings of lengths,
  39.      etc.
  40.  
  41.    o Describe sending of one application abstract-syntax and transfer
  42.      syntax name (in addition to the ACSE as & ts), but also describe
  43.      how, as responder, to locate and reply when these are one of a
  44.      number of offered abstract syntaxes and/or transfer syntaxes (how
  45.      to send and use multiple as and ts is one of the extension
  46.      possibilities).
  47.  
  48.    o Do not use the invocations ids or the responding AP-title,
  49.      AE-qualifier (ignore happily on receipt).
  50.  
  51.  
  52.                                    1
  53.  
  54.  
  55.  
  56.  
  57.  
  58.    o Do not use the userdata field on ACSE A-ASSOCIATE or A-RELEASE
  59.      exchanges.
  60.  
  61.    o Do allow the user data on the ACSE user abort to be used by the
  62.      application (typically to carry application- or
  63.      implementation-specific error/explanation messages).
  64.  
  65.    o Use Session version 2 (with the Common Upper-Layer Requirements
  66.      limits on userdata).
  67.  
  68.    o Include the correct procedure to follow when a release collision
  69.      occurs (this is different for the association initiator and
  70.      responder).
  71.  
  72.    o Identify more clearly where the cookbook is taking advantage of a
  73.      CULR part 1 restriction.
  74.  
  75.    o Do not include re-use of transport (although this can improve
  76.      efficiency, it is always *additional* to starting with new
  77.      T-connections, and thus makes the implementation more complex.)
  78.  
  79.    o Do not shorten the explanatory text at the beginning or move it to
  80.      another document (clarify it by all means).
  81.  
  82.    o Change the layout of the octet sequences to a more rigid
  83.      tag-length-value column format, with the datatype of primitive
  84.      values in a fourth column.  Indent to show the nesting if feasible.
  85.      e.g.,
  86.  
  87.      30  80  {4                . list of transfer syntaxes
  88.      06  02  5101    oid       . BER transfer syntax
  89.      00  00  }4                . e-o-c for ts list
  90.  
  91.  
  92.  
  93. The Group was uncertain on whether the lengths of constructed elements
  94. should all be indefinite, all definite, or follow a pattern of whatever
  95. is convenient.  For interworking all possibilities must be understood on
  96. receipt, but various performance payoffs are possible.  The views of the
  97. mailing list will be sought.
  98.  
  99. There was also some discussion of related work in other circles.
  100.  
  101.  
  102.    o A profile for ``minimal OSI functionality'' is being developed in
  103.      the OIW and EWOS regional workshops (these are the OSI profiling
  104.      bodies for North America and Europe).  This is intended to be part
  105.      three of Common Upper-Layer Requirements.  The mOSI profile and
  106.      thinosi work have a common origin.  At present, the upper-layer
  107.      facilities supported in mOSI and in thinosi are not quite the same.
  108.      It will be highly desirable for there to be one single selection of
  109.      features for both.  Attempts will be made to align these - in
  110.  
  111.                                    2
  112.  
  113.  
  114.  
  115.  
  116.  
  117.      particular the new draft of the cookbook should be made available
  118.      to the EWOS technical liaison group (TLG) in time for their next
  119.      meeting in April.
  120.  
  121.    o Within X/Open, a new appendix for the XTI interface is being
  122.      developed that defines the use of this interface for minimal OSI.
  123.  
  124.  
  125. The Group will meet in Amsterdam.
  126.  
  127. Attendees
  128.  
  129. John Boatright           bryan_boatright@ksc.nasa.gov
  130. Kevin Carosso            kvc@innosoft.com
  131. George Chang             gkc@ctt.bellcore.com
  132. Peter Furniss            p.furniss@ulcc.ac.uk
  133. Sylvain Langlois         Sylvain.Langlois@exp.edf.fr
  134. Mark Needleman           mhn@stubbs.ucop.edu
  135. Geir Pedersen            Geir.Pedersen@usit.uio.no
  136. Jim Romaguera            romaguera@cosine-mhs.switch.ch
  137. Keith Sklower            sklower@cs.berkeley.edu
  138. Klaus Truoel             truoel@gmd.de
  139. William Warner           warner@ohio.gov
  140. Les Wibberley            lhw24@cas.org
  141. Charles Young            Charles.E.Young@att.com
  142.  
  143.  
  144.  
  145.                                    3
  146.