home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v20 / repdir / 1003.12 < prev    next >
Internet Message Format  |  1990-08-02  |  6KB
  1. From uucp@tic.com  Thu Jun 21 18:02:12 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA26630; Thu, 21 Jun 90 18:02:12 -0400
  4. Posted-Date: 21 Jun 90 19:47:14 GMT
  5. Received: by cs.utexas.edu (5.64/1.63)
  6.     id AA11445; Thu, 21 Jun 90 17:02:06 -0500
  7. Received: by longway.tic.com (4.22/tic.1.2)
  8.     id AA18884; Thu, 21 Jun 90 16:36:44 cdt
  9. From: <jsh@usenix.org>
  10. Newsgroups: comp.std.unix
  11. Subject: Standards Update, IEEE 1003.12: PII
  12. Message-Id: <375@usenix.ORG>
  13. Sender: std-unix@usenix.ORG
  14. Reply-To: std-unix@uunet.uu.net
  15. Date: 21 Jun 90 19:47:14 GMT
  16. Apparently-To: std-unix-archive@uunet.uu.net
  17.  
  18. From:  <jsh@usenix.org>
  19.  
  20.  
  21.            An Update on UNIX*-Related Standards Activities
  22.  
  23.                                May 1990
  24.  
  25.                  USENIX Standards Watchdog Committee
  26.  
  27.                    Jeffrey S. Haemer, Report Editor
  28.  
  29. IEEE 1003.12: PII
  30.  
  31. Andy Nicholson <droid@earth.cray.com> reports on the April 23-27
  32. meeting in Salt Lake City, UT:
  33.  
  34. Introduction
  35.  
  36. For starters, we've had some significant turnover.  [Editor:
  37. Including, you'll note, Steve Head, our former, fine dot 12 snitch.
  38. Thanks for diving in, Andy.] We are now down to five participants who
  39. were present a year ago, are on our third AT&T representative, and an
  40. HP representative has permanently left the working group.  Despite all
  41. this, the group is beginning to make rapid advances on both the
  42. Simplified (SNI) and Detailed (DNI) network interfaces.  This
  43. meeting's progress is sketched below.
  44.  
  45. Overview of the Work We're Doing
  46.  
  47. The dot 12 committee is working on three projects: Simplified Network
  48. interface (SNI), Detailed Network Interface (DNI), and Data
  49. Representation Interface (DRI).  Work on DRI is being delayed until
  50. SNI and DNI are well along.  DNI is a protocol-independent interface
  51. to network services that allows access to protocol-dependent features
  52. in a protocol-independent manner.  DNI is meant to provide a complete
  53. interface to everything you might expect to be able to do with
  54. networking services.  DNI is comparable to Berkeley Sockets or AT&T's
  55. TLI, and we plan that anything that can be accomplished with those
  56. interfaces will be subsumed by DNI.
  57.  
  58. The idea behind SNI is that many applications will not require
  59. ``detailed'' access to networking services.  SNI gives a ``stdio''
  60. type of interface for networking that combines common groupings of
  61. procedures, eliminates access protocol-dependent features, and is just
  62. plain easier to use.  Applications that use SNI aren't necessarily
  63. simple, they just don't need DNI's detailed access to networking
  64. services.
  65.  
  66. __________
  67.  
  68.   * UNIX is a registered trademark of AT&T in the U.S. and other
  69.     countries.
  70.  
  71. May 1990 Standards Update                            IEEE 1003.12: PII
  72.  
  73.                 - 2 -
  74.  
  75. Simple Network Interface
  76.  
  77. We started the week discussing the SNI interface.  Norm Smith, from
  78. Unisys, had intended to bring an alternate SNI proposal to this
  79. meeting, but his group at Unisys decided to work with the current one.
  80. Irene Hu, from DEC, says she may yet offer an alternate proposal.
  81.  
  82. I presented a paper, prepared from previous minutes, which gathered up
  83. some deferred issues relating to SNI and we resolved some of them.
  84. For example, we added some explicit goals for SNI that everyone seemed
  85. to have accepted implicitly, but were never made official.
  86.  
  87. We also considered creating a formal definition of SNI functionality,
  88. to help us determine whether any particular function should be
  89. included, but decided it would be more efficient to keep deliberating
  90. each case individually.  We'll record the rationale for each as part
  91. of the standard document to help us avoid and respond to ballot
  92. objections.
  93.  
  94.    + SNI functionality
  95.      A paper by Tim Kirby (who works with me at Cray Research)
  96.      prompted the group to redefine a function call.  Sni_recv(), was
  97.      defined to discard excess data in a datagram when the buffer
  98.      offered by an application isn't large enough.  The new version of
  99.      Sni_recv(), allows an application either to discard excess data
  100.      or to perform multiple sni_recv() calls to read it all.  It also
  101.      allows applications to discard datagrams without reading them at
  102.      all.  Here, I think the group has noticeably extended the power
  103.      of the interface without sacrificing efficiency.
  104.  
  105.    + Kernel objects
  106.      Because SNI endpoints may not be kernel objects, we need to
  107.      define semantics and interfaces that will allow SNI endpoints to
  108.      survive exec().  Unfortunately, we disagree on the semantics of
  109.      the endpoint-preservation procedures.  Should multiple copies of
  110.      the same endpoint exist in different processes' address spaces,
  111.      as happens with fork() and exec()?  Implementing the protocol
  112.      stack in a user library creates multiple copies of state
  113.      information for the same endpoint, and it may be impossible to
  114.      keep them synchronized.
  115.  
  116.      Some of us (Keith Sklower, from Berkeley, the author of the SNI
  117.      document, and I) want to restrict endpoint semantics so that only
  118.      one process may have a copy of an SNI endpoint; others (Irene and
  119.      Norm) disagree and wish to allow multiple copies of SNI endpoints
  120.      where the programmer wishes.
  121.  
  122. May 1990 Standards Update                            IEEE 1003.12: PII
  123.  
  124.                 - 3 -
  125.  
  126. Detailed Network Interface
  127.  
  128. We discussed DNI procedures in detail for the first time and found
  129. tentative agreement on most of the many issues raised.  Mike Karels,
  130. from Berkeley's Computer Science Research Group, presented an outline
  131. of required functionality.  After discussing it, we agreed to make DNI
  132. endpoints POSIX file descriptors (as returned by open()) until we see
  133. a compelling counter-argument.  I'll challenge you to offer one.
  134.  
  135. On Wednesday, Irene gave an overview of XTI.  During the presentation,
  136. Torez Hiley, our new attendee from ATT, told us that XTI is being
  137. revised: input from vendors using the Berkeley socket interface is
  138. prompting the addition of many features.  Torez will report on the
  139. upcoming revision at the July meeting.  Where sockets and XTI/TLI
  140. differ, the best solution is not clear.  Moreover, some features are
  141. absent or inadequately supported in both interfaces.  Here, we have a
  142. lot of work to do and are just getting started.  We're eager to hear
  143. whether the new XTI solves any of our problems.
  144.  
  145. May 1990 Standards Update                            IEEE 1003.12: PII
  146.  
  147.  
  148. Volume-Number: Volume 20, Number 32
  149.  
  150.