std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/05/86)
There seems to be widespread confusion as to the relation of the newsgroup mod.std.unix (aka the mailing list STD-UNIX) and the IEEE P1003 standards committee. Allow me to try to clear some of it up. Because something is discussed in mod.std.unix does not mean that it is automatically proposed to P1003 for inclusion in the standard. Proposals to the committee have to be more formal. Especially they have to include specific proposed wording. As it happens, the moderator of the newsgroup is also the USENIX representative to the committee. As such, I am willing to present proposals to the committee if someone actually has some to present. However, the proposer has to specifically request that for a specific proposal and I have to agree to it before it will happen. It is true that several committee members follow the newsgroup and that I make sure that copies of articles from the newsgroup go to appropriate technical reviewers or are mentioned to the committee as a whole. However, they are not presented as proposals: they are presented as comments. They may help committee members understand the context of a topic which is treated in the standards document, but they are unlikely to cause new topics to be added to the document. This is not to say that input from the newsgroup is not useful to the committee. A number of problems with the latest drafts were pointed out in the newsgroup and fixed because of that. The time zone discussion has brought up some points which will probably affect the eventual treatment of that subject by the committee. Because something is discussed in mod.std.unix does not even necessarily mean that it has anything to do with the P1003 committee. The directory umask discussion is an example. No one has proposed that the committee incorporate such a facility, and I would be surprised if anyone did. There were three main reasons I originally brought the subject up: I've never heard any convincing arguments for why it was not done that way in the first place; Somebody might think of a way to implement it which avoided the tar and rcp type problems; and There has been so little traffic in the newsgroup lately that a slightly controversial subject seemed indicated. The committee is very aware that they should not be introducing new facilities. It has happened a few times. The only one I can think of at the moment is file locking, specifically the mandatory locking feature of flock (which was actually introduced by the /usr/group committee). This is also, not coincidentally, one of the most controversial things in the current document (at the moment it's in an appendix), even though its proponents only back it because they are convinced it is necessary. You will find things in the draft standard document which do not correspond to your local system, regardless of what your local system is. This is because in the real world there are at least two major variants of UNIX and many minor ones. To pick one and standardize on it alone would be to try to outlaw all the others. This is probably not even possible, even if it were desirable. The committee has chosen instead to try to produce something which is not exactly like anything out there but which can be implemented with relatively minor changes on most existing systems. I will post a report on the latest committee meeting soon in which I will try to sketch how the committee actually works. Ritual disclaimer: this article is constructed of my personal opinions and does not necessarily represent any official position of IEEE, P1003, USENIX, /usr/group, or any other organization. Volume-Number: Volume 5, Number 36
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (03/25/86)
This article is a slightly adapted copy of an earlier one. There seems to be widespread confusion as to the relation of the newsgroup mod.std.unix (aka the mailing list STD-UNIX) and the IEEE P1003 standards committee. Allow me to try to clear some of it up. Because something is discussed in mod.std.unix does not mean that it is automatically proposed to P1003 for inclusion in the standard. Proposals to the committee have to be more formal. Especially they have to include specific proposed wording. As it happens, the moderator of the newsgroup is also the USENIX representative to the committee. As such, I am willing to present proposals to the committee if someone actually has some to present. However, the proposer has to specifically request that for a specific proposal and I have to agree to it before it will happen. It is true that several committee members follow the newsgroup and that I make sure that copies of articles from the newsgroup go to appropriate technical reviewers or are mentioned to the committee as a whole. However, they are not presented as proposals: they are presented as comments. They may help committee members understand the context of a topic which is treated in the standards document, but they are unlikely to cause new topics to be added to the document. This is not to say that input from the newsgroup is not useful to the committee. A number of problems with the latest drafts were pointed out in the newsgroup and fixed because of that. The time zone discussion has brought up some points which will probably affect the eventual treatment of that subject by the committee. Because something is discussed in mod.std.unix does not even necessarily mean that it has anything to do with the P1003 committee. The committee is very aware that they should not be introducing new facilities. It has happened a few times. The only one I can think of at the moment is file locking, specifically the mandatory locking feature of flock (which was actually introduced by the /usr/group committee). This is also, not coincidentally, one of the most controversial things in the current document (at the moment it's in an appendix), even though its proponents only back it because they are convinced it is necessary. You will find things in the draft standard document which do not correspond to your local system, regardless of what your local system is. This is because in the real world there are at least two major variants of UNIX and many minor ones. To pick one and standardize on it alone would be to try to outlaw all the others. This is probably not even possible, even if it were desirable. The committee has chosen instead to try to produce something which is not exactly like anything out there but which can be implemented with relatively minor changes on most existing systems. Ritual disclaimer: this article is constructed of my personal opinions and does not necessarily represent any official position of IEEE, P1003, USENIX, /usr/group, or any other organization. Volume-Number: Volume 6, Number 2
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/22/86)
This article is a slightly adapted copy of an earlier one. There seems to be widespread confusion as to the relation of the newsgroup mod.std.unix (aka the mailing list STD-UNIX) and the IEEE P1003 standards committee and its subcommittees. Allow me to try to clear some of it up. Because something is discussed in mod.std.unix does not mean that it is automatically proposed to P1003 for inclusion in the standard. Proposals to the committee have to be more formal. Especially they have to include specific proposed wording. As it happens, the moderator of the newsgroup is also the USENIX representative to the committee. As such, I am willing to present proposals to the committee if someone actually has some to present. However, the proposer has to specifically request that for a specific proposal and I have to agree to it before it will happen. It is true that several committee members follow the newsgroup and that I make sure that copies of articles from the newsgroup go to appropriate technical reviewers or are mentioned to the committee as a whole. However, they are not presented as proposals: they are presented as comments. They may help committee members understand the context of a topic which is treated in the standards document, but they are unlikely to cause new topics to be added to the document. This is not to say that input from the newsgroup is not useful to the committee. A number of problems with the latest drafts were pointed out in the newsgroup and fixed because of that. The time zone discussion has led to an actual proposal which may be adopted by the committee. Because something is discussed in mod.std.unix does not even necessarily mean that it has anything to do with the P1003 committee. The committee is very aware that they should not be introducing new facilities. It has happened a few times. The only one I can think of at the moment is file locking, specifically the mandatory locking feature of flock (which was actually introduced by the /usr/group committee). This is also, not coincidentally, one of the most controversial things in the current document, even though its proponents only back it because they are convinced it is necessary. You will find things in the draft standard document which do not correspond to your local system, regardless of what your local system is. This is because in the real world there are at least two major variants of UNIX and many minor ones. To pick one and standardize on it alone would be to try to outlaw all the others. This is probably not even possible, even if it were desirable. The committee has chosen instead to try to produce something which is not exactly like anything out there but which can be implemented with relatively minor changes on most existing systems. Ritual disclaimer: this article is constructed of my personal opinions and does not necessarily represent any official position of IEEE, P1003, USENIX, /usr/group, or any other organization. Volume-Number: Volume 7, Number 2
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/28/86)
This article is a slightly adapted copy of an earlier one. There seems to be widespread confusion as to the relation of the newsgroup mod.std.unix (aka the mailing list STD-UNIX) and the IEEE P1003 standards committee and its subcommittees. Allow me to try to clear some of it up. Because something is discussed in mod.std.unix does not mean that it is automatically proposed to P1003 for inclusion in the standard. Proposals to the committee have to be more formal. Especially they have to include specific proposed wording. As it happens, the moderator of the newsgroup is also the USENIX representative to the committee. As such, I am willing to present proposals to the committee if someone actually has some to present. However, the proposer has to specifically request that for a specific proposal and I have to agree to it before it will happen. It is true that several committee members follow the newsgroup and that I make sure that copies of articles from the newsgroup go to appropriate technical reviewers or are mentioned to the committee as a whole. However, they are not presented as proposals: they are presented as comments. They may help committee members understand the context of a topic which is treated in the standards document, but they are unlikely to cause new topics to be added to the document. This is not to say that input from the newsgroup is not useful to the committee. A number of problems with the latest drafts were pointed out in the newsgroup and fixed because of that. The time zone discussion has led to an actual proposal (P.055) which may be adopted by the committee. Because something is discussed in mod.std.unix does not even necessarily mean that it has anything to do with the P1003 committee. The committee is very aware that they should not be introducing new facilities. It has happened a few times. The only one I can think of at the moment is file locking, specifically the mandatory locking feature of flock (which was actually introduced by the /usr/group committee). This is also, not coincidentally, one of the most controversial things in the current document, even though its proponents only back it because they are convinced it is necessary. You will find things in the draft standard document which do not correspond to your local system, regardless of what your local system is. This is because in the real world there are at least two major variants of UNIX and many minor ones. To pick one and standardize on it alone would be to try to outlaw all the others. This is probably not even possible, even if it were desirable. The committee has chosen instead to try to produce something which is not exactly like anything out there but which can be implemented with relatively minor changes on most existing systems. Ritual disclaimer: this article is constructed of my personal opinions and does not necessarily represent any official position of IEEE, P1003, USENIX, /usr/group, or any other organization. Volume-Number: Volume 8, Number 2
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/08/87)
This article is a slightly adapted copy of an earlier one. There seems to be widespread confusion as to the relation of the newsgroup mod.std.unix (aka the mailing list STD-UNIX) and the IEEE P1003 standards committee and its subcommittees. Allow me to try to clear some of it up. Because something is discussed in mod.std.unix does not mean that it is automatically proposed to P1003 for inclusion in the standard. Proposals to the committee have to be more formal. Especially they have to include specific proposed wording. As it happens, the moderator of the newsgroup is also the USENIX representative to the committee. As such, I am willing to present proposals to the committee if someone actually has some to present. However, the proposer has to specifically request that for a specific proposal and I have to agree to it before it will happen. It is true that several committee members follow the newsgroup and that I make sure that copies of articles from the newsgroup go to appropriate technical reviewers or are mentioned to the committee as a whole. However, they are not presented as proposals: they are presented as comments. They may help committee members understand the context of a topic which is treated in the standards document, but they are unlikely to cause new topics to be added to the document. This is not to say that input from the newsgroup is not useful to the committee. A number of problems with the latest drafts were pointed out in the newsgroup and fixed because of that. The time zone discussion has led to an actual proposal (P.055) which may be adopted by the committee. Because something is discussed in mod.std.unix does not even necessarily mean that it has anything to do with the P1003 committee. The committee is very aware that they should not be introducing new facilities. It has happened a few times. The only one I can think of at the moment is file locking, specifically the mandatory locking feature of flock (which was actually introduced by the /usr/group committee). This is also, not coincidentally, one of the most controversial things in the current document, even though its proponents only back it because they are convinced it is necessary. You will find things in the draft standard document which do not correspond to your local system, regardless of what your local system is. This is because in the real world there are at least two major variants of UNIX and many minor ones. To pick one and standardize on it alone would be to try to outlaw all the others. This is probably not even possible, even if it were desirable. The committee has chosen instead to try to produce something which is not exactly like anything out there but which can be implemented with relatively minor changes on most existing systems. Ritual disclaimer: this article is constructed of my personal opinions and does not necessarily represent any official position of IEEE, P1003, USENIX, /usr/group, or any other organization. Volume-Number: Volume 9, Number 2