home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 19 / CD_ASCQ_19_010295.iso / vrac / mb1801.zip / MB1801.EXE / HEADER.DOC < prev    next >
Text File  |  1994-04-23  |  3KB  |  73 lines
  1.       About BBS Message Headers.
  2.  
  3. There seems to be a general mis-understanding of the function
  4. of the message headers. Here is a little history that may clear things up.
  5.  
  6. Originally there were no message headers.
  7. This caused some problems: it was very hard to diagnose
  8. network failures without the audit trail of the path the mesage
  9. took though the network. So, in mid-1984, I added the header.
  10.  
  11. In 1985, the ARRL gave a demonstration of automatic message forwarding
  12. to the FCC. One of the main points presented to the FCC was that the message
  13. headers allowed for FULL TRACING of who handled the message, and
  14. when it was transmitted by each station. This automatic audit trail
  15. was one of the major arguments in favor of automatic control of packet
  16. BBS stations, and helped to result in Docket 85-105, and eventually
  17. the HF STA, and thus packet radio as we know it today.
  18.  
  19. As time went on, many people discovered that they could learn a
  20. great deal about the functioning of the network by looking at
  21. the message headers. Some wrote software to do this automatically.
  22. The WP server is one example. It uses the information contained
  23. in the message headers to help build and maintain it's distributed
  24. database system.
  25.  
  26. People are now working on software that will automatically determine
  27. the entire network map from the information contained in message
  28. headers. Some day, this will allow us to build our BBS routing
  29. tables AUTOMATICALLY. As we all know, maintaining routing tables
  30. is one of the nasty chores for a BBS sysop!
  31.  
  32. Two things must happen for this all to work:
  33.  
  34. 1. It is MOST important that the information in the message header
  35.    not be altered as it passes through the various BBS on it's path.
  36.  
  37. 2. The header must be in a standard format, so that the software
  38.    that decodes it can operate correctly.
  39.  
  40. 3. The message headers are separated from the body of the message
  41.    by a blank line.  Anything that comes before the first blank
  42.    line is a header, whether in correct format or not.    Anything
  43.    that comes after the first blank line is the message body.
  44.  
  45.  
  46. The format of these headers has evolved through many changes.
  47. In 1987, NK6K proposed a standard to be used by all BBS authors.
  48. Most followed this standard, or followed a slightly different
  49. standard used originally by WA7MBL.
  50.  
  51. The following is a standard "nk6k" header:
  52.  
  53. R:920527/0507 @:W0RLI.OR.USA.NA West Linn #:6031 Z:97068
  54.  
  55. Required: The "R:" identifies the line as a standard header.
  56. Required: Date and time the message arrived at this bbs, in GMT.
  57. Required: BBS.
  58. Optional: Hierarchical location. Strongly recommended.
  59. Required: Message number.  Greater than zero, less than 65536.
  60. Optional: QTH, which is all text after the hierarchical location
  61. and before the message number field.
  62.  
  63. Optional: The last field is the ZIP or postal code.
  64.  
  65. Some software allows an optional time zone identifier after the time.
  66. This is not required, and is ignored by most bbs software.
  67.  
  68. The following is a standard minimum header, as proposed by KA2BQE:
  69. All fields are required.
  70.  
  71. R:951115/0629 3456@W0RLI.OR.USA.NA
  72.  
  73.