home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / archive / text0000.txt < prev    next >
Encoding:
Text File  |  1994-03-07  |  15.0 KB  |  344 lines

  1. Submitted-by: sef@uunet.uu.net (Sean Eric Fagan)
  2.  
  3. This is a policy statement for comp.std.unix.
  4.  
  5. This is Volume 33 of comp.std.unix.
  6. These volumes are purely for administrative convenience.
  7. Feel free to continue any previous discussion or to start new ones.
  8.  
  9. Subject: Topic.
  10.  
  11. The USENET newsgroup comp.std.unix, also known as the mailing list
  12. std-unix@uunet.uu.net, is for discussions of standards related to
  13. the UNIX operating system, particularly of IEEE P1003, or POSIX,
  14. including IEEE 1003.1, 1003.2, etc.
  15.  
  16. Other related standards bodies and subjects include but are not limited to
  17.     IEEE 1201 and IEEE 1238,
  18.     ISO/IEC JTC1 SC22 WG15 (the ISO and IEC version of POSIX),
  19.     the U.S. and other Technical Advisory Groups (TAGs) to WG15,
  20.     the X3.159 Programming Language C Standard by the ANSI X3J11 committee,
  21.     ISO/IEC JTC1 SC22 WG14 (the ISO and IEC version of X3.159),
  22.     ANSI X3J16 on the C++ programming language,
  23.     ANSI X3B11.1 on WORM File Systems,
  24.     the National Institute of Standards and Technology (NIST),
  25.     and their Federal Information Processing Standards (FIPS),
  26.     X/Open and their X/Open Portability Guide (XPG),
  27.     the Open Software Foundation (OSF),
  28.     UNIX International (UI),
  29.     the UniForum Technical Committee,
  30.     the AFUU Working Groups,
  31.     PortSoft,
  32.     AT&T System V Interface Definition (SVID),
  33.     System V Release 3, System V Release 4,
  34.     4.2BSD, 4.3BSD, 4.4BSD,
  35.     Tenth Edition UNIX, Plan 9 from Bell Labs,
  36.     Mach, Chorus, Amoeba, GNU,
  37.     and the USENIX Standards Watchdog Committee.
  38.  
  39. Subject: Moderator.
  40.  
  41. The newsgroup comp.std.unix and the mailing list std-unix@uunet.uu.net
  42. is moderated.  The moderator is Sean Eric Fagan.
  43.  
  44. Subject: Disclaimer.
  45.  
  46. Postings by any committee member in this newsgroup do not represent 
  47. any position (including any draft, proposed or actual, of a standard) 
  48. of the committee as a whole or of any subcommittee unless explicitly 
  49. stated otherwise in such remarks.  Postings and comments by the moderator
  50. do not necessarily reflect any person's or organization's opinions.
  51.  
  52. * UNIX is a Registered Trademark of X/Open.
  53. ** IEEE is a Trademark of the Institute for Electrical and Electronics
  54.     Engineers, Inc.
  55. *** POSIX is not a trademark.
  56. Various other names mentioned above may be trademarks.
  57. I hope their owners will not object if I do not list them all here.
  58.  
  59.  
  60. Subject: Postings.
  61.  
  62. Submissions for posting to the newsgroup and comments about the newsgroup
  63. (including requests to subscribe or unsubscribe to the mailing list)
  64. should go to two different addresses:
  65.  
  66.         DNS address            UUCP source route
  67. Submissions    std-unix@uunet.uu.net        uunet!std-unix
  68. Comments    std-unix-request@uunet.uu.net    uunet!std-unix-request
  69.  
  70. In addition to those addresses, I can be reached (electronically) as sef at
  71. either uunet.uu.net, kithrup.com, or cygnus.com (e.g., sef@kithrup.COM).  If
  72. you get a bounce from one of those addresses, or do not get a reply within a
  73. week, send mail to one or more of the others.  For submissions, I prefer
  74. std-unix@uunet.uu.net, as that is where I do the list maintenance.
  75. Permission to post to the newsgroup is assumed for mail to std-unix.
  76. Permission to post is not assumed for mail to std-unix-request,
  77. unless explicitly granted in the mail.  Mail to my personal addresses
  78. will be treated like mail to std-unix-request if it obviously refers
  79. to the newsgroup.
  80.  
  81. The mailing list is distributed on the Internet, UUCP, and elsewhere.
  82. There is a redistribution list on BITNET for BITNET, EARN, and NetNorth.
  83. Please send submissions from those networks to std-unix@uunet.uu.net
  84. nonetheless, because messages sent to the BITNET LISTSERV will not reach
  85. the whole list.
  86.  
  87. If you have access to USENET, it is better (more efficient, cheaper,
  88. less effort for me to manage) to subscribe to the newsgroup comp.std.unix
  89. than to the mailing list.  Submissions should still go to the above
  90. addresses, although many (perhaps most) USENET hosts will forward
  91. attempts to post directly to the newsgroup to the moderator.
  92.  
  93. If you are on the mailing list, and articles are bounced back to me from
  94. your address, you will be deleted from the list, and I will attempt to
  95. get in touch with the administrator for your site, or what looks like your
  96. site, and will reinstate your presence on the list when the problem is
  97. fixed.
  98.  
  99. Posted articles may originate from uunet.uu.net, kithrup.com, or cygnus.com.
  100. There are also occasional guest moderators, who may post from still other 
  101. machines.  Guest moderators are announced in advance by the regular moderator.
  102.  
  103. Subject: Archives.
  104.  
  105. Archives for comp.std.unix or std-unix@uunet.uu.net may be found on UUNET.
  106. Most of them are compressed, so if you don't have compress, get it first
  107. (it's in the comp.sources.unix archives).
  108.  
  109. The comp.std.unix archives may be retrieved by anonymous FTP over the Internet.
  110. Connect to ftp.uu.net with FTP and log in as user anonymous with password
  111. guest.
  112.  
  113. The current volume is in the file
  114.         ~ftp/usenet/comp.std.unix/archive
  115. or
  116.         ~ftp/usenet/comp.std.unix/volume.34
  117. The previous volume, which is compressed, may be retrieved as 
  118.         ~ftp/usenet/comp.std.unix/volume.33.Z
  119. and so forth for more ancient volumes.
  120.  
  121. For hosts with direct UUCP connections to UUNET, UUCP transfer from
  122. host uunet should work with, for example,
  123.         uucp uunet!'~ftp/usenet/comp.std.unix/archive' archive
  124. You will have to put a backslash before the ! (i.e., \!)
  125. if you're using the C shell or bash.
  126.  
  127. The output of "cd ~ftp/usenet/comp.std.unix; ls -l" is in
  128.         ~ftp/usenet/comp.std.unix/list
  129. and the output of "cd ~ftp/usenet/comp.std.unix; ls -l *" is in
  130.         ~ftp/usenet/comp.std.unix/longlist
  131.  
  132. These files are updated rather sporadically; essentially, whenever
  133. I come across this section at the beginning of each volume.
  134.  
  135. For further details, retrieve the file
  136.         ~ftp/usenet/comp.std.unix/README
  137.  
  138.  
  139. Subject: General submission acceptance policy.
  140.  
  141. Submissions are never ignored (although they might be overlooked).
  142. If you don't see your article posted and you don't get a mailed
  143. response from the moderator, your submission probably didn't arrive.
  144. However, travel schedules and other business sometimes intervene
  145. (and for that matter it can take many hours for a submission to
  146. get to the moderator and the posted message to get back to the poster),
  147. so you may sometimes not see anything for a few days.  If you wait
  148. and still don't see anything, try sending again.
  149.  
  150. Although I try to read mail every day, and try to have articles posted
  151. as soon as possible, there are sometimes circumstances which make that
  152. difficult to impossible.  Too much work, flaky networks, and broken
  153. hardware have all, at times, caused me to not be able to post an article
  154. within minutes of it being posted.  Please do not keep resubmitting
  155. your article, as it will only serve to annoy me.
  156.  
  157. As moderator, I reject relatively few articles:  maybe 1 out of 10;
  158. although that amount varies, it is a good rough estimate.  I retain the
  159. right to reject submissions.  If a submission does not appear relevant
  160. to comp.std.unix, it is sent back to the submitter with a note saying
  161. why it is not appropriate.  Usually this is because it just doesn't fit
  162. the topic of the newsgroup, in which case I may suggest another newsgroup.
  163. Sometimes it is because someone else has already given the same answer
  164. to a question, in which case I ask if the submitter really wants it
  165. posted.  Sometimes I reject an article because the information content
  166. it is too low (e.g., twenty-five lines of included text, and a single-
  167. line commanet).  Occasionally I suggest editing that would make an article
  168. more appropriate to the newsgroup.  If a message appears to be directed
  169. towards me, I will reply; if I am unsure, I wil ask the sender if
  170. posting is really necessary or desired.
  171.  
  172. Very occasionally I may reject an article outright:  this will most likely
  173. be because it contains ad hominem attacks, which are never permitted
  174. in this technical newsgroup.  There are many other potential reasons
  175. for rejection, however, such as inclusion of copyrighted material.
  176. Fortunately, most such problems have not come up.
  177.  
  178. Note that while technical postings on technical subjects are encouraged,
  179. postings about the politics of standardization are also appropriate,
  180. since it is impossible to separate politics from standards.
  181.  
  182. Crosspostings are discouraged.  Submissions such as ``how do I find
  183. xyz piece of software'' or ``is the x implementation better than the
  184. y implementation'' that come in for multiple newsgroups usually get
  185. sent back to the submittor with a suggestion to resubmit without
  186. comp.std.unix in the Newsgroups: line.  Sometimes I'll crosspost if
  187. there's clear relevance to comp.std.unix, but I always add a
  188. Followup-To: line in an attempt to direct further discussion to a
  189. single newsgroup, usually comp.std.unix.  This policy is useful because
  190. crossposting often produces verbose traffic of little relevance to
  191. comp.std.unix.  The most common response from me when I reject a submission
  192. is to suggest that it belongs better elsewhere, usually some vendor-,
  193. machine-, or operating system-specific newsgroup.  If you have a technical
  194. question, before posting, it is usually sufficient to ask yourself if
  195. the answer would be sufficient on a single vendor's machine, or if it is
  196. necessary for it to be relevant to many different machines.
  197.  
  198.  
  199.  
  200. Subject: Editorial policy.
  201.  
  202. When posting a submission, I sometimes make changes to it.  These
  203. are of four types:  headers and trailers; comments; and typographical.
  204.  
  205. Headers and trailers
  206.  
  207. Header changes include:
  208. + Cleaning up typos, particularly in Subject: lines.
  209. + Rationalizing From: lines to contain only one address syntax,
  210.     either hosta!hostb!host!user or, preferably, user@domain.
  211.     Very occasionally, this might cause an improper address
  212.     to be generated.  If this occurs, and you think you may
  213.     submit an article again, send me a note, and I will attempt
  214.     to use an address you suggest next time.
  215. + Adding a Reply-To: line.  This usually points to the newsgroup
  216.     submission address in the mailing list, but to the submitter
  217.     in the newsgroup, for reasons too messy to detail here.
  218. + Adding the Approved: line.
  219. + Adding a References: line, if missing.
  220. + Deleting any Distribution: line, as detailed in the next paragraph.
  221.  
  222. The only distribution used in comp.std.unix is no distribution, i.e.,
  223. worldwide.  If it's not of worldwide interest, it doesn't belong in
  224. comp.std.unix.  Anything pertaining to the IEEE/CS TCOS standards
  225. or committees (e.g., IEEE 1003, IEEE 1201), the ANSI X3.159 Programming
  226. Language C Standard (X3J11), or the ISO 9945 POSIX work (ISO/IEC JTC1
  227. SC22 WG15) is of worldwide interest.  If a submission arrives with a
  228. Distribution:  line, such as na or us, I delete that line.
  229.  
  230. Every article has a trailing line of the form
  231. >    Volume-Number: Volume 22, Number 42
  232. This allows the reader to notice articles lost in transmission and
  233. permits the moderator to more easily catalog articles in the archives.
  234. Volumes usually change after about 100 articles, but are purely for
  235. administrative convenience; discussions begun in one volume should
  236. be continued into the next volume.  Due to the way news is transmitted,
  237. articles may appear out of order at some sites if I send out several
  238. at once.
  239.  
  240. Also, signatures that are excessively long may be truncated.  See
  241. Gene Spafford's articles in news.announce.newusers for guidelines on
  242. signatures.  Four lines will generally be considered sufficient,
  243. and I tend to delete any excess white space or ``graphics.''
  244.  
  245. Very long quotations of previous articles are offtimes shortened, and
  246. ``standard'' inclusions indicators of '>' are replaced, if the author
  247. has used some other form.
  248.  
  249.  
  250.  
  251. Subject: Comments
  252.  
  253. Comments by the moderator are sometimes added to clarify obscure
  254. issues.  These are always enclosed in square brackets with the
  255. closing mark ``-mod,'' [ like this -mod ].  Sometimes entire articles
  256. appear that are written by the moderator:  these always end with
  257. a signature that includes the words ``moderator, comp.std.unix.''
  258.  
  259. Comments by the editor of the USENIX Standards Watchdog Reports
  260. sometimes appear in those reports.  Such comments are always
  261. enclosed in square brackets and begin with the word ``Editor:''
  262. [ Editor: like this ].
  263.  
  264. Comments by the publisher of the USENIX Standards Watchdog Reports
  265. sometimes appear in those reports.  Such comments are always
  266. enclosed in square brackets and end with the mark ``-pub,''
  267. [ like this -pub ].
  268.  
  269. Entire articles may appear by the editor or publisher of the
  270. Watchdog Reports, and those are always identified by the signature.
  271.  
  272. Subject: Typographical
  273.  
  274. People submitting articles sometimes enclose parenthetical comments
  275. in brackets [] instead of parentheses ().  I usually change these
  276. to parentheses to avoid confusion with the above conventions for
  277. comments by the moderator, editor, or publisher.
  278.  
  279. Obvious misspellings, such as ``it's'' for the possessive or
  280. ``its'' as a contraction of ``it is'' are corrected (when I notice them).
  281.  
  282. Excess white space is deleted.  (This includes multiple blank lines at 
  283. times.)
  284.  
  285. I don't have any reallly strict policies on formatting, but, in general,
  286. if an article has overly-long lines, or the author has right-justified
  287. the margins, I will run it through fmt(1) before posting it.  See
  288. Gene Spafford's articles in news.announce.newusers for guidelines on
  289. formatting of news articles.
  290.  
  291. Redundant quoted headers are often omitted.
  292.  
  293.  
  294.  
  295. Subject: Common kinds of postings.
  296.  
  297. There are several sets of postings that reoccur in comp.std.unix
  298. at more or less regular intervals.  Here are two of the most common.
  299.  
  300. USENIX Standards Watchdog Reports
  301.  
  302. The USENIX Association sponsors a set of reports after each quarterly
  303. meeting of the IEEE 1003 and IEEE 1201 standards committees.  These
  304. reports are written by volunteers who are already attending committee
  305. meetings and are edited by the Watchdog Report Editor, who is Stephen
  306. E. Walli <stephe@mks.com>.  Reports on other committees, such as X3J11,
  307. are also included when available.  These reports are published in
  308. comp.std.unix/std-unix@uunet.uu.net and ;login:  The Newsletter of the
  309. USENIX Association.  They are also available for publication elsewhere.
  310.  
  311. EUUG/USENIX ISO Monitor Project
  312.  
  313. The European UNIX systems Users Group (EUUG) and the USENIX Association
  314. jointly sponsor an observer to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX)
  315. standards committee.  This observer, Dominic Dunlop <domo@tsa.co.uk>,
  316. writes a report after each WG15 meeting, of which there are usually
  317. two a year.  These reports are published in the EUUG Newsletter
  318. (EUUGN), :login;, and comp.std.unix.  They are also available for
  319. publication elsewhere.
  320.  
  321. Archives of the EUUG/USENIX ISO Monitor Reports, the USENIX Standards
  322. Watchdog Reports, and the Windsound/TIC Calendar of UNIX-Related Events
  323. may be found on ftp.uu.net.  Retrieve ~ftp/usenet/comp.std.unix/README 
  324. for details.
  325.  
  326.  
  327.  
  328. Subject:  Comments
  329.  
  330. Please feel free to send me any comments you might have about my
  331. job as moderator.  The group is meant to be informative and useful, and
  332. you help determine that.  I may still make arbitrary decisions, but
  333. I will probably do less such with some feedback.  In addition, if you
  334. think I am doing a bad job, and not responding to criticisms, you
  335. can post to the news.admin.misc newsgroup, although that may not do
  336. much good.
  337.  
  338. Sean Eric Fagan, moderator, comp.std.unix and std-unix@uunet.uu.net.
  339.  
  340.  
  341.  
  342. Volume-Number: Volume 34, Number 1
  343.  
  344.