Garbo/Garbo.cdr/pc/doc_net/format.inf

Internet Message Format | 1989-05-27 | 9.7 KB

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: [e-mail] (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: <[e-mail]>
Date: 26 May 89 06:00:16 GMT
Expires: 27 Jun 89 06:00:14 GMT
Sender: [e-mail]
Followup-To: comp.binaries.ibm.pc.d
Lines: 201
Approved: [e-mail]
X-Submissions-to: [e-mail]
X-Questions-to: [e-mail]
X-Repost-requests-to: [e-mail]

Checksum: 4219959243  (Verify with "brik -cv")
Posting-number: Volume 03, Issue INF4
Submitted-by: Rahul Dhesi <[e-mail]>
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 "[e-mail]".  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 [e-mail] 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 --