home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v6 / text0001.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  3.0 KB  |  64 lines
  1. This article is a slightly adapted copy of an earlier one.
  2.  
  3. There seems to be widespread confusion as to the relation of the
  4. newsgroup mod.std.unix (aka the mailing list STD-UNIX) and the
  5. IEEE P1003 standards committee.  Allow me to try to clear some of it up.
  6.  
  7.  
  8. Because something is discussed in mod.std.unix does not mean that
  9. it is automatically proposed to P1003 for inclusion in the standard.
  10. Proposals to the committee have to be more formal.  Especially they
  11. have to include specific proposed wording.
  12.  
  13. As it happens, the moderator of the newsgroup is also the USENIX
  14. representative to the committee.  As such, I am willing to present
  15. proposals to the committee if someone actually has some to present.
  16. However, the proposer has to specifically request that for a specific
  17. proposal and I have to agree to it before it will happen.
  18.  
  19. It is true that several committee members follow the newsgroup and
  20. that I make sure that copies of articles from the newsgroup go to
  21. appropriate technical reviewers or are mentioned to the committee
  22. as a whole.  However, they are not presented as proposals:  they
  23. are presented as comments.  They may help committee members understand
  24. the context of a topic which is treated in the standards document,
  25. but they are unlikely to cause new topics to be added to the document.
  26.  
  27. This is not to say that input from the newsgroup is not useful
  28. to the committee.  A number of problems with the latest drafts
  29. were pointed out in the newsgroup and fixed because of that.
  30. The time zone discussion has brought up some points which will
  31. probably affect the eventual treatment of that subject by the
  32. committee.
  33.  
  34.  
  35. Because something is discussed in mod.std.unix does not even
  36. necessarily mean that it has anything to do with the P1003 committee.
  37.  
  38.  
  39. The committee is very aware that they should not be introducing
  40. new facilities.  It has happened a few times.  The only one
  41. I can think of at the moment is file locking, specifically the
  42. mandatory locking feature of flock (which was actually introduced
  43. by the /usr/group committee).  This is also, not coincidentally,
  44. one of the most controversial things in the current document
  45. (at the moment it's in an appendix), even though its proponents
  46. only back it because they are convinced it is necessary.
  47.  
  48. You will find things in the draft standard document which do not
  49. correspond to your local system, regardless of what your local system
  50. is.  This is because in the real world there are at least two major
  51. variants of UNIX and many minor ones.  To pick one and standardize on
  52. it alone would be to try to outlaw all the others.  This is probably
  53. not even possible, even if it were desirable.  The committee has chosen
  54. instead to try to produce something which is not exactly like anything
  55. out there but which can be implemented with relatively minor changes on
  56. most existing systems.
  57.  
  58. Ritual disclaimer:  this article is constructed of my personal opinions
  59. and does not necessarily represent any official position of IEEE, P1003,
  60. USENIX, /usr/group, or any other organization.
  61.  
  62. Volume-Number: Volume 6, Number 2
  63.  
  64.