home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0015.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  6.2 KB  |  154 lines
  1. Submitted-by: pc@hillside.co.uk (Peter Collinson)
  2.  
  3. USENIX Standards Watchdog Committee
  4. Stephen R. Walli <stephe@usenix.org>, Report Editor
  5. Report on POSIX.17 - Name Space/Directory Services
  6.  
  7.  
  8. Mark Hazzard <markh@rsvl.unisys.com> reports on the  meeting
  9. in Chicago, Illinois:
  10.  
  11. Summary
  12.  
  13. The POSIX.17 group is generating a user to directory services API, for
  14. example an API to an X.500 Directory User Agent (DUA).  We are
  15. referring to a network idea of a directory, not the ``file which
  16. contains file entries'' defined in POSIX.1.  It is not limited to just
  17. the X.500 functionality. We are using XAPIA - X/Open's Directory
  18. Services specification (XDS) as a basis for work.  XDS is an object
  19. oriented interface and requires a companion specification for object
  20. management (XOM).
  21.  
  22. XOM is a stand-alone specification with general applicability beyond
  23. the API to directory services.  It will be used by IEEE 1224.1 (X.400
  24. API) and possibly other POSIX groups, and is being standardized by
  25. IEEE 1224.
  26.  
  27. We made significant progress on a third draft of the document in
  28. Chicago, with the language independent specification work still to be
  29. done. We hope to mock ballot the document sometime after the July
  30. working group meeting.  POSIX.12 (Protocol Independent Interfaces) and
  31. POSIX.17 worked together this week and arrived at a number of
  32. scenarios for coordinating the work. POSIX.17 is taking steps to
  33. determine if their work overlaps with the proposed work of certain
  34. ISO/SC21 (OSI) working groups.
  35.  
  36. Status
  37.  
  38. Commitment within the group remains adequate, but there's more than
  39. enough work to go around.
  40.  
  41. Chris Harding, our Technical Editor (from X/Open), brought a second
  42. draft of the specification to the meeting.  We made significant
  43. progress towards producing a third draft with emphasis on format
  44. cleanup, model, overview sections and test assertions.
  45.  
  46. The ``homework'' assignments on Language Independent Specification
  47. (LIS) weren't completed and additional work on LIS was put on hold
  48. until the outcome of the SEC meeting.  There seemed to be some
  49. confusion as to the applicability of the LIS requirement for POSIX.17
  50. and other Distributed Services APIs.  The SEC reaffirmed the LIS
  51. requirement.  The LIS work was reassigned to the Technical Editor.
  52.  
  53. The big debate on generalizing the Object Management API never
  54. materialized.  (Refer to the three snitch reports on the New Orleans
  55. 1991 meeting.) I strongly suspect this was largely due to the absence
  56. of Scott ``Owls in the bushes'' Guthrey at the Chicago meeting.
  57.  
  58. Requirements from POSIX.12
  59.  
  60. The group met with POSIX.12 (Protocol Independent Interfaces) to get
  61. their requirements for the POSIX.17 API.  They expressed the desire
  62. (necessity?) to:
  63.  
  64.    - access existing directory services (e.g.  DNS) via the
  65.      POSIX.17 API
  66.  
  67.    - map the existing BSD API (e.g. gethostbyname,
  68.      getservbyname, etc.) onto the POSIX.17 API.
  69.  
  70. We discussed at length how these and other requirements should best be
  71. met, and produced three different scenarios describing relationships
  72. between the user application, the directory API(s), the directory
  73. service(s) and the transport service (accessed via POSIX.12's
  74. Simplified Network Interface).
  75.  
  76. In the first scenario, the transport provider (SNI) would talk
  77. directly to all directory services e.g.  DNS, X.500, etc.  Each
  78. directory service resolver would be accessed through its native
  79. interface, of which POSIX.17 would be just another API.
  80.  
  81. In scenario two, POSIX.17 would be the only API and would be used to
  82. access all directory services.  To access a non- X.500 DUA, the
  83. underlying implementation might have to translate POSIX.17 calls into
  84. the appropriate format and invoke the corresponding resolver.
  85.  
  86. In the final scenario, POSIX.17 would again be the only API, but only
  87. one resolver (X.500 DUA) would be used to query a single composite
  88. information base (DIB) containing information on all objects (e.g.
  89. DNS Resource Records and X.500 Distinguished Names).
  90.  
  91. In each of the scenarios, impact to the POSIX.17 API will be minimal.
  92. However, significant impact is anticipated for the underlying
  93. implementation and directory information base.
  94.  
  95. We discussed the relative merits of each and decided that at some
  96. future time a single API, resolver (agent), directory service and
  97. information base just might be the best for POSIX systems.  We also
  98. recognized that POSIX systems will need to interoperate with non-POSIX
  99. systems for the foreseeable future, and that fact won't be lost on
  100. implementors.
  101.  
  102. Live long and prosper! or Extending the life of our standard
  103.  
  104. The base document defines both the API and the collection of objects
  105. managed through the API, called a ``package.''
  106.  
  107. We believe that packages will be much more dynamic than the API
  108. itself, and could be unbundled from the API to give the API greater
  109. stability.  We actioned the Distributed Services Steering Committee
  110. (DSSC) to recommend a common solution, as this problem is shared by
  111. other networking groups.  We expect the DSSC to take this issue up in
  112. Santa Clara.
  113.  
  114. Mock Ballot
  115.  
  116. We decided to try to mock ballot our document sometime after the July
  117. meeting. After reaching agreement on the minimum document content for
  118. mock ballot, we assigned actions to get this work done.  We wish to
  119. solicit input on requirements and feedback on our LIS and Test
  120. Assertion work.
  121.  
  122. Is SC21 doing APIs too?
  123.  
  124. With the granting of any IEEE project request (PAR) comes a
  125. responsibility to coordinate with other de jure standards bodies, the
  126. list of which is included on the PAR itself.  In fulfilling this
  127. obligation, the group has learned (and dutifully reported to the SEC)
  128. that ISO SC21 is considering working on APIs to OSI application level
  129. services.  This work has a potential to overlap the SC22 supported work
  130. being done by IEEE TCOS/POSIX (e.g.  POSIX.17, P1224, P1238).
  131.  
  132. In Closing ...
  133.  
  134. The group made good solid progress in Chicago, and our document is
  135. beginning to ``flesh out.'' We think we understand what's required for
  136. test assertions and language independence, and have done several
  137. things to make the base document more readable.  If we can maintain
  138. ``critical mass'' within the group, we have a good chance of going to
  139. mock ballot yet this year.  There's a lot of work to do, so if anyone
  140. out there can make it to Santa Clara in July ...
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152. Volume-Number: Volume 24, Number 17
  153.  
  154.