I'm just going to make one general point here, to clarify things a bit
better. Hopefully these will forstall comments that aren't germane
to my intent. Then, a few more specific points.
People have shown concern that my draft is in conflict, for
example, with full RFC1153, and their existing format doesn't comply
with my draft. To the extent of sending me copies of existing
FAQs which are (supposed to be) RFC1153 compliant, but not compliant
with mine.
This draft is not intended to supercede any other existing formal
or semi-formal format. Thus, for example, FAQs already written to
full RFC1153 are just fine (the sample emailed to me wasn't *perfectly*
RFC1153 BTW), and don't need to switch. This is because RFC1153,
in terms of how the existing tools actually work, is (defacto)
a superset of my format. Eg: T. Fine's tools will work with my draft
just as easily as it works with full RFC1153. Indeed, the FAQs
that I have authored are closer to RFC1153 than this draft, and I
don't intend to "stupid up" my FAQs either.
The draft is trying to compromise on a very fine line:
- be compatible with existing tools (news reader undigest,
T. Fine's digest converter, etc.) [see below]
- be reasonably compatible with existing practise
- be trivially easy to use or convert to.
- easy to read without fancy software.
It is intended to gain the most "bang per buck" for someone writing
a new FAQ, or converting an existing non-digest FAQ and wishes to
spend the absolute minimum time futzing with formats. Through one
simple syntax for "Subject:" the draft gets 90% of what people *really*
want the FAQs to do. I'd hate to complicate the "minimum" guidelines
by a factor of four just to get 5% more functionality. If you want
to go fancier, by all means adopt bits of 1153.
After all, "strict" RFC1153 is only implemented in an extremely small
number of messages, and most of the bells and whistles of the format
aren't actually used by any tools anyways.
Specifically with "Subject:" headers: A number of people brought up
suggestions about various things, such as long subject line continuation,
additional RFC822 headers, and lines of hyphens. Most of these I had
thought of already, but left out for the moment to keep it simple.
I'm not sure that I want to "mandate" hyphens in this draft. I use
them myself, but it doubles the complexity of the Subject: syntax (and
makes my "one edit command" comment a lie), and isn't necessary for most
digest parsers. I also don't want to get too embroiled in RFC822 headers,
because it would need a formal description of their format and meaning
which would go on for pages and pages and pages. I don't want to make
reading RFC822 mandatory... That'd be like insisting everybody understand
their sendmail.cf before they're allowed to send mail.
If I could get away with this:
<blank line and/or line of 30 hyphens starting in column 1>
Subject: <subject>
<continue as necessary>
<additional, optional, RFC822 headers (like From:, Date: etc.)>
<blank line>
<text>
with relatively little additional commentary, I'll go with that.
Table of contents section: I'll put a little extra in as commentary.
The intent is that the TOC entry matches a subset of the Subject lines
so you could "mark" the TOC entry and search for it (as in X). Some
FAQs use special tokens (the comp.text faq uses "TRn") for quick regexp
searching.
A question: I've heard various conflicting rumours about what GNUS
expects a digest to look like. Could someone examine the source
(macro, lisp whatever) and tell me exactly what it *really* wants?
-- Look on the bright side - at least the PC's reached gender parity!Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541 Ferret list: ferret-request@ferret.ocunix.on.ca
[
Usenet Hypertext FAQ Archive |
Search Mail Archive |
Authors |
Usenet
]
[
1993 |
1994 |
1995 |
1996 |
1997
]
© Copyright The Landfield Group, 1997
All rights reserved