Network Working Group Kent Landfield Request for Comments: XXXX Category: Informational Sometime 1995 Usenet Sources Newsgroup Moderation Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This memo provides information concerning moderation of Usenet source newsgroups. These groups exist to distribute publicly available software packages in source code format to the Usenet community. This memo describes the format and usage of articles posted to such newsgroups. The goal of this document is to explain the practices currently in use for the benefit of new and existing moderators, implementors of automated software archivers, as well as the general Usenet news readership. This RFC documents a de-facto standard in use within the Usenet community. Table of Contents 1. Introduction ............................................... 4 2. History of Sources Moderation .............................. 4 2.1. comp.sources.unix ........................................ 5 2.2. comp.sources.games ....................................... 5 2.3. comp.sources.misc ........................................ 5 2.4. comp.sources.atari.st .................................... 5 2.5. comp.sources.mac ......................................... 6 2.6. comp.sources.amiga ....................................... 6 2.7. comp.sources.x ........................................... 6 2.8. comp.sources.sun ......................................... 6 2.9. comp.sources.apple2 ...................................... 6 2.10. comp.sources.3b1 ......................................... 6 2.11. comp.sources.hp48 ........................................ 7 2.12. comp.sources.acorn ....................................... 7 2.13. comp.sources.reviewed .................................... 7 Landfield [Page 1] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 2.14. comp.sources.postscript .................................. 7 3. Definitions. .............................................. 7 4. Type of Issues ............................................. 8 4.1. Informational Postings (INF) ............................. 8 4.2. Source Postings .......................................... 9 5. Issue Format ............................................... 9 5.1. Standard News Header Usage ............................... 9 5.1.1. Subject Line ........................................... 9 5.1.1.1. Volume-Issue Section ................................. 9 5.1.1.2. Topic Section ........................................ 10 5.1.2. From Line .............................................. 11 5.1.3. Newsgroups Line ........................................ 11 5.1.4. References Line ........................................ 12 5.1.5. Reply-To Line .......................................... 12 5.1.6. Keywords Line .......................................... 12 5.1.7. Summary Line ........................................... 12 5.1.8. Organization Line ...................................... 12 5.2. Auxiliary Header Lines ................................... 13 5.2.1. Mandatory Auxiliary Header Lines ....................... 13 5.2.1.1. Submitted-by ......................................... 13 5.2.1.2. Posting-number ....................................... 13 5.2.1.3. Archive-name ......................................... 14 5.2.1.4. Patch-To ............................................. 15 5.2.2. Optional Auxiliary Header Lines ........................ 16 5.2.2.1. Supersedes ........................................... 16 5.2.2.2. Environment ........................................... 17 5.3. Article Validation Headers ............................... 17 5.3.1. X-Md4-Signature ........................................ 18 5.3.2. Checksum ............................................... 18 6. Handling Patches ........................................... 18 6.1. Maintenance .............................................. 18 6.2. Official Patch Distribution .............................. 19 6.3. Unofficial Patches ....................................... 19 7. Dealing With Posting Errors ................................ 19 7.1. Reposting Articles ....................................... 19 7.2. Duplicate Volume-Issue Identifiers ....................... 19 8. Newsgroup Policy Concerns ................................. 20 8.1. Posting Format .......................................... 20 8.2. Size of Individual Issues ............................... 20 8.3. Number of Issues to be Posted Daily ..................... 20 8.4. Number of Issues Per Volume ............................. 21 8.5. Verifying Submissions ................................... 21 8.6. Posting Information of Short Term Interest .............. 21 8.7. Backup or Co-moderator .................................. 22 8.8. Moderator Absences ...................................... 22 8.9. Non-Source Submissions .................................. 22 8.10. Requests For Previously Posted Issues ................... 23 9. Copyrights ................................................. 23 Landfield [Page 2] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 10. Acknowledgments ............................................ 24 11. Security Considerations .................................... 24 12. References ................................................. 24 13. Author's Address ........................................... 24 Landfield [Page 3] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 1. Introduction The purpose of this RFC is to provide a documented approach for moderating Usenet source newsgroups. This RFC describes the overall structure of the articles, the use of individual RFC 1036 [1] headers as applicable, as well as Usenet source newsgroup Auxiliary header lines. This RFC acts as a guide to moderation by giving moderators some general principles and practices to follow. It documents moderation practices that have become a de-facto standard within the Usenet community. This RFC also serves to document the process for archivers. Software packages posted to the newsgroups are a valuable international resource. By documenting how software packages are posted and in what form the postings take, more advanced source archivers and source retrieval software tools can be developed and deployed. 2. History of Sources Moderation Source distribution began on Usenet with two different groups, net.sources and net.sources.d. Both groups were unmoderated with net.sources used for posting actual source code and net.sources.d meant for discussion postings. The number of non-source postings appearing in net.sources began to increase. At the time there were no moderators on the net. Discussions began as to how to moderate newsgroups in general. The "mod" hierarchy was created to deal with the problem and the code needed to support moderation was added to the news software running on the backbone systems. Shortly after that, John Nelson volunteered to moderate a newsgroup dedicated to posting only source code with no discussion. Mod.sources was the beginning of moderated source distribution. Not long after Rich Salz took over as moderator of mod.sources, Rick Adams proposed and directed a major restructing of the newsgroup hierarchies. The "Great Renaming" combined the "net.*" and "mod.*" hierarchies into the more extensible "comp.*" hierarchy existing today. The "Great Renaming" saw the following source groups combined and renamed. mod.sources comp.sources.unix mod.amiga.sources comp.sources.amiga mod.sources.games comp.sources.games net.sources.games comp.sources.games net.sources.mac comp.sources.mac net.sources comp.sources.misc The following briefly describes a history of moderators for each of the comp.sources.* newsgroups. Landfield [Page 4] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 2.1. comp.sources.unix The initial moderator of what is today's comp.sources.unix was John Nelson. The first issue to mod.sources was posted January 8, 1985. John was the moderator for the first 5 volumes. During Volume 6, moderator duties were passed to Rich Salz. Rich began posting to mod.sources July 6, 1986. Rich was responsible for setting up most of the basic structure of source moderation as it appears in this document. As new source newsgroups formed, Rich passed his posting software to the new moderators in an attempt to maintain some standard way of posting "sources". In November 1991, after posting through Volume 24, Rich decided it was time to pass the mantel to another. Paul Vixie volunteered to take over along with Mike Stump and Nick Lai so that there would be three people working on the group. 2.2. comp.sources.games Although Rich Salz had created mod.sources.games and was the first official moderator (along with his other duties in mod.sources), his first task was to find a seperate moderator for the games group. Rich never posted anything to m.s.g. He passed the "moderatorship", along with a tape of games, to Bill Randle. Bill started posting to mod.sources.games on April 17, 1987. He was the first (and only) person to post to the group. When the "Great Renaming" occurred, comp.sources.games was created by combining the moderated m.s.games and non-moderated newsgroup net.sources.games. 2.3. comp.sources.misc The moderated comp.sources.misc replaced the unmoderated net.sources in May 1987. This was done by the Usenet backbone in response to the fact that net.sources was largely non-sources. Rich Salz suggested the creation of a moderated sources group that did no testing of software as mod.sources did, just filter out discussion posting. Dis- cussions on the net at the time indicated that the majority of people were willing to trade the small delays for having a source group that wasn't full of noise. The initial moderator of was Brandon Allbery. Brandon posted the first 15 volumes and in December 1991, he passed the responsibilities to Kent Landfield. 2.4. comp.sources.atari.st The group was created in March of 1988 ?? __________ was the group's first moderator. Shortly after however, Steven Grimm took over as moderator. The group had not been archived in any organized way. Landfield [Page 5] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 Steve reset the volume and issue numbers to prevent later confusion. He was the group's moderator from March 1988 until December 1993. Annius Groenink took over as moderator and began posting at the start of volume 7. 2.5. comp.sources.mac This group began as the unmoderated net.sources.mac newsgroup. Dur- ing the "Great Renaming", the group comp.sources.mac was created with Roger L. Long as its moderator. The group saw its first posting in May of 1988. 2.6. comp.sources.amiga Pat White and Brent Woods began posting to comp.sources.amiga as co- moderators on June 23, 1988. Rob Tillotson also helped as needed during the early days of the newsgroup. Bob Page then took over the moderator duties of comp.sources.amiga at Volume 2 in October 1988. Before beginning to post to the group's third volume, Bob decided volumes should be based on the year instead of sequentially numbered starting at 1. There was a jump in the archives from Volume 2 to Volume 89. Tad Guy took over at Volume 90 as the moderator. Volume 92 saw another change in moderator as Michael Dinn took over. 2.7. comp.sources.x Mike Wexler started posting August 8, 1988. During Volume 3, Mike passed the job Dan Heller. Dan began posting March 28, 1989. When Dan decided to take a break to write a book in September 1989, he asked Kent Landfield to step in and be moderator in a temporary capa- city. Dan returned in February of 1990 and continued posting until February 4, 1992 when David C. Martin took over in Volume 15. David continued posting until March 3, 1993. Starting with Volume 19, Chris Olson became the group's moderator. 2.8. comp.sources.sun Charles McGrew has been comp.sources.sun's only moderator since its creation in May 1989. 2.9. comp.sources.apple2 Jonathan A. Chandross has been comp.sources.apple2's only moderator since its creation in November 1990. 2.10. comp.sources.3b1 David H. Brierley has been comp.sources.3b1's only moderator since Landfield [Page 6] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 its creation in February 1991. 2.11. comp.sources.hp48 Chris Spell has been comp.sources.hp48's only moderator since its creation in August 1991. 2.12. comp.sources.acorn The first postings appeared January 15, 1992 with Philip Colmer as moderator. In Volume 2, Jason Williams and Edouard Poor took over as co-moderators of the group comp.sources.acorn. Peter Gutmann replaced Jason Williams in July of 1993. 2.13. comp.sources.reviewed Andrew Patrick fostered a different type of sources group and on April 11, 1991 became its first moderator. comp.sources.reviewed was created for the distribution of sources that had been subjected to a Peer Review process. Similar to the process used for academic jour- nals, submissions are sent to a moderator who then sends the sources to Peer Review volunteers for evaluation. The reviewers provide a documented evaluation of the software. If the moderator and reviewers judge a submission to be acceptable, the sources are posted along with the comments provided by the reviewers. In February 1993, starting with Volume 3, Kevin Braunsdorf took over as the group's moderator. In April of 1994, David Boyd became the group's third moderator. 2.14. comp.sources.postscript Jonathan Monsarrat has been comp.sources.postscript's only moderator since its creation in April 1993. 3. Definitions. Issue - A individual article posted to a moderated sources newsgroup. Maintainer - A software package maintainer is either the initial author or someone designated by the author to be responsible for maintaining the software. Moderator - The person who is recognized as responsible for the accurate and timely postings of software packages which meet the newsgroup's guidelines. Newsgroup - For the purpose of this RFC, the use of the term newsgroup is to mean a moderated Usenet sources newsgroup. Landfield [Page 7] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 Patch - A program initially written by Larry Wall that allows for the easy distribution and installation of software fixes in the form of diffs. Patches - Input to the patch program that is intended to correct a bug or extend the features of a software package. Official patches - Patches that are issued by the maintainer and are so designated by the maintainer. Only the maintainer should issue official patches to the previously posted software. Volume - A volume is a grouping of posted articles stored on disk normally in directories named volumeNN. NN is the moderator assigned volume number. An issue's volume number is specified in the Posting-number: Auxiliary header line described below. 4. Type of Issues There are two different types of issues that a moderator can post to the newsgroup, informational postings and source code postings. The informational postings are administrative in nature while the source postings are the reason for the newsgroup's existence. 4.1. Informational Postings (INF) INFormational postings are moderator generated postings that inform the community of aspects of moderation and archiving pertaining to the newsgroup. INF postings can be regular postings or they can be correctional in nature. When a new volume is created the moderator should post a set of informational postings specifying the newsgroup's general policy, a list of newsgroup archive sites, an index of all previously posted issues and a cross index of patches that have been previously posted to the newsgroup. The policy INFormational posting should include information describing the use of any additional Auxiliary header lines, how articles should be submitted, how patches will be handled, how to become an archive site as well as general guidelines used by the moderator in performing the responsibilities as the newsgroup's moderator. Numbering of INF postings is sequential and independent of source issue numbering. Moderators have, in the past, used a variety of Archive-names to name INF postings on disk. INF postings should have meaningful Archive-names, not /dev/null, .junk or other equally use- less names. Landfield [Page 8] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 4.2. Source Postings Source postings are articles that either contain the actual source code package to be distributed or an expanded description of a subse- quent package. Source postings should include a description or `blurb' that indicates what the program is, why a reader would want to run it, as well as other relevant details. Most of the time it's included directly after the Auxiliary headers in part01 whether or not the package being posted is a single or multi-part posting. In some cases it may be appropriate to post the blurb in an expanded format as the contents of part00. In either case, the blurb need only be included in the first part posted. The blurb is important because users tend to skip over programs without a blurb unless the title sounds truly interesting. 5. Issue Format Issues posted to a sources newsgroup consists of three different sec- tions: the RFC 1036 compliant news headers, moderator supplied Auxi- liary headers and the actual text of the posted issue. Each section is separated from the next by a line containing a single newline. 5.1. Standard News Header Usage Issues posted to moderated source newsgroups are to conform to the news article specifications in RFC 1036 which describes the Usenet news system. The following supplements RFC 1036 by describing the content of the applicable headers as they pertain to moderating Usenet source newsgroups. 5.1.1. Subject Line The Subject line is divided into two sections, the volume-issue sec- tion and the topic section. 5.1.1.1. Volume-Issue Section The volume-issue section format is divided into two different parts, the volume indicator and the issue indicator. The volume indicator is the character "v" followed by digits indicating the volume of which the article is a part. The digits are padded with leading zeros to a minimum of two places. The issue indicator is used to indicate whether the article is a source posting or an INFormational posting. Subject: v01i001: greatgame - Some great game, Part01/01 ^^^^^^^ Landfield [Page 9] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 For a source posting, the source issue indicator is the character "i" followed by digits indicating the issue number for the article, pad- ded with leading zeros to three places. Source posting Volume-Issue name syntax: v[0-9][0-9]i[0-9][0-9][0-9] For an informational posting the issue indicator is the three charac- ters "INF" followed by digits indicating the informational issue number for the article. Informational posting Volume-Issue name syntax: v[0-9][0-9]INF[0-9] 5.1.1.2. Topic Section The topic section consists of the package name and a package descrip- tion separated by a dash such as: Subject: v01i001: greatgame - Some great game, Part01/01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ A comma has been used in some newsgroups in place of the dash. There is also an optional, informational section of the Subject line. This section is used to alert the reader that the article is a part of a multi-part posting or the article is a patch. For Multi-part source postings a ", Partnn/NN" is appended to the Subject line. If a pack- age is a single part posting, the use of ", Part01/01" is optional. If the posting is a patch, the topic section also has ", Patchnn" on the Subject line as an indication that the article is a patch to existing software. Although most archivers do not and should not make use of the Partnn/NN and Patch information, they are useful for the user when reading news or searching Subject lines of articles within an archive. Source Posting: Subject: v01i001: greatgame2 - Another great game, Part01/01 Single part Patch Posting: Subject: v01i007: greatgame2 - Another great game, Patch01 When dealing with multi-part patch postings it is necessary to give an indication of the number of parts. This is depicted as is shown below. Landfield [Page 10] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 Multi-part patch Posting: Subject: v34i107: package - Neat software, Patch01a/5 This indicates that this issue is the first part, part "a", of a five part posting. All five parts make up the first patch designated as Patch01. The use of "a out of 5" is a recognized inconsistency, but meets the convention that each part of a multi-part posting is numbered. There is an additional use of the Subject line in regards to repost- ings articles. This is discussed later. 5.1.2. From Line In order to make it easier for the community to contact authors of posted packages, the moderator should assure articles can be replied to from within news readers. There are two ways to do this: o The moderator assures the From: line in posted issues contains the electronic mail address of the submitter. This usually involves assuring the From: line matches the contents of the Auxiliary header line Submitted-by described below. o If the moderator wishes to place their own address in the From: line, then the moderator assures that a Reply-To: is present which contains the email address of the person submitting the package. It is recommended that the moderator put the submitter's address in the From: line. Since news readers display From: line information, it is more appropriate to accurately depict who the package is "From". 5.1.3. Newsgroups Line If a submitter requests the moderator to cross post an article to multiple groups, the moderator should try to comply as long as the other groups are not moderated. If one or more of the other requested groups are moderated, the moderator should either coordi- nate with the moderator(s) of the other group(s) or inform the sub- mitter that the article is being cross posted to only newsgroups that are not moderated. Due to the nature of some existing news software, an article cross posted by a moderator to multiple moderated news- groups appears in all the specified moderated groups without requir- ing the further approval of the other moderator(s). A posting of this type will probably surprise and may even anger the other moderator(s) if the article posted violates the charter of the other Landfield [Page 11] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 moderated newsgroup(s). 5.1.4. References Line In the case of multi-part postings, the second and subsequent parts should include a References: header. This header is used by threaded newsreaders to chain a set of articles together. This allows the package to be dealt with as a unit. There are two ways to deal with the References header. o The References header contains the Message-ID of the first part of the series (or package). The References header should only list the Message-ID of the first part posted and need not list all the intermediate parts. o The References header only contains the Message-ID of the part posted immediately prior (e.g putting part N-1's Message-ID in in part N's References header). The method selected is purely a matter of aesthetics. By using this header, threaded news readers will present each multi-part posting as a single item to the user making it much easier for them to read. NOTE: Another way of linking articles is to list the Message-ID of every part. This is not recommended as it just increases the size of the articles without adding additional information and utility. 5.1.5. Reply-To Line Although not required, if a submission received by the moderator con- tains a Reply-To: header line, the moderator should include the header line in the posted article. 5.1.6. Keywords Line Although not required, if a submission received by the moderator con- tains a Keywords: header line, the moderator should include the header line in the posted article. 5.1.7. Summary Line Although not required, if a submission received by the moderator con- tains a Summary: header line, the moderator should include the header line in the posted article. 5.1.8. Organization Line Although not required, if a submission received by the moderator Landfield [Page 12] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 contains an Organization: header line, the moderator should include the header line in the posted article. 5.2. Auxiliary Header Lines Source newsgroup moderators have established additional headers whose sole purpose is to support the posting of source code. These Auxili- ary headers do not appear in the RFC 1036 "News" header section of an article. Instead they are the first lines of the article text separated from the news headers by a single line containing a new- line. 5.2.1. Mandatory Auxiliary Header Lines There are four Auxiliary headers that are in general use and shall be supported. Here is an example of their use. Submitted-by: root@freeware.ATT.COM (Root User) Posting-number: Volume 7, Issue 82 Archive-name: greatgame/part01 Patch-To: greatgame: Volume 22, Issue 122,125-127 5.2.1.1. Submitted-by The Submitted-by: header contains the contact information of the maintainer who submitted the sources to be posted. The Submitted-by line consists of two sections, the electronic mailing address in Internet syntax and the full name of the submitter. The electronic address should be in domain form whenever possible. Otherwise, the bang patch should be relative to some major site. There are two acceptable forms in which the information can be supplied: Submitted-by: email-address (user-full-name) Submitted-by: user-full-name The full name may appear in parentheses after the electronic mail address of the person submitting the package, or it may appear before the electronic mail address enclosed in angle brackets. The following are examples of the Submitted-by line. Submitted-by: Kent Landfield Submitted-by: kent@landfield.com (Kent Landfield) 5.2.1.2. Posting-number The Posting-number: header is used by the moderator to assign the issue's volume and issue numbers. This header is used to officially Landfield [Page 13] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 specify the volume-issue information. In the unlikely event that volume-issue information on the Subject: line and that specified in the Posting-number: header do not agree, the Posting-number: header shall be considered authoritative. Source posting syntax: Posting-number: Volume NN, Issue n INFormational posting syntax: Posting-number: Volume NN, Info n In the past, the word "Administrivia" has been used instead of "Info" to indicate an INFormational posting. Such use is discouraged. 5.2.1.3. Archive-name The Archive-name is the official name of a source package in the archive. There are a couple of items to consider when choosing an Archive-name for a posting. The moderator must consider the length of the selected name. Because there are still systems that have fourteen character filename limits, it is important to assure the name of any single directory component of the Archive-name is limited to fourteen characters. The base filename specified in the Archive- name must be limited to at most eleven characters. This assures site archive administrators have the space in the file names to allow for compression of the archive members. The second item to consider is the method that archivers are going to use in storing the posting. There are two different methods of storing source postings in archives that have been used in the past. o If the posting is a single part posting, it is stored directly in the volume directory. If the posting is a single part patch, it is also stored in the volume directory. If the posting is a multi-part posting, its stored in a subdirectory located in the volume directory. o Store all source postings as multi-part postings. Both single and multi-part postings are stored in a subdirectory located in the volume directory. For initial postings, the base file name is "part". For patches, the base file name is "patch". Both "part" and "patch" are in lower case. Although both methods are quite workable, the first method forces the moderator to do more work having to think up ways to name patches for existing single part postings. It also limits the number of Landfield [Page 14] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 characters that the moderator can use in specifying an Archive-name for the posting. By using the second method, the moderator can use all fourteen characters for the filename since the Archive-name is the name of a directory. In this case, reserving two characters for file compression suffixes is not a consideration. The second method also allows the naming to be more consistent in that the directory name used in the initial posting is the same for a patch posting. In this way, the moderator has a place to store a patch in a manner consistent with the initial posting. Initial source posting syntax: Archive-name: rkive/part01 Patch posting syntax: Archive-name: rkive/patch01 Note the numbers used in the initial posting and the patch posting are zero padded to a minimum of two digits. This makes it easier to quickly see if all the parts are available on an archive using tools such as ls or lc. In the event that the issue is an individual piece of a multi-part patch posting, the alphabet is to be used to indicate the sequence of the issue. The example below depicts the first post- ing in a multi-part patch. Archive-name: package/patch01a Lastly, the names used for Archive-names should be in lower case. This is due to some mail based archive retrieval software that is in widespread use. 5.2.1.4. Patch-To To support the tracking of patches, the Patch-To line is used. The Patch-To line exists only for articles which are patches to previ- ously posted software. Initial postings do not contain the Patch-To Auxiliary header line. Patch-To: syntax Patch-To: package-name: Volume X, Issue x[-y,z] Below are two sets of Auxiliary headers. The first example shows the headers as they would appear in the initial posting of the software to the newsgroup. The second example shows the Auxiliary headers as they would appear for a patch that is about to be posted. Note the addition of a Patch-To line which acts as a reverse reference Landfield [Page 15] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 pointing back to the initially posted article or set of articles. Auxiliary Headers For Initial Postings: Submitted-by: Kent Landfield Posting-number: Volume 17, Issue 17 Archive-name: rkive/part01 Auxiliary Headers For Patch Postings: Submitted-by: Kent Landfield Posting-number: Volume 99, Issue 14 Archive-name: rkive/patch01a Patch-To: rkive: Volume 17, Issue 17-22 The 17-22 in the Patch-To line indicates the patch applies to a multi-part posting. The '-' is used to mean "article A through article B, inclusive. In the next example, the article that contains the following line is a patch to a single part posting. Patch-To: ls: Volume 76, Issue 71 If a patch applies to a multiple part posting that is not consecu- tive, the ',' is used to separate the part issue numbers. It is pos- sible to mix both ',' and '-' on a single Patch-To line. Patch-To: greatgame2: Volume 22, Issue 122,125,126,127 or Patch-To: greatgame2: Volume 22, Issue 122,125-127 There should be only one Patch-To header per posted issue. 5.2.2. Optional Auxiliary Header Lines The moderator can establish additional Auxiliary header lines if deemed necessary to better facilitate the distribution and use within their specific newsgroup. What follows is not a complete list of optional Auxiliary headers but sample of optional headers currently in use across multiple comp.sources newsgroups. 5.2.2.1. Supersedes If a new release is posted instead of a large set of patches, the new posting should contain a Supersedes line with a format similar to the Patch-To header. The Supersedes line lets the community know that this is a complete replacement of an earlier version of the package. Landfield [Page 16] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 It is also helpful for cleaning archives by providing archive administrators with a pointer to the previous version that can be removed from their archives. Supersedes: syntax Supersedes: package-name: Volume X, Issue x[-y,z] Supersedes: example Supersedes: greatgame2: Volume 22, Issue 122-127 In the event that an article is posted to the same volume that it is to supersede, the Archive-name of the superseding article should con- tain the version number to differentiate it from the initial posting in that volume. If the superseding article is posted to a subsequent volume then the Archive-name should be the same as the article that it supersedes unless told different by the software's maintainer. 5.2.2.2. Environment The Environment Auxiliary header line can be used by moderators to give their readership a quick indication of the environment or resources required to use a particular issue. Environment: syntax Environment: Keyword [, keyword ..] Environment: example Environment: SunView, XView, X11R4, termcap The keywords' usage is case insensitive. There is also a NOT indica- tor (e.g., !AIX) so that the moderator can specify that the package does not work on the specified keyword. The news Keywords line has been used for this, but news headers often don't get saved with the article. 5.3. Article Validation Headers One problem for archivers and news readers in the past has been detecting corrupted postings. A solution to this problem is through the use of some sort of checksum mechanism. MD4 as specified in RFC 1186, "The MD4 Message Digest Algorithm", can be used to detect arti- cle corruption and tampering. It is recommended that an article validation mechanism be used to assist archive sites improve the integrity of the articles contained within their archives. It is expected that article validation methods will follow the lead of the Privacy Enhanced Mail developments. Landfield [Page 17] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 5.3.1. X-Md4-Signature MD4, as specified in RFC1186, can be used to apply a fingerprint on an article posted to Usenet. When run through a verification tool, MD4 will tell whether an article has been corrupted. The use of MD4 does not detect or prevent the complete replacement of an article. Think of MD4 as a super-strong checksum. The header X-Md4-Signature contains the value that will be checked against to determine if the article is intact. An example X-Md4-Signature line using MD4 is shown below. X-Md4-Signature: b0000a78df894269abd0188fa3537090 5.3.2. Checksum The Checksum header is another header used for article verification. The header has two parts, the actual sum value and an informational section in parenthesis that lets the user know what to use to do the actual article verification. An example appears below: Checksum: 2571181954 (verify with brik -cv) 6. Handling Patches Patches should be handled as swiftly as possible. Authors of sources posted to the newsgroups should be encouraged to send all patches to the newsgroup moderator so that they can be posted back through the newsgroup in order that the patches can be archived. This has not been done consistently in the past in some sources groups and has lead to lost patches. If the patches must get out real fast, the authors should post them to the appropriate bugs newsgroup (e.g. comp.sources.bugs or comp.sources.games.bugs) and send the moderator a copy at the same time so that they will be available when they are needed in the future. The moderator should convey this to the authors via the newsgroup policy posting at a minimum. Subject: v01i007: greatgame2 - Another great game, Patch01 6.1. Maintenance It is not the moderator's responsibility to maintain software posted through the moderator's newsgroup. 6.2. Official Patch Distribution All distribution of patches should be made in patch format. In other words, the patches should be in acceptable diff format so that the Landfield [Page 18] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 patches can be applied using the patch program. When official patches are received by the moderator from the recognized software maintainer, they are to be posted to the newsgroup with the appropri- ate indication that the posting contains a patch. 6.3. Unofficial Patches When patches are sent to the moderator from other than the software maintainer, the moderator should forward the suggested patches to the software maintainer. Only official patches should be posted to the newsgroup. 7. Dealing With Posting Errors If an error is made in posting an article to the newsgroup, the com- munity should be made aware of the error as soon as it is discovered or reported to the moderator. The moderator should post an INForma- tional message to the newsgroup indicating the type of the problem and if possible, describe a resolution to the problem. Problems that have occurred in the past include duplicate Volume-Issue identifiers, holes in Volume-Issue identifiers, truncated articles posted, propa- gation problems and multiple postings of the same article. 7.1. Reposting Articles Sometimes it is necessary to repost an issue. It is up to the moderator to decide when this is appropriate. Some common reasons a moderator might decide to repost an issue are a lack of article pro- pagation, a truncated news article, or a submitter error. When the moderator has deemed it appropriate to repost an issue, the moderator should assure that "REPOST:" is placed on the Subject line. An example is shown below. Subject: REPOST: v01i001: greatgame - Some great game, Part01/05 The moderator should assure the Archive-name header information is consistent with the initial posting. In this manner, source archivers using Archive-name archiving will be able to deal with the reposted issue correctly. 7.2. Duplicate Volume-Issue Identifiers If the moderator discovers that multiple articles have been posted with the same Volume-Issue identifiers, the moderator should correct the problem by assigning an unused Volume-Issue identifier to the duplicate article. An INFormational message should be posted to the Landfield [Page 19] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 newsgroup to alert sites that archive the newsgroup that they need to be alerted to the correction in the Volume-Issue identifiers. It may also be necessary to repost both the initial issue, that had the ini- tial Volume-Issue identifier, as well as the issue with the corrected Volume-Issue identifier. This becomes necessary since sites that store issues by Volume-Issue may have had the original issue overwritten by the second, incorrect numbered issue. 8. Newsgroup Policy Concerns The following are items that a moderator should be aware of and in some cases, should follow, in order to better assist the community the newsgroup is serving. 8.1. Posting Format The moderator should pick a posting format and stick with it. Most often the submissions are posted in shell archive format using shar or cshar to bundle up the files. Shell archive is the recommended format as its contents are readable from within a newsreader. Some groups have chosen to post files in a uuencoded format due to con- cerns associated with the architecture of the system the sources are targeted for. In either case, the moderator should assure that the format is acceptable with their readership and then stick with it. 8.2. Size of Individual Issues Individual postings should be less that or equal to 60K. If it is necessary to split the posting into multiple parts, each part should be less that or equal to 60K. This is due to the architecture res- trictions of some older systems. This restriction is more in the minds of the users on the net than the software running it. Postings of 90K successfully make it through most present day news systems. Many mail systems have limitations of 100K on messages that pass through them. This is a concern because there are news to mail gate- ways that deliver and post news via electronic mail. 8.3. Number of Issues to be Posted Daily Very often a moderator is faced with posting a package that has a large number of parts to it or feels in a hurry to "flush" the queue of articles awaiting posting. The moderator should limit the number of bytes that get posted in a twenty-four hour period. Normally 500 to 800K can be posted at a time without flooding news directories. Please keep in mind that some people run news with extremely limited news spool directories. 8.4. Number of Issues Per Volume Landfield [Page 20] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 There are generally between 100 and 150 issues in a volume. This division is arbitrary but has been used in most newsgroups in the past to limit the size of any one individual volume. 8.5. Verifying Submissions How a moderator verifies submissions prior to posting depends greatly on the charter of the newsgroup. Some groups do a large amount of testing while others don't. At a minimum, moderators should ask themselves the following questions about a submission prior to post- ing the package. o Does it unpack without problems or should it be re-packaged by the moderator? o Is there a copyright that could interfere with the right to distribute ? o Does the requested Archive-name conflict with an existing package by a different author ? o If its a patch, does the community have general availability to the sources that the patch is to be applied to ? o If its a patch, does it patch correctly without problems ? o Does the submission contain an individual line longer than 512 bytes which might be truncated by the NNTP reference servers ? o Does the submission contain unprintable characters that may make it through the mail systems but not the news systems ? o Does the posting contain long filenames that might get truncated during unpacking on some systems without long filenames. 8.6. Posting Information of Short Term Interest Postings that describe temporary situations should be posted to a discussion newsgroup consistent with the user community which the moderated sources group supports. The moderator should specify which discussion group is to be used for short term informational postings in the policy INF posting. It is also recommended the moderator cross post articles of this type to the newsgroup comp.sources.d and any other newsgroups the moderator considers appropriate. Postings such as "I will be out of town..." and "What's in the queue to post..." have been posted to moderated source newsgroups in the Landfield [Page 21] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 past. Postings such as these are inappropriate INF postings due to the extremely limited amount of time information of this type is use- ful. Postings such as "Submission Address Changing" or "I'll be posting from a new host" would not be considered short term as they affect how the group is being run. By avoiding posting articles of short term interest to an archived sources group, the moderator allows the news expire functionality to correctly handle short term informational messages. Put another way, informational postings to discussion newsgroups will expire as they should and won't be archived taking up disk space forever on systems worldwide. 8.7. Backup or Co-moderator It is recommended the primary moderator locate a backup moderator to assist as needed. This is more an insurance policy by having someone to fill in for them temporarily. It is easy to need some time off from moderator responsibilities due to work schedules and having a backup moderator assures the newsgroup's continuity during those potential periods. 8.8. Moderator Absences In the event that a moderator is not able to perform the duties of the moderator for some small length of time, such as a vacation, the moderator should inform the community by posting to comp.sources.d, and any other interested newsgroup, that there will be a delay in posting articles. It is not necessary to give a reason for the delay. If a moderator finds that they will be unable to perform their duties for a more extended period of time, they should allow the backup moderator to assume posting responsibilities until the primary moderator is able to once again assume the responsibilities of posting to the newsgroup. In this manner, articles and patches submitted can to be posted to the newsgroup in a timely fashion and the newsgroup continues to be a resource the Usenet community can depend on. 8.9. Non-Source Submissions When a non-source posting is submitted to the newsgroup, the modera- tor should send the submitter email informing the sender that their submission was inappropriate for posting to a moderated sources news- group. If possible, suggest a newsgroup where the posting might be appropriate. Forwarding a canned message such as the one that fol- lows is appropriate. "I am sorry but I am unable to post your request to the Landfield [Page 22] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 newsgroup comp.sources.misc. This newsgroup is a moderated newsgroup whose sole purpose is for the distribution and archiving of source code. Requests for software can be made to to comp.sources.wanted or a more specific newsgroup if one exists. Requests for help with the sources gathered from the net should be made to the newsgroups comp.sources.d or comp.sources.bugs depending on the type of the problem." 8.10. Requests For Previously Posted Issues There are numerous FTP and email archive sites available to the com- munity. Moderators need not feel that it is their responsibility to take the time and potential expense needed in satisfying requests for previously posted issues. If the moderator makes it a policy to not send sources on request, the moderator should at least point the per- son making the request in the right direction. Forwarding a canned message like the one that follows is appropriate. "Past issues of comp.binaries.amiga and comp.sources.amiga are archived on ab20.larc.nasa.gov. These archives are available via anonymous ftp in the directories /usenet/comp.binaries.amiga && /usenet/comp.sources.amiga If you don't have direct access to the Internet, you can still retrieve back issues of comp.binaries.amiga by using a mail-based archive server such as BITFTP (available only to BITNET-connected sites), and FTPMAIL (available to everyone). Send the word ``help'' in a mail message to BITFTP@PUCC or FTPMAIL@DECWRL.DEC.COM (whichever is appropriate) for help." 9. Copyrights Software that has organizational copyrights should not be posted without a release from the appropriate release authority. For the most part, copyrights are attached by the authors granting the com- munity certain rules such as: "Permission is hereby granted to copy, distribute or otherwise use any part of this package as long as you do not try to make money from it or pretend that you wrote it. This copyright notice must be maintained in any copy made." If the moderator has any question concerning the legality of posting a piece of software, the moderator should not post the software until Landfield [Page 23] RFC XXXX Usenet Sources Newsgroup Moderation Sometime 1995 appropriate permissions and assurances are received by the moderator. There should be no "compilation copyright" placed on the sources newsgroup by the moderator. The newsgroups are a collective effort, the result of the sites that pass the newsgroup around, the kind souls that maintain archives, those who improve the code that is pub- lished through the newsgroup, and - most importantly - the people who write the code. Please note, in no way can a moderator supplied copyright notice supersede the copyright that the individual posters have attached. 10. Acknowledgments Sections of the text in this document are based on and taken from the "info" postings written by Rich Salz in the early 1980's. The author wishes to express his heartfelt thanks to the many people who contributed to this specification, especially to Rich Salz, Bill Randle, Tad Guy, Dan Heller, John Nelson, Steve Grimm, Mike Stump AND OTHERS TO BE FILLED IN... 11. Security Considerations Security issues are not discussed in this memo. 12. References [1] Horton, M., Adams, R., "Standard for Interchange of USENET Mes- sages", RFC 1036, AT&T Bell Laboratories, Center for Seismic Studies, December 1987 13. Author's Address Kent Landfield 3245 Meredith Ln Grapevine, TX 76051-6509 Phone: 817-858-0515 EMail: kent@landfield.com Landfield [Page 24]