From ra!tut!draken!kth!mcvax!uunet!cs.utexas.edu!rutgers!iuvax!bsu-cs!ibmbin Fri May 26 13:05:33 EET DST 1989 Article 298 of comp.binaries.ibm.pc: Path: chyde!ra!tut!draken!kth!mcvax!uunet!cs.utexas.edu!rutgers!iuvax!bsu-cs!ibmbin >From: dhesi@bsu-cs.bsu.edu (Rahul Dhesi) Newsgroups: comp.binaries.ibm.pc Subject: v03INF4: format.inf, description of format of postings Summary: format.inf, description of format of postings Keywords: info Message-ID: <7446@bsu-cs.bsu.edu> Date: 26 May 89 06:00:16 GMT Expires: 27 Jun 89 06:00:14 GMT Sender: ibmbin@bsu-cs.bsu.edu Followup-To: comp.binaries.ibm.pc.d Lines: 201 Approved: dhesi@bsu-cs.bsu.edu X-Submissions-to: ibmpc-binaries@bsu-cs.bsu.edu X-Questions-to: ibmpc-binaries-request@bsu-cs.bsu.edu X-Repost-requests-to: ibmpc-repost@bsu-cs.bsu.edu Checksum: 4219959243 (Verify with "brik -cv") Posting-number: Volume 03, Issue INF4 Submitted-by: Rahul Dhesi Archive-name: v03info/format.inf [ Written by Rahul Dhesi, Mon Feb 13 13:29:37 EST 1989. Last change from Rahul Dhesi, Sun Mar 19 00:59:55 EST 1989 ] FORMAT OF POSTINGS All postings in comp.binaries.ibm.pc include a set of headers at the beginning in a standardized form. There are two sets of headers. The first set of headers is separated from the second set, and the second set is separated from the rest of the posting, by an empty line. The first set conforms to the format used by the news transport and reading software. The second set is not used by the news software but provides information that may not be available in the first set of headers. FIRST SET OF HEADERS The From: header is always an electronic mail address of the person who submitted this posting to comp.binaries.ibm.pc. Whenever available, this address is in domain format. If no domain address was available, it is in the format "user@host.UUCP". If the second format was used, look elsewhere in the posting for suggestions about possible UUCP paths to use. Whenever possible, the address is accompanied by the name of the person. The Subject: header is in one of the following forms: Subject: vxxiyyy: name, description Subject: vxxiyyy: name, description (part mm/nn) Subject: vxxINFy: name, description Subject: vxxJUNK: description The "vxxiyyy" means "Volume xx, Issue yyy". The Volume number changes approximately once every 100 issues. The issue number changes with each posting. Large submissions are broken up into smaller pieces, and a single submission will then correspond to several issue. In this case the "part mm/nn" identifies each part of a multi-part posting, and "mm/nn" means "part mm of a total of nn parts". In rare cases, when an unimportant administrative posting appears, it will use the last form, in which "vxxJUNK" means "junk in volume xx". Occasionally a multi-part posting will be preceded by a part 0 which describes the parts that follow. Certain informative articles, such as the one you are reading now, are periodically posted to introduce the user this newsgroup, explain how to get software from it, how to submit software to it, etc. These postings have a Subject header of the third type, in which "vxxINFy" means "periodic informative posting y in volume xx". The Summary: header is of the form: Summary: filename, description The "filename" is the filename in which this posting will be found after it has been extracted as appropriate. (Extraction will usually involve combining multiple parts if any and then uudecoding.) The "filename" is intended to be legal under MS-DOS 2.x, MS-DOS 3.x, System V and 4.xBSD. The "description" usually duplicates the description given in the Subject: header except that part numbers are not given. The Keywords: header is added to some postings to mark them as special. This header is followed by a comma-separated list of keywords. Currently, the keywords in use are: administrivia An administrative announcement discard A posting that can be discarded soon after it has been read, so it need not be archived info An informative posting; similar to administrivia, but of greater scope Administrative postings of fleeting importance are marked with both the "administrivia" and "discard" keywords. It is probably safest to archive all postings that do not include the "discard" keyword. SECOND SET OF HEADERS The Checksum: header is of the form: Checksum: 1733847567 This header may be used to verify the integrity of the article as it arrived at your site. The checksum is really a 32-bit CRC (cyclic redundancy code) generated with the program "brik", which was posted in comp.binaries.ibm.pc as C source and MS-DOS executable in volume 1, issue 217, 14 March 1989. To verify the integrity of any article in comp.binaries.ibm.pc, supply it to brik as a filename on the command line or as standard input. For example, from rn, you can type | brik -cv and if brik prints no error message, it means that the CRC calculated by brik matched the one stored in the article. You can also save the article in a file, e.g. a file called this.article, and then give the command: brik -cv this.article to check the CRC. The Posting-number: header is of one of the forms: Volume xx, Issue yyy Volume xx, Issue INFy Volume xx, Issue JUNK This verbosely duplicates the information in the "vxxiyyy", "vxxINFy", or "vxxJUNK" field found in the Subject: header. The Originally-from: and Submitted-by: headers tell you where this posting originated and who submitted it to this newsgroup. The Originally-from: header is optional and is added only if it provides information that is not in the Submitted-by: header. The Originally-from: header identifies where the submitter got the software, or who wrote it, or both. The Originally-from: header will not always mean the same thing, but is simply an attempt to provide more information than the Submitted-by: header alone provides. The Submitted-by: header identifies who submitted the posting to this newsgroup. If you have questions about a posting (rather than the software itself), the person identified in this header is usually the one to contact. Due to the possibility of the news software mangling headers of articles, the Submitted-by: header is likely to be more reliable than the From: header. Both the Originally-from: and Submitted-by: headers provide a domain format electronic mail address if one is available, else they provide an address of the form user@host.UUCP or host1!host2!...!user. Where possible any UUCP address is shown relative to a well-known site, or additional hints for contacting the person are given in the text following the header. The Archive-name: header is intended to be used for the automated (or manual) archiving of postings. The format of the string following is always "dirname/filename" where "dirname" is a suggested directory name and "filename" is a suggested filename for storing this specific posting. In the case of a multi-part posting each part will have the same "dirname" but a different "filename". Both the "dirname" and "filename" are legal directory or file names under MS-DOS 2.x, MS-DOS 3.x, System V, and 4.xBSD. The filename is often, but not always, of the form "partxx" where xx is a two-digit number. The Can-delete: header is occasionally added when a posting supersedes an earlier one, for example, when a new version of software is posted and the old one becomes obsolete. Only the Can-delete: header in the FIRST part of a multi-part posting is intended to be used in this way, although it may be present in other parts too. The Can-delete: header is in the form of "dirname/filespec" such that "dirname" is a directory name, and "filespec" is a filespec that may possibly contain wildcards acceptable to the C-shell. The Can-delete: header is a recommendation from the moderator that matching files can be deleted because they are obsolete. If necessary, the Can-delete: header may occur more than once, or contain multiple filenames, to suggest deletion of multiple files. For example, Can-delete: xyz/src0[1-3] abc/exe[135] Can-delete: xyz/exe0[1-2] means that xyz/src01, xyz/src02, xyz/src03, abc/exe1, abc/exe3, abc/exe5, xyz/exe01, and xyz/exe02 may all be deleted. This header should NOT be used for the automatic deletion of files, as I cannot guarantee that I will never make any mistakes. Do all deletions manually. MODERATOR'S COMMENTS AND CHECKSUMS Most postings are accompanied by moderator's comments. These are enclosed in brackets [...]. If during testing I find bugs that are not serious enough to prevent the software from being useful, I simply describe them in my comments. The thoroughness with which I test software before it is posted varies. I try to test every submission, but some occasionally get posted with little or no testing. Each single-part posting, and part 1 of each multi-part posting, contains a list of checksums. These are calculated using the 4.3BSD "sum" command. To get the same answer use "sum -r" under System V. Checksums for uuencoded postings are always for all the lines between, but not including, the BEGIN and END lines. To find this checksum easily you can filter a posting through the following shell command line: sed -e '1,/^BEGIN/d' -e '/^END/,$d'| sum (use "sum -r" instead of "sum" under System V). The checksum for a file that you would get after uudecoding is for the entire file. The format in which checksums are given in the body of a posting is not yet standardized. It is due to be revised soon to make it more compact, and to make it easier to automate the testing of checksums. Also provided is file size in bytes. -- end of format.inf --