dhesi@iuvax.cs.indiana.edu) (02/14/89)
Posting-number: Volume 01 Issue INF4
Originally-from: Rahul Dhesi (bsu-cs!dhesi@iuvax.cs.indiana.edu)
Submitted-by: Rahul Dhesi (bsu-cs!dhesi@iuvax.cs.indiana.edu)
Archive-name: v01info/format.inf
[Written by Rahul Dhesi, Mon Feb 13 13:29:37 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". Volume numbers change
approximately once every six months to a year. Issue numbers change
for 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 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. In many
cases the two will be identical. In other cases, when the two are
different, 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 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, to
suggest deletion of multiple files. For example,
Can-delete: xyz/src0[1-3]
Can-delete: xyz/exe0[1-2]
means that xyz/src01, xyz/src02, xyz/src03, 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.
Also provided is file size in bytes.
-- end of format.inf --