home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / FSC.ZIP / FSC-0007.TXT < prev    next >
Text File  |  1987-10-16  |  12KB  |  245 lines
  1. FSC-0007
  2.  
  3.             FidoNet <tm> RFC822-Style Message Format
  4.     (Informal Proposed Message Format Specification - Draft)
  5.                      Robert Heller @ 321/148
  6.                   Thr Oct 15, 1987 19:47:47.74
  7.  
  8. 1. Purpose.
  9. ===========
  10.  
  11. The purpose of this document is to outline my ideas concerning
  12. FidoNet <tm> message format, both as stored on disk as message
  13. files handled by BBS (or other "conferencing" programs) and as
  14. these messages exist packed into "bundles" or "packets" as
  15. transmitted from machine to machine.  I think using a uniform
  16. format for normal message storage will make things easier, at
  17. least in terms of "standardized" message bundling and transmiting
  18. software is concerned.  If done right it also makes things easier
  19. for BBS and conferencing software writers too.
  20.  
  21. This specification is only a first draft proposal.  Just
  22. something to put on the table for discussion. Feel free to
  23. comment on it. I am open to suggestions.
  24.  
  25. 2. Preliminary Definations.
  26. ===========================
  27.  
  28. I will be using BNF notation to describe the format of data
  29. fields.  This is a fairly standard notation and should be familar
  30. to anyone who has taken a compiler design course.  To make things
  31. a little briefer, I will be using some pre-defined
  32. psuedo-terminal symbols.  These symbols are defined as:
  33.  
  34.    o The symbol ALPHA referes to any ASCII alphabetic character,
  35.      including the uppercase letters ('A' thru 'Z', 41H thru
  36.      5AH), the lowercase letters ('a' thru 'z', 61H thru 7AH) and
  37.      these characters: '#' (23H), '$' (24H), '&' (26H), '*'
  38.      (2AH), '+' (2BH), '-' (2DH), '=' (3DH), '^' (5EH), and '_'
  39.      (5FH).
  40.  
  41.    o The symbol DIGIT refers to any of the ASCII characters '0'
  42.      thru '9' (30H thru 39H).
  43.  
  44.    o The symbol NEWLINE refers to the two character sequence CR
  45.      (0DH) following LF (0AH).
  46.  
  47.    o The symbol WHITESPACE refers to one or more ASCII space
  48.      (20H) or tab (09H) characters. 
  49.  
  50.    o The symbol OPTWHITESPACE referes to zero or more ASCII space
  51.      (20H) or tab (09H) characters.
  52.  
  53.    o The symbol TEXT referes to zero or more printable ASCII
  54.      characters not including a NEWLINE sequence.
  55.  
  56.    o The symbol NULL referes to the null string (no characters at
  57.      all).
  58.  
  59. Oh, one other thing:  message files contain only printable ASCII
  60. characters and NEWLINE sequences (packed messages will have
  61. non-printable bytes).  Also, I'll number the definations.  I am
  62. also only using six BNF operator characters: a vertical bar (|)
  63. for alteration, braces ({}) for comments, single quotes (') for
  64. character and string literals and parens (()) for expression
  65. grouping. 
  66.  
  67.  
  68. 3. Definations 1: Stored Message.
  69. =================================
  70.  
  71. The goal symbol is "<message>".
  72.  
  73.    { A message consists of a header followed followed by a
  74.      NEWLINE followed by a message body. }
  75. <message>::=<header> NEWLINE <message-body>             {Def 1.1}
  76.    { A message body is just unbounded text. }
  77. <message-body>::=NULL | (TEXT NEWLINE <message-body>)   {Def 1.2}
  78.    { A header is more complicated:  There are a series of
  79.      header line types. }
  80. <header>::=<header-line> NEWLINE <header>               {Def 1.3}
  81. <header-line>::=<to>|<from>|<date>|<attributes>|
  82.                 <cost>|<subject>|<via>|<origin>|
  83.                 <area>|<seen-by>|<message-id>|
  84.                 <other-header-line>                     {Def 1.4}
  85.    { Now for the header line formats themselves.
  86.      Some notes:  certain header lines are required (<to>,
  87.      <from>, and <date>), and some can only occur once (<to>,
  88.      <from>, <date>, and <subject>). Except for these
  89.      restrictions, most header lines can either be omited or can
  90.      occur more than once. }
  91. <to>::='To: ' <address>                                 {Def 1.5}
  92. <from>::='From: ' <address>                             {Def 1.6}
  93. <address>::=<user> OPTWHITESPACE '@' OPTWHITESPACE 
  94.             <nodeid>                                    {Def 1.7}
  95. <user>::= ALPHA <user1>                                 {Def 1.8}
  96. <user1>::= (ALPHA | DIGIT | WHITESPACE | NULL) <user1>  {Def 1.9}
  97.         { Note: this is the full blown INFA node address -
  98.           includes optional zone and point numbers. }
  99. <nodeid>::= ((<digits> ':') | NULL) {zone}
  100.             <digits> '/' <digits>   {basic net/node}
  101.             (('.' <digits>) | NULL) {point}             {Def 1.10}
  102. <digits>::= DIGIT | (DIGIT <digits>)                    {Def 1.11}
  103. <date>::='Date: ' <date-string>                         {Def 1.12}
  104.         { Here it is: my idea for a *standard* date string }
  105.   { day-of-week month date, year hour:minute AM/PM time-zone }
  106.   { Although not specified, hours and minutes are zero padded to
  107.     two digits.  The date and year are not padded at all.}
  108. <date-string>::= <day> ' ' <month> ' ' <digits> ', ' 
  109.                  <digits> ' ' <digits> ':' <digits> 
  110.                  <am-pm> ((' ' <time-zone> | NULL)      {Def 1.13}
  111. <day>::= 'Mon" | 'Tue' | 'Wed' | 'Thu' | 'Fri' | 
  112.          'Sat' | 'Sun'                                  {Def 1.14}
  113. <month>::= 'Jan' | 'Feb' | 'Mar' | 'Apr' | 'May' | 
  114.            'Jun' | 'Jul' | 'Aug' | 'Sep' | 'Oct' |
  115.            'Nov' | 'Dec'                                {Def 1.15}
  116.         { If the AM/PM indicator is missing (null), the hours
  117.           field is assumed to in 24-hour format (i.e. 00 to 23) }
  118. <am-pm>::= 'AM' | 'PM' | NULL                           {Def 1.16}
  119.         { This field is optional.  It makes sense given that
  120.           FidoNet <tm> is international. }
  121. <time-zone>::= ALPHA | (ALPHA <time-zone>)              {Def 1.17}
  122. <subject>::=('Subject: ' | 'Subject (Private): ') TEXT  {Def 1.18}
  123. <cost>::='Cost: ' <money-sign> <digits>
  124.          (('.' <digits>) | NULL)                        {Def 1.19}
  125.         { This is tricky, given the internationalness
  126.           of FidoNet <tm>.  I guess it isn't critical. }
  127. <money-sign>::= '$' | '#' | NULL                        {Def 1.20}
  128. <via>::= 'Via: ' <nodeid> ', ' <date-string> <program>  {Def 1.21}
  129. <program>::= NULL | (' ' TEXT)                          {Def 1.22}
  130. <origin>::= 'Origin: ' TEXT                             {Def 1.23}
  131. <area>::= 'Area: ' <areaname>                           {Def 1.24}
  132.         { I'm leaving the question of all caps for the
  133.           area name open:  other than ease of comparision,
  134.           is it neccessary to be all caps? }
  135. <areaname>::= ALPHA | (ALPHA <areaname>)                {Def 1.25}
  136. <seen-by>::= 'Seen-By: ' <seen-by-list>                 {Def 1.26}
  137. <seen-by-list>::= <seen-nodeid> | 
  138.                   (<seen-nodeid> <seen-by-list>)        {Def 1.27}
  139. <seen-nodeid> ::= ((<digits> ':') NULL)
  140.                   ((<digits> '/') NULL) <digits>
  141.                   (('.' <digits>) | NULL)               {Def 1.28}
  142.         { This is also open-ended.  Should there be a
  143.           standard format for this? }
  144. <message-id>::= 'Message-id: ' TEXT                     {Def 1.29}
  145. <attributes>::= 'Attributes: ' <attrlist>               {Def 1.30}
  146. <attrlist>::=<attribute> | (<attribute> ', ' <attrlist>){Def 1.31}
  147.         { This is probably not complete, but...}
  148. <attribute>::='Kill Sent' | 'File Attached' | 'File Request' |
  149.               'Sent' | 'Crash' | 'Audit'                {Def 1.32}
  150. <other-header-line>::=<tagname> ': ' (TEXT | NULL)      {Def 1.33}
  151. <tagname>::= ALPHA <tagname1>                           {Def 1.34}
  152. <tagname1>::=NULL | ((ALPHA | WHITESPACE | DIGIT |
  153.              <pun> <tagname1>)                          {Def 1.35}
  154.         { This is also open-ended.  Restriction: colon (:)
  155.           cannot be allowed! }
  156. <pun>::='(' | ')' | '.' | ',' | ';'                     {Def 1.36}
  157.  
  158. 4. Packed Message Format.
  159. =========================
  160.  
  161. A packed message is simply a regular message with some binary
  162. header info and a NUL (00H) byte after the message text:
  163.  
  164.        Offset
  165.       dec hex
  166.               .-----------------------------------------------.
  167.         0   0 |    0     |     3      |    0      |    0      |
  168.               +-----------------------+-----------------------+
  169.         2   2 | origZone (low order)  | origZone (high order) |
  170.               +-----------------------+-----------------------+
  171.         4   4 | origNet  (low order)  | origNet  (high order) |
  172.               +-----------------------+-----------------------+
  173.         6   8 | origNode (low order)  | origNode (high order) |
  174.               +-----------------------+-----------------------+
  175.         8   8 | origPoint (low order) | origPoint (high order)|
  176.               +-----------------------+-----------------------+
  177.        10   A | destZone (low order)  | destZone (high order) |
  178.               +-----------------------+-----------------------+
  179.        12   C | destNet  (low order)  | destNet  (high order) |
  180.               +-----------------------+-----------------------+
  181.        14   E | destNode (low order)  | destNode (high order) |
  182.               +-----------------------+-----------------------+
  183.        16  10 | destPoint (low order) | destPoint (high order)|
  184.               +-----------------------+-----------------------+
  185.        18  12 | Attribute (low order) | Attribute (high order)|
  186.               +-----------------------+-----------------------+
  187.        20  14 |      message text (includes ASCII header)     |
  188.               ~                    unbounded                  ~
  189.               |                 null terminated               |
  190.               `-----------------------------------------------'
  191.  
  192. Some notes:  I've included both the Zone and Point addresses in
  193. the packed message headers.  This does not really affect things
  194. like routing and point mapping.  The packets themselves have
  195. addressing info in their headers (as described in FSC001).  The
  196. addressing in the packet header - this addressing is used by the
  197. transmitting programs.  The internal addressing info is processed
  198. by re-packing programs - that is programs which peel routed
  199. messages (messages that are "just passing through") and re-packet
  200. them for later re-transmitsion to another node during a future
  201. mail event.  Messages destined for the current node (one whose
  202. address exactly matches all four destination address words), get
  203. extracted from the packet and stored in the message base.  Note
  204. that only the ASCII message text is stored.  The binary header is
  205. discarded at this point. 
  206.  
  207. 5. Conclusions.
  208. ===============
  209.  
  210. It is my idea that FidoNet <tm> is going to sooner or later going
  211. need some of the extendablity provided by this sort of message
  212. format. If fact it allready needs some of these fields, and has
  213. been "faking it" for some time now: things like EchoMail (
  214. "Area: ", "Origin: ", and "Seen-By: " header lines), points and
  215. zones (extra addressing hacks), uucp gatewaying (more extra
  216. addressing hacks), routing ("Via: " header lines).  Going to a
  217. RFC822-style message format also helps to increase the varity of
  218. BBS and conferencing software - this will help improve the "state
  219. of the art" in this regard.  Also, using a RFC822-style message
  220. format allows indefinite extensablity - as new ideas regarding
  221. messages and conferencing develope, the message format can be
  222. easily extended to handle these new ideas with ease.
  223.  
  224. 6. Contact Info.
  225. ================
  226.  
  227. Comments, suggestions, gripes, etc. can be sent to me at any of
  228. these addresses: 
  229.  
  230.         ARPANet:        Heller@CS.UMass.Edu
  231.         BITNET:         Heller@UMass.BitNet
  232.         Genie:          RHELLER
  233.         BIX:            heller
  234.         CompuServe:     71450,3432
  235.         FidoNet         Robert Heller @ 1:321/148
  236.         USMail:         SRB 51A, Locks Hill Road, Wendell, MA 01379
  237.         Voice Phone:    617-544-6933, Weekdays before 19:30
  238.                         Eastern Time, Weekends from 08:00 to
  239.                         19:30 Eastern time. Or, 413-545-0528 from
  240.                         08:00 to 16:00 Eastern Time Weekdays.
  241.         Data Phone:     617-544-6933 at 300 or 1200 BAUD from
  242.                         19:30 to 08:00 Eastern Time, except
  243.                         during FidoNet <tm> mail periods.
  244.                                                                                              
  245.