home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0035.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  7.0 KB  |  155 lines
  1. Submitted-by: stephe@usenix.org (Stephen R. Walli)
  2.  
  3. Report on POSIX.17 - Directory Services API
  4.  
  5.  
  6. Mark Hazzard <markh@rsvl.unisys.com> reports on the April 6 - 10, 1992
  7. meeting in Dallas, Texas:
  8.  
  9. Summary
  10.  
  11. Draft 3.0 of POSIX.17 began IEEE ballot on April 7th and finished the
  12. first round of balloting May 19th with 84% of the ballot group
  13. responding. We completed sending responses to all who participated in
  14. the Mock Ballot of Draft 2.0.
  15.  
  16. The group formed a ballot resolution team, and dealt with the "Which
  17. track to ISO?" issue. Splitting/re-casting our Project Authorization
  18. Request (PAR) was a hot topic. We're following a PMC recommendation
  19. to separate the Directory Services API work (which is in ballot) from
  20. the POSIX name space issue which hasn't received much attention.
  21.  
  22. Introduction
  23.  
  24. The POSIX.17 group has defined and is balloting a user to directory
  25. API (e.g. API to an X.500 DUA - Directory User Agent). We used APIA -
  26. X/Open's XDS specification as a basis for work. XDS is an object
  27. oriented interface and requires a companion specification (XOM) for
  28. object management.
  29.  
  30. XOM is a stand-alone specification with general applicability beyond
  31. the API to directory services. It is used by IEEE P1224.1 (X.400 API)
  32. and is being standardized by the P1224 working group.
  33.  
  34. The current POSIX.17 PAR has a two part scope. The first authorizes
  35. the group to work on an API to directory services. The second (and
  36. more contentious) part addresses the POSIX name space issue. The
  37. working group has discussed name space, but decided to focus on the
  38. API to directory.
  39.  
  40. POSIX.17 is one of five "networking" groups under TCOS, and comes
  41. under the purview of the Distributed Services Steering Committee
  42. (DSSC).
  43.  
  44. Status
  45.  
  46. The group finally completed all the written responses to the comments
  47. received from the Mock Ballot of Draft 2.0 of our document. If you
  48. responded, you should have a reply by now.
  49.  
  50. Draft 3.0 of POSIX.17 was distributed for IEEE ballot just prior to
  51. the Dallas meeting, and included all test methods and the language
  52. independent specification (LIS). The document grew from 234 pages in
  53. Draft 2.3 to 478 pgs in Draft 3.0 with the inclusion of all remaining
  54. test methods.
  55.  
  56. As of this writing, the 1st ballot is now officially closed, with 84%
  57. of the Ballot Group returning ballots.
  58.  
  59. Once again, we met with POSIX.12 (Protocol Independent Interfaces) in
  60. joint session and discussed their requirements on directory services.
  61. The white paper produced by POSIX.17 was used as a basis for moving
  62. ahead on requirements. (The white paper was the result of an action
  63. taken in Irvine to document agreements, assumptions, issues, options
  64. and proposed actions.)
  65.  
  66. The meeting was quite productive and resulted in an understanding on
  67. how to progress the work. POSIX.17 took an action to assist the
  68. POSIX.12 group with writing an annex mapping a simplified, more
  69. focused interface to the POSIX.17 API.
  70.  
  71. Some POSIX.17 members met with P1224 to process the
  72. comments/objections raised during the initial round of balloting of
  73. the object management specification.
  74.  
  75. The PMC recommended in January that the POSIX.17 project request (PAR)
  76. be split into two separate projects, one for the Directory Services
  77. API work (which is in ballot) and the other for the POSIX name space
  78. issue which hasn't received much attention.
  79.  
  80. Name space conjures up many different things for different audiences.
  81. Some folks see the issue as a language issue, dealing with function
  82. prefixes and the like. The working group sees the issue as one in
  83. which objects are uniquely named in a global context, i.e. beyond a
  84. single kernel. If we use the process id as an example, we find that
  85. the 5- digit positive integer used as the name for a process within
  86. most kernels doesn't scale too well globally. If I want to have a
  87. utility that determines the status of all my processes, even those on
  88. other kernels, I have to somehow extend the name space.
  89.  
  90. There was a spirited debate as to whether or not a second PAR was
  91. needed for name space work, in that the issues could be resolved by
  92. some other mechanism in the TCOS realm. Neither POSIX.17 nor the
  93. System Interface Coordination Committee (SICC) believe that POSIX.17
  94. owns the ``C'' name space issue. A white paper will be produced
  95. summarizing the name space issue and the work to date. Stay tuned ...
  96.  
  97. The road to ISO
  98.  
  99. The group spent much time debating how to progress the POSIX.17 API
  100. work for ISO standardization. The central point of contention was a
  101. proposal to remove the POSIX.17 API from ISO 9945-1 to join
  102. P1224/P1224.1 in a to-be- determined track in ISO. [Ed. - ISO/IEC
  103. 9945-1 is the ISO name for IEEE 1003.1, or POSIX.1. All other system
  104. interfaces, such as POSIX.4 real-time and POSIX.6 security, are
  105. supposed to be integrated to 9945-1 in future ammendments.]
  106.  
  107. The rationale given was that since the POSIX.17 work is dependent on
  108. P1224 and all three documents share the same style of interface and
  109. roots, they should all be progressed to ISO within the same Working
  110. Group. Since P1224 and P1224.1 aren't part of (and won't be part of)
  111. 9945-1, POSIX.17 should be pulled out of 9945-1 and progressed with
  112. the other two documents.
  113.  
  114. There is a risk that ISO SC22/WG15 (the ISO POSIX SubCommittee 22
  115. Working Group) will not accept a work item for an API to directory
  116. services outside of 9945-1. The implication is that a new SC22 working
  117. group (or one from SC21 or SC18) may be required for this work, with
  118. all the associated start-up overhead. All this could delay the work
  119. and subsequently jeopardize its completion as an ISO standard.
  120.  
  121. Taking the work from 9945-1 also breaks the link requiring a
  122. distributed POSIX system to include an API to directory services. At
  123. least one other distributed services working group (POSIX.12) was
  124. concerned about this as well.
  125.  
  126. Arguments against the non-9945-1 track to ISO resulted in a compromise
  127. that will (hopefully) allow us to retain the reference to the POSIX.17
  128. work in a work item for 9945-1. The work item could revert to a
  129. pointer to the work being done outside of 9945-1 (if that comes about)
  130. and also serve as a place holder for our work within SC22 WG15 if
  131. another track couldn't be found.
  132.  
  133. A resolution was prepared for the SEC, proposing that the SEC
  134. authorize POSIX.17 to take several actions relating to the mechanics
  135. of progressing our document through the IEEE ballot process and on to
  136. ISO. After some initial tough sledding late Thursday night, (my
  137. Minnesota roots showing), the SEC accepted all the time critical
  138. aspects of the resolution, deferring the rest until Chicago.
  139.  
  140. In Closing ...
  141.  
  142. Once again, there are quite a few homework assignments between
  143. meetings. The ballot resolution process begins. Look for a white
  144. paper rationalizing the directory services API work with the name
  145. space issue. We also need to submit a New Project proposal for
  146. progressing the POSIX.17 to ISO within SC22.
  147.  
  148. The group will meet next time in Chicago, concentrating on Ballot
  149. resolution and name space issues. We plan to meet in Utrecht and
  150. possibly for a few days in Reading, UK, to complete the work for our
  151. first (and hopefully final) ballot recirculation.
  152.  
  153. Volume-Number: Volume 28, Number 37
  154.  
  155.