home *** CD-ROM | disk | FTP | other *** search
/ Garbo / Garbo.cdr / pc / doc_net / format.inf < prev    next >
Internet Message Format  |  1989-05-27  |  10KB
  1. From ra!tut!draken!kth!mcvax!uunet!cs.utexas.edu!rutgers!iuvax!bsu-cs!ibmbin Fri May 26 13:05:33 EET DST 1989
  2. Article 298 of comp.binaries.ibm.pc:
  3. Path: chyde!ra!tut!draken!kth!mcvax!uunet!cs.utexas.edu!rutgers!iuvax!bsu-cs!ibmbin
  4. >From: dhesi@bsu-cs.bsu.edu (Rahul Dhesi)
  5. Newsgroups: comp.binaries.ibm.pc
  6. Subject: v03INF4: format.inf, description of format of postings
  7. Summary: format.inf, description of format of postings
  8. Keywords: info
  9. Message-ID: <7446@bsu-cs.bsu.edu>
  10. Date: 26 May 89 06:00:16 GMT
  11. Expires: 27 Jun 89 06:00:14 GMT
  12. Sender: ibmbin@bsu-cs.bsu.edu
  13. Followup-To: comp.binaries.ibm.pc.d
  14. Lines: 201
  15. Approved: dhesi@bsu-cs.bsu.edu
  16. X-Submissions-to: ibmpc-binaries@bsu-cs.bsu.edu
  17. X-Questions-to: ibmpc-binaries-request@bsu-cs.bsu.edu
  18. X-Repost-requests-to: ibmpc-repost@bsu-cs.bsu.edu
  19.  
  20. Checksum: 4219959243  (Verify with "brik -cv")
  21. Posting-number: Volume 03, Issue INF4
  22. Submitted-by: Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
  23. Archive-name: v03info/format.inf
  24.  
  25. [ Written by Rahul Dhesi, Mon Feb 13 13:29:37 EST 1989.  Last change
  26. from Rahul Dhesi, Sun Mar 19 00:59:55 EST 1989 ]
  27.  
  28.                             FORMAT OF POSTINGS
  29.  
  30. All postings in comp.binaries.ibm.pc include a set of headers at the
  31. beginning in a standardized form.  There are two sets of headers.  The
  32. first set of headers is separated from the second set, and the second
  33. set is separated from the rest of the posting, by an empty line.  The
  34. first set conforms to the format used by the news transport and reading
  35. software.  The second set is not used by the news software but provides
  36. information that may not be available in the first set of headers.
  37.  
  38. FIRST SET OF HEADERS
  39.  
  40. The From: header is always an electronic mail address of the person who
  41. submitted this posting to comp.binaries.ibm.pc.  Whenever available,
  42. this address is in domain format.  If no domain address was available,
  43. it is in the format "user@host.UUCP".  If the second format was used,
  44. look elsewhere in the posting for suggestions about possible UUCP paths
  45. to use.  Whenever possible, the address is accompanied by the name of
  46. the person.
  47.  
  48. The Subject: header is in one of the following forms:
  49.  
  50.      Subject: vxxiyyy: name, description
  51.      Subject: vxxiyyy: name, description (part mm/nn)
  52.      Subject: vxxINFy: name, description
  53.      Subject: vxxJUNK: description
  54.  
  55. The "vxxiyyy" means "Volume xx, Issue yyy".  The Volume number changes
  56. approximately once every 100 issues.  The issue number changes with
  57. each posting.  Large submissions are broken up into smaller pieces, and
  58. a single submission will then correspond to several issue.  In this
  59. case the "part mm/nn" identifies each part of a multi-part posting, and
  60. "mm/nn" means "part mm of a total of nn parts".  In rare cases, when an
  61. unimportant administrative posting appears, it will use the last form,
  62. in which "vxxJUNK" means "junk in volume xx".
  63.  
  64. Occasionally a multi-part posting will be preceded by a part 0 which
  65. describes the parts that follow.
  66.  
  67. Certain informative articles, such as the one you are reading now, are
  68. periodically posted to introduce the user this newsgroup, explain how
  69. to get software from it, how to submit software to it, etc.  These
  70. postings have a Subject header of the third type, in which "vxxINFy"
  71. means "periodic informative posting y in volume xx".
  72.  
  73. The Summary: header is of the form:
  74.  
  75.      Summary: filename, description
  76.  
  77. The "filename" is the filename in which this posting will be found
  78. after it has been extracted as appropriate.  (Extraction will usually
  79. involve combining multiple parts if any and then uudecoding.)   The
  80. "filename" is intended to be legal under MS-DOS 2.x, MS-DOS 3.x, System
  81. V and 4.xBSD.  The "description" usually duplicates the description
  82. given in the Subject:  header except that part numbers are not given.
  83.  
  84. The Keywords: header is added to some postings to mark them as
  85. special.  This header is followed by a comma-separated list of
  86. keywords.  Currently, the keywords in use are:
  87.  
  88.      administrivia             An administrative announcement
  89.      discard                   A posting that can be discarded soon after
  90.                                it has been read, so it need not be archived
  91.      info                      An informative posting;  similar to
  92.                                administrivia, but of greater scope
  93.  
  94. Administrative postings of fleeting importance are marked with both the
  95. "administrivia" and "discard" keywords.  It is probably safest to
  96. archive all postings that do not include the "discard" keyword.
  97.  
  98. SECOND SET OF HEADERS
  99.  
  100. The Checksum: header is of the form:
  101.  
  102.       Checksum: 1733847567
  103.  
  104. This header may be used to verify the integrity of the article as it
  105. arrived at your site.  The checksum is really a 32-bit CRC (cyclic
  106. redundancy code) generated with the program "brik", which was posted in
  107. comp.binaries.ibm.pc as C source and MS-DOS executable in volume 1,
  108. issue 217, 14 March 1989.  To verify the integrity of any article in
  109. comp.binaries.ibm.pc, supply it to brik as a filename on the command
  110. line or as standard input.  For example, from rn, you can type
  111.  
  112.      | brik -cv
  113.  
  114. and if brik prints no error message, it means that the CRC calculated
  115. by brik matched the one stored in the article.  You can also save the
  116. article in a file, e.g. a file called this.article, and then give the
  117. command:
  118.  
  119.      brik -cv this.article
  120.  
  121. to check the CRC.
  122.  
  123. The Posting-number: header is of one of the forms:
  124.  
  125.       Volume xx, Issue yyy
  126.       Volume xx, Issue INFy
  127.       Volume xx, Issue JUNK
  128.  
  129. This verbosely duplicates the information in the "vxxiyyy", "vxxINFy",
  130. or "vxxJUNK" field found in the Subject: header.
  131.  
  132. The Originally-from: and Submitted-by: headers tell you where this
  133. posting originated and who submitted it to this newsgroup.  The
  134. Originally-from: header is optional and is added only if it provides
  135. information that is not in the Submitted-by: header.  The
  136. Originally-from: header identifies where the submitter got the
  137. software, or who wrote it, or both.  The Originally-from: header will
  138. not always mean the same thing, but is simply an attempt to provide
  139. more information than the Submitted-by: header alone provides.
  140.  
  141. The Submitted-by: header identifies who submitted the posting to this
  142. newsgroup.  If you have questions about a posting (rather than the
  143. software itself), the person identified in this header is usually the
  144. one to contact.  Due to the possibility of the news software mangling
  145. headers of articles, the Submitted-by: header is likely to be more
  146. reliable than the From: header.
  147.  
  148. Both the Originally-from: and Submitted-by: headers provide a domain
  149. format electronic mail address if one is available, else they provide
  150. an address of the form user@host.UUCP or host1!host2!...!user.  Where
  151. possible any UUCP address is shown relative to a well-known site, or
  152. additional hints for contacting the person are given in the text
  153. following the header.
  154.  
  155. The Archive-name: header is intended to be used for the automated (or
  156. manual) archiving of postings.  The format of the string following is
  157. always "dirname/filename" where "dirname" is a suggested directory name
  158. and "filename" is a suggested filename for storing this specific
  159. posting.  In the case of a multi-part posting each part will have the
  160. same "dirname" but a different "filename".  Both the "dirname" and
  161. "filename" are legal directory or file names under MS-DOS 2.x, MS-DOS
  162. 3.x, System V, and 4.xBSD.  The filename is often, but not always, of
  163. the form "partxx" where xx is a two-digit number.
  164.  
  165. The Can-delete: header is occasionally added when a posting supersedes
  166. an earlier one, for example, when a new version of software is posted
  167. and the old one becomes obsolete.  Only the Can-delete: header in the
  168. FIRST part of a multi-part posting is intended to be used in this way,
  169. although it may be present in other parts too.  The Can-delete: header
  170. is in the form of "dirname/filespec" such that "dirname" is a directory
  171. name, and "filespec" is a filespec that may possibly contain wildcards
  172. acceptable to the C-shell.  The Can-delete: header is a recommendation
  173. from the moderator that matching files can be deleted because they are
  174. obsolete.
  175.  
  176. If necessary, the Can-delete: header may occur more than once, or
  177. contain multiple filenames, to suggest deletion of multiple files.  For
  178. example,
  179.  
  180.      Can-delete:  xyz/src0[1-3]  abc/exe[135]
  181.      Can-delete:  xyz/exe0[1-2]
  182.  
  183. means that xyz/src01, xyz/src02, xyz/src03, abc/exe1, abc/exe3,
  184. abc/exe5, xyz/exe01, and xyz/exe02 may all be deleted.
  185.  
  186. This header should NOT be used for the automatic deletion of files, as
  187. I cannot guarantee that I will never make any mistakes.  Do all
  188. deletions manually.
  189.  
  190. MODERATOR'S COMMENTS AND CHECKSUMS
  191.  
  192. Most postings are accompanied by moderator's comments.  These are
  193. enclosed in brackets [...].  If during testing I find bugs that are not
  194. serious enough to prevent the software from being useful, I simply
  195. describe them in my comments.  The thoroughness with which I test
  196. software before it is posted varies.  I try to test every submission,
  197. but some occasionally get posted with little or no testing.
  198.  
  199. Each single-part posting, and part 1 of each multi-part posting,
  200. contains a list of checksums.  These are calculated using the 4.3BSD
  201. "sum" command.  To get the same answer use "sum -r" under System V.
  202.  
  203. Checksums for uuencoded postings are always for all the lines between,
  204. but not including, the BEGIN and END lines.  To find this checksum
  205. easily you can filter a posting through the following shell command
  206. line:
  207.  
  208.      sed -e '1,/^BEGIN/d' -e '/^END/,$d'| sum
  209.  
  210. (use "sum -r" instead of "sum" under System V).
  211.  
  212. The checksum for a file that you would get after uudecoding is for the
  213. entire file.
  214.  
  215. The format in which checksums are given in the body of a posting is not
  216. yet standardized.  It is due to be revised soon to make it more
  217. compact, and to make it easier to automate the testing of checksums.
  218.  
  219. Also provided is file size in bytes.
  220. -- end of format.inf --
  221.  
  222.  
  223.