home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.23 / text0100.txt < prev    next >
Encoding:
Text File  |  1991-06-15  |  3.5 KB  |  82 lines
  1. Submitted-by: randall@Virginia.EDU (Randall Atkinson)
  2.  
  3. In article <1991Jun12.034606.16284@uunet.uu.net>, 
  4.     Peter Collinson <pc@hillside.co.uk> writes:
  5.  
  6. >There was a problem with the Draft 11 distribution. POSIX.2 is now
  7. >over 900 pages. It's balloting period was 30 days, although with a
  8. >mailing lead it was about 6 weeks.  Due to postal services, some
  9. >members of the balloting group only received their ballot copies two
  10. >weeks prior to the closing deadline. Hal Jespersen was as
  11. >accommodating as he could be on the deadline, but the extent of these
  12. >submissions was definitely affected.  The question rears its head
  13. >again.  Should we be balloting POSIX standards the same as we ballot
  14. >smaller hardware standards?
  15.  
  16.   This is a very real problem.  I ended up abstaining on both the
  17. Ada-bindings and Threads ballots because I didn't have sufficient time
  18. to review the lengthy &/or complex ballots in the time allotted.
  19.  
  20.   It seems to me that the SEC should consider mandating that future
  21. ballots for the POSIX arena have a longer minimum balloting period
  22. than the IEEE requires.  This would not conflict with the IEEE
  23. requirements and would get better standards in the final result.
  24.  
  25. >New PARs
  26. >
  27. >The Project Management Committee (PMC) has recommended the proposed
  28. >PAR (Project Authorization Request) for 1003.2b be split into two
  29. >parts. One part will cover extensions and new requests from other
  30. >groups, such as the tar, cpio and new pax file formats from POSIX.1
  31. >(Kernel) and utilities from POSIX.4 (Realtime) and POSIX.6
  32. >(Security).  The timing and alignment issues with the ISO 9945-2
  33. >balloting process will be covered by the other part.
  34. >
  35. >The scope of this second PAR is restricted to standardization of
  36. >existing industry practice. The group does not want to get into
  37. >designing new utilities.
  38.  
  39.   Such a scope is the only appropriate one.  In particular the
  40. experience of other standards (e.g. ISO Network Protocol
  41. interoperability problems) have made it clear that it is best to
  42. standardise only existing practice and let there be actual implemented
  43. experience with new utlitites or features before putting them in the
  44. standard.
  45.  
  46.   I am glad to see this made explicit in the POSIX.2b PAR as it has
  47. been an ongoing concern of mine (in particular with regard to
  48. windowing interfaces that there isn't enough experience with).
  49.  
  50. >There is also concern over draft stability when discussing the
  51. >commands to access the features from the POSIX.4 and POSIX.6
  52. >standards. How mature does the feature have to be before the POSIX.2
  53. >group goes to the effort of defining a command interface to it ?
  54.  
  55.  
  56. It seems to me that if a draft hasn't even reached balloting that
  57. it is not sufficiently stable for the POSIX.2 WG to make much effort
  58. devising a suitable command interface for it.  There have been a lot
  59. of cases where changes occurred in balloting as well, so it might
  60. not even be stable enough at ballot-time.
  61.  
  62. >Discussion
  63.  
  64. >Richard Hart from POSIX.7 (System Administration) presented the syntax
  65. >for a new printing command based on the MIT/Athena Palladium network
  66. >printing services. Everyone in the POSIX.2 group agreed that the
  67. >proposed syntax was awkward.
  68.  
  69. The posted examples are pursuasive.  The printing commands should all
  70. be based on widespread existing practice in UN*X systems.  The MIT/Athena
  71. Palladium services are not widespread enough to justify their adoption.
  72.  
  73. >Requests for technology
  74. >
  75. >There is an opportunity now to propose a new archive format.  
  76.  
  77. Why is yet another archive format needed ??
  78.  
  79.  
  80. Volume-Number: Volume 23, Number 103
  81.  
  82.