![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to BABYL CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Apple XNU] / GNUtools / emacs / etc|
Return to BABYL CVS log | Up to [Apple XNU] / GNUtools / emacs / etc |
1.1 root 1: >From [email protected] (Robert Krawitz) Mon Nov 30 10:56:46 1987
2:
3: Let's see if I remember my BNF for babyl files; this corresponds to
4: version 5:
5:
6:
7: File := <header>
8: <message>* ; Some say there must be at least one message.
9:
10: Header := Babyl Options:\n
11: <header-option>*
12: |^_
13:
14: Header-option := <header-token> ; See note [5]
15: : *
16: <value>
17:
18: header-token := [^\000-\017:\177-\377]* ; Not these characters [tab is OK]
19: header-value := ditto, if a list, each element separated by a comma and
20: a space.
21:
22: message := \^L\n
23: [01], ; See note [1] below
24: ( <attribute>,)* ; Note space before and comma after token
25: ,
26: ( <label>,)* ; ditto, see note [4] below
27: \n
28: <header>* ; See note [1] and [2] below
29: *** EOOH ***\n
30: <header>* ; See note [2] below
31: \n
32: <body>
33: \^_
34:
35: attribute := unseen |
36: last | ; Not all programs implement this. It
37: ; generally only gets used internally, and
38: ; isn't written out to a file.
39: >last | ; Babyl uses this for a deleted message at the
40: ; end. It shouldn't be written out to a file.
41: deleted |
42: recent | ; Not all programs implement this. It refers
43: ; to a message in the last batch of new mail;
44: ; thus it probably shouldn't be written out to
45: ; a file during a normal save although it
46: ; makes sense to write it out in an emergency save.
47: filed |
48: answered |
49: forwarded |
50: redistributed |
51: badheader | ; Not all programs implement this
52: filed ; Not all programs implement this
53:
54: label := [^\000-\020,\177-\377]* ; No control chars,
55: ; whitespace, commas, rubout, or high bit set
56:
57: header := [^\000-\020:\177-\377]*:
58: <header-line>
59: <header-line>*
60:
61: header-line := [ \t][^\n]*\n ; Continuation lines must be indented
62:
63: body := (.*\n)* ; See note [3] below
64:
65:
66: [1] A zero means that the headers have not been cleaned up,
67: reprocessed, toggled, or whatever. In this case there should be no
68: headers before the EOOH line. A one means that the headers have been
69: reprocessed. In this case, the original headers will typically be
70: before the EOOH line and the reformatted or whatever subset of headers
71: that the user should see will be after it. Note that in this case
72: it's permissible to garbage collect all headers before the EOOH line.
73: No one's defined what it means to garbage collect SOME of the headers
74: before this line, or what that means.
75:
76: [2] It's apparently permissible to add headers of the program's own
77: choosing before the EOOH line. Or at least, Rmail does so (it caches
78: a summary line) and nothing seems to object. There's no particular
79: guarantee that something else won't step all over it, though. Headers
80: after the EOOH line can be reformatted as the program wishes (e. g.
81: indent the header lines to the same distance, canonicalize machine
82: names) for display to the user. It's generally best for programs that
83: read a babyl file to look at the headers before the EOOH line if they
84: exist, since these should be untouched by the user. Remember, the
85: user can edit anything after the EOOH line.
86:
87: [3] A \^_ at the beginning of a line should be quoted somehow. The
88: normal way seems to be to decompose it into 2 characters: a ^ and a _.
89: Strictly speaking, it doesn't always have to be, since the following
90: text would have to be parsable as a message, but some programs don't
91: try to use that much intelligence. Oh well.
92:
93: [4] Labels, or keywords as they are often called, are generally
94: defined by the user, although it's not entirely impermissible for a
95: program to use these for its own purpose (e. g. a keyword named
96: RemindMe might be used to automatically find important messages).
97: Some people also want these used to cache other state implemented by
98: certain programs; this use is undefined. Note that all keywords used
99: should be inserted in a header-option named Keywords:. Can a keyword
100: have the same name as an attribute? Who knows? It's probably not a
101: good idea, since some programs use the concept of <labels> =
102: <keywords> + <attributes>. Sigh.
103:
104: [5] Some tokens are standardized in meaning. Common tokens are Mail
105: inboxes, babyl file version number, which is currently 5, labels used
106: in messages, window format for Zmail, anything else you want to be
107: associated with a file. Be warned that labels should be a complete
108: list of all user-defined keywords used in the file, so if you add a
109: new label to a message, you should add it to this list. You should
110: also have a Babyl version: 5 file attribute (look in a babyl file for
111: details).
112:
113: Anyone know if there actually is a "formal" standard? This was done
114: quickly from memory and a Zmail manual, but there are at least three
115: programs around that use Babyl files (zmail, babyl, and emacs/rmail)
116: and someone at SIPB was going to write a command-based mail reader
117: similar to Unix Mail but operating on babyl files, and someone (of
118: course not me :-)) should probably write xbabyl :-)
119:
120: References:
121:
122: ITS/Tops-20 INFO file on babyl (who wrote it? ECC? GZ?)
123:
124: Zmail manual (the MIT version was written by RMS; ECC wrote the
125: section on Babyl file format)
126: --
127:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.