From: Brent Allsop (allsop@swttools.fc.hp.com)
Date: Thu Mar 04 1999 - 09:33:50 MST
> Jason Spencer wrote:
> > There are certain central and less-than-central topics that
> > are repeatedly
> > brought up on this list. Perhaps we should compose a list of
> > these topics
> > and put it on the web, linked in to the list registration page. The
> > intention would not be to discourage discussion of these
> > topics on the list
> > but to let people know that these topics should be approached
> > thoughtfully
> > and probably with essay-length submissions..
> >
> > If any of the long-time readers think that this would be
> > useful, I'm sure
> > you could rattle off a list of such topics better than I..
>
> Now this is an idea I could see implementing. All it requires is a
> little space on the ExI Web server, a little HTML work, and some
> writing - no programming, no ongoing maintenance, and no dollar
> costs at all. I'm sure we could get volunteers to generate a list
> of "important, contentious issues", and to write a summary of each
> side's position on them.
>
> Does ExI have the extra server space for such a project (I'd think
> <1 MB)? And does anyone at ExI have time to coordinate such a
> project?
>
> Billy Brown, MCSE+I
> bbrown@conemsco.com
I'm on of the web administrator for the extropy site. If
anyone puts together some html pages, sends them to me, and recommends
where they be linked in, and there are no objections form Max or
anyone else about such additions, I'm always happy to put them on the
server. I'm sure we have the space for something like this. As
usual, the big problem is having someone put together the actual html
content.
Personally, I'd like some kind of system where we accumulate
knowledge about such issues and make progress. I've written what I
call an IFAQ system for interactive FAQ system. Here is a description
of the system. Let me know what you think and if you'd like to see
something like this set up for this list.
Brent Allsop
============================================================================
-- Some prose about interactive FAQ server philosophy: --
----------------------------------------------------------------------------
-- Two Types of FAQs --
There are two types of questions asked in notes groups: ones
with uncontroversial answers such as the ones contained in the
sci.physics FAQ and ones with controversial answers. Some questions
seem to have more answers than there are people on the net. FAQs
maintained by single people or groups of people such as the one in
sci.physics are very good at maintaining a database of uncontroversial
answers to question with such. These databases of uncontroversial
answers obviously provide a great service to people reading notes
groups. It keeps the number of repeated questions with repeated
answers posted to notes to a minimum while still providing great
information to readers with questions.
-- Non Consensus is the Real Problem. --
There is a far greater problem with questions that have many
apposing controversial answers. No single person or even a group of
people can ever hope to have the band width required to accurately
represent every position desired by the many people with very strong
diverse beliefs about such FAQs. A good example of such a question
is: "Is there a God?" At least with questions that have
uncontroversial answers the worst that can happen is that someone will
ask a question that is constantly asked; someone will give an
erroneous answer; several people will post a correction to the
erroneous answers; and finally someone will add the better version of
the right answer to a FAQ. With questions that only have controversial
answers some brave benevolent soul will post a very good answer with
some very good supporting arguments. Then everyone and their dog
seems to be compelled to put forth their own answer (like a vote) as
if it is required for the salvation of the asker (it IS right? ;).
Finally after 100 or more heated flaming responses the string
typically degenerates into everyone calling everyone else something
that is bad that pertains to the particular notes group. (A machine
that doesn't pass the Turing Test in comp.ai.philosophy; A weiner dog
in alt.pets.dogs;) A Christian in alt.atheism, An atheist in
alt.christnet... ) This same flaming discussion will occur on a
regular cycle time depending on the average history setting on the
notes readers of the group. The same arguments being presented again
and again in a very unorganized inefficient fashion.
-- Purpose of Interactive FAQ Server --
The purpose of this interactive FAQ server is to organize and
hopefully make more efficient this process of conversion,
communication, and supporting positions. It is to organize people
with similar views into teams that can work together to better
communicate their views to other readers of the group. It is to more
easily communicate which positions have a consensus and which ones
don't. (Does the quality of a cable carrying digital audio
information improve the quality of the sound? ;) It is very difficult
to research and find out which answers to questions have a consensus
among experts in the literature since most published material only has
one or a few authors (and hence only one "vote"). One must become an
expert themselves and survey most of the literature before being able
to accurately determine such. Hopefully this interactive FAQ server
will make it easier for non experts to see which answers have a
consensus and which ones don't. Of course if all the experts support
one position (i.e. free agency IS compatible with determinism? ;) and
all the "lay" populace support an apposing position it is still up to
the reader of the FAQ to determine which supporters are experts and
which are not since anyone can be a supporter and/or a submitter.
-- Organized Team Work --
When you submit your name as a supporter of a particular
response to a FAQ (a valid e-mail address must be included to do
such.) you should consider yourself joining a team. Everyone on the
team should work to better communicate the team's view to others with
the ultimate, idealistic goal of converting others and having your
team become the one with clearly the most popular response. (This
idealistic goal can also be achieved by abandoning poor positions. ;)
If the team comes up with more evidence or recognizes a better,
shorter, more concise way to state a position such that it has more
conversion, and communication power, a member should submit the new
version of the position and everyone on the team should change their
support to that better written response. Hopefully a submitter of a
new response will have their answer reviewed and get a significant
list of people that will agree to support the response (You can only
support one position per FAQ.) before submitting the response.
Posting a call for supporters in notes or e-mailing to supporters of a
current response are good ways to find supporters or converts. Only
very brave people will be the sole supporter of a response. If a
response has no supporters at all it will eventually be removed from
the database via the sorting process. If you are a supporter of an
unpopular position you should expect to receive e-mail or at least
posts in the group directed at you trying to win you over to more
popular positions since having lots of responses (especially similar
ones) will tend to make a mess of the FAQ database.
-- Popularity isn't Proof! --
Obviously popularity of any particular response doesn't prove
that the response is the best or worst response. If someone really
believes that they're position is right and are the only one that
believes such they should be brave enough to be the only (or minority)
supporter of a response. Hopefully people like this have good reasons
for such and can communicate this in their response. If they are
right, some day someone will find more evidence that converts more
people to that team. Such early courageous members of a minority team
that becomes a popular team will probably be considered "heros" of
that team.
-- Sorting and Posting --
An automatic process can be set up to automatically run a sort
on the database and then post a default report of the newly sorted
database to the notes group. It will become the FAQ for the group.
This will probably be at intervals of around one month. It is up to
each individual notes group to decide the frequency of such. This
sorting process will sort questions and responses according to how
much support they have. The support of a question is the sum total of
supporters of all it's responses. Questions and Responses with no
supporters will be removed entirely from the database when sorted.
Each sorting will increment the dbVersion number. Submittals that
refer to questions and responses with numbers will require a proper
'dbVersion:' number to insure that an incorrect earlier number of a
question or response isn't being used. Reports include the current
dbVersion. Make sure the numbers you use to reference FAQs and
responses are the currently correct ones and not ones from a report
from some previous sorting!
-- Honor system will make it work --
Before submitting anything please check to see if what you
want to consider your name is already being used. This can be done by
submitting a 'Change-name:' command with your desired name as both the
'Old-name:' and 'New-name:' value. This will return a report of every
existence of the name. If someone is already using your name come up
with some differentiating version (besides case) that makes your's
unique. Also, once you chose a name don't continually change it or
use different versions. The faq server is case insensitive. Remember
you can only support one Response per FAQ and a unique name, not
including case, is important for this process to work.
Having a valid e-mail address with a submitted supporter is
important for the "team" to be able to work together and is therefore
required. When you submit support there is no formal check to verify
that the e-mail address you submit is valid. If anyone discovers that
the e-mail address of a supporter is not valid an administrator should
be notified and the offending entry should be removed from the
database.
Obviously anyone can cause great problems and mess up this
process. If your going to participate please make an attempt to be a
good citizen and work to improve the FAQ. If you have any suggestions
as to how to improve this process, or notice what you think is a
defect in the server, I'd love to hear about it. (And feel free to
send any great FAQ maintainers $35 if you greatly benefit from their
efforts! ;) ;) ;) Don't you think they deserve it? I "vote" for
professional FAQ maintainers. ;)
Good luck and happy converting!
============================================================================
--- Interactive FAQ server HELP file. ---
============================================================================
This file contains a description of how to use the interactive
FAQ server (intfaqserv program). It contains a description of the
textual commands that can be e-mailed to an operating intfaqserv
program. It has 3 sections:
1 Typical major commands indicating required sub commands:
2 Some prose about interactive FAQ server philosophy:
3 Alphabetical listing of commands with descriptions:
The first section contains a few template like examples of
common commands. Pick out the command you want from the list of 4
things below and see this section for a template of the required sub
commands. If your going to submit a question, a response, or support
for a response please read section 2 first. Section 3 is primarily
for a reference of all commands. Here is a list of the primary things
you can do with the associated major command:
Get a current report: 'Report:'
Submit a question: 'Submit-question:' *
Submit a response: 'Submit-response:' *
"vote" for a response: 'Submit-support:' *
* There are several required sub commands for these commands.
In order to submit a FAQ you must at the same time submit a response
and have the associated initial supporter of that response; And
similarly In order to submit a response you must have an initial
supporter. See below for more detail about required sub commands and
example templates for major commands. Don't forget the ':' at the end
of each command.
============================================================================
Typical major commands indicating required sub commands:
----------------------------------------------------------------------------
Help:
This 'Help:' command has no subcommands and simply responds by
returning this help file.
----------------------------------------------------------------------------
Report:
This 'Report:' command is the standard way to get the FAQ in
it's standard current form. This default version doesn't include any
unsupported questions, responses, or traitors.
----------------------------------------------------------------------------
Report:
FAQ: all
Response: all
Names: all
Reply-to: allsop@hpfcla.fc.hp.com
This version of the 'Report:' command will give you all the
information contained in the FAQ database. The optional 'Reply-to:'
command indicates that the response should be sent to
allsop@hpfcla.fc.hp.com and not the return value specified in the
e-mail header. The 'Reply-to:' command may be included in any e-mail
command. Some e-mail sending programs may use an e-mail header format
for which the intfaqserv program can not find a return e-mail address.
In this case a 'Reply-to:' command is required.
----------------------------------------------------------------------------
Submit-support:
dbVersion: 1 <- required!
Question-number: 2 <- required!
Response-number: 1 <- required!
Supporter: (Brent Allsop) <allsop@fc.hp.com> <- required!
This 'Submit-support:' command has all the required
subcommands and will submit (Brent Allsop) with an e-mail address of
<allsop@fc.hp.com> to response #1 of FAQ #2. If (Brent Allsop) or
someone with that name is supporting another response to this question
they will be moved to the traitor list for that response. This is why
having a unique name is important. If you are submitting anything be
sure you have a unique name. (see 'Name-change:' command about how to
do this.) Remember that this FAQ server is not sensitive to case.
Remember to put ()s around names and <>s around addresses.
----------------------------------------------------------------------------
Remove-support:
dbVersion: 1 <- required!
Question-number: 2 <- required!
Response-number: 1 <- required!
Supporter: (Brent Allsop) <allsop@fc.hp.com> <- required!
This 'Remove-support:' command has all the required
subcommands and will remove (Brent Allsop) from the supporter list of
response #1 of FAQ #2 and add him to the traitor list of the response.
----------------------------------------------------------------------------
Submit-question:
Supporter: (Brent Allsop) <allsop@fc.hp.com> <- required!
Question-text: <- required!
Is a dbVersion required to submit a question?
End-text
Question-author: (Malia Allsop) <m_allsop@fc.hp.com>
Response-text: <- required!
I don't know.
End-text
Response-author: (Brent Allsop) <allsop@fc.hp.com>
This 'Submit-question:' command submits the question: "Is a
dbVersion required to submit a question?" with the response: "I don't
know.". It is pointless to have a question without a response so an
initial answer is required (along with a supporter) to be submitted
with a question. If the optional Author commands are not given the
values are taken from the required 'Supporter:' sub command. An
"Empty" author command with no values may be given if author anonymity
is desired. ('End-text' cannot have any space before it and is only
this way here for ease of reading.)
----------------------------------------------------------------------------
Submit-response:
dbVersion: 1 <- required!
Supporter: (Brent Allsop) <allsop@fc.hp.com> <- required!
Question-number: 2 <- required!
Response-text: <- required!
No. A dbVersion is not required.
to submit a question.
end-text
Response-author:
This 'Submit-response:' command submits the response: "No. A
dbVersion is not required." to FAQ #2. An initial supporter value is
required. The "empty" 'Response-author:' command results in a nill or
anonymous author value. If an author command is left off completely
the values for the required 'Supporter:' sub command are used.
('End-text' cannot have any space before it and is only this way here
for ease of reading.)
----------------------------------------------------------------------------
Change-name:
Old-name: (Brent Allsop) <allsop@fc.hp.com> <- required
New-name: (Brent Allsop) <allsop@hpfcla.fc.hp.com> <- required
This 'Change-name:' command is for changing the name and/or
address of an entry. If the 'Old-name:' values match identically, not
counting case differences, the old values are replaced with the
New-name: values in the database. The subcommands used to control the
'Report:' command may also be used here. However, the default value
for the Change-name: command is to change all matching names not just
values in supported entries like the default 'Report:' command. A
report of each replacement and a total number of replacements is
returned.
----------------------------------------------------------------------------
Change-name:
Old-name: (Brent Allsop) <allsop@fc.hp.com> <- required
New-name: (Brent Allsop) <allsop@hpfcla.fc.hp.com> <- required
FAQ: 2
Response: 3
Names: supported
This version of 'Change-name:' will only change the author of
FAQ #2 and Response #3 and any supporters of this response with a
matching name and address.
----------------------------------------------------------------------------
; checking for a unique name.
Change-name:
Old-name: (Brent Allsop) <allsop@fc.hp.com> <- required
New-name: (Brent Allsop) <allsop@fc.hp.com> <- required
The 'Change-name:' command with identical 'Old-name:' and
'New-name:' values returns a report of every existence of the name and
address. Remember this server does not distinguish between case of
letters. If you are submitting for the first time you must use this
command first to be sure your name is unique. Once you pick a name
that isn't already used always use that name.
============================================================================
Alphabetical listing of commands with description:
----------------------------------------------------------------------------
Change-name:
This command is used to change author and supporter name and
address values. If the values in the 'Old-name:' match
identically (other than case differences) the 'New-name:'
values will replace them. This command can also be used to
check for a unique name and address combination by having the
'Old-name:' and 'New-name:' values identical. The number of
name changes along with which name changes is returned in a
report. "+Report control" commands can be used in a similar
fashion to the 'Report:' command to specify particular names
to change. The default value, however, is everything
including unsupported and traitor entries unlike the 'Report:'
command which defaults to only includes supported entries and
supporters. In other words if no "+Report control" commands
are given all identical matches with 'Old-name:' values are
changed to 'New-name:' values.
dbVersion:
Every time the FAQ database is sorted a new dbVersion number
is stored with the Database. Major commands which reference
specific FAQs and/or Responses must include this command and
the number must match the value stored in the current
database. The command will fail otherwise. Each report
produced by the 'Report:' command indicates the dbVersion
value when the report was generated. This is a global command
so only one dbVersion is required per e-mail submittal.
So this is more like a *major command and, unlike other
'sub commands', may appear before other *major commands.
+FAQ: <support indicator>
There can be more than one of these per 'Report:' command.
See <support indicator> specifications below.
*Help:
This command will return a copy of this file.
Names: <support indicator>
The <support indicator> indicates which lists of names
(supporters, traitors, none[0] or all) to include in the
report. A single number <support indicator> is not valid
here. See <support indicator> specifications below.
New-name: (name) <e-mail address>
This is a 'Change-name:' sub command. Everything within the
'()'s is taken as the name value and everything withing the
'<>'s is taken as the e-mail address value. See
'Change-name:' for more info.
Old-name: (name) <e-mail address>
This is a 'Change-name:' sub command. Everything within the
'()'s is taken as the name value and everything withing the
'<>'s is taken as the e-mail address value. See
'Change-name:' for more info.
Question-author: (name) <e-mail address>
This command indicates the author of the question being
submitted. Everything within the '()'s is taken as the name
value and everything withing the '<>'s is taken as the e-mail
address value. This command is optional and if not included
the 'Supporter:' values will be used. If anonymity is desired
the command may be included with no values. See 'Supporter:'
for more details.
Question-number: #
This command indicates which FAQ the major command will apply
to.
Question-text:
Everything following this command until a 'End-text' at the
beginning of a line is taken as the question text. Each line
must be less than 80 characters in length and there can't be
an 'End-text' string at the beginning of any line in the
actual text since such will be the end of the command.
*Remove-support:
If you are not a supporter of the specified response to a FAQ
the command will fail. If the 'Supporter:' is a supporter of
the specified response then the name and address will be moved
to the traitor list of the response. 'dbVersion:',
'Question-number:', 'Response-number:', and 'Supporter:'
are all required sub commands.
Reply-to: <e-mail address>
This 'Reply-to:' command specifies which e-mail address
the response should be sent to. If not given the
"Reply-to:", "From:", or "from" value in the e-mail header
are used in this order. Some e-mail sending programs may use
an e-mail header format for which the intfaqserv program can
not get a proper return e-mail address. In this case a
'Reply-to:' command would be required. This command can be
included with any command.
*Report:
This command returns a FAQ report. With no "report control"
commands (indicated with +) a default report will be generated
including supported questions, responses, and the associated
supporters. "Report control" commands (see below) are
required to get unsupported answers, responses, and traitor
information.
+Response: <support indicator>
This command can be repeated more than once for each 'FAQ:'
command. See <support indicator> specifications below.
Response-author: (name) <e-mail address>
This command indicates the author of the response being
submitted. Everything within the '()'s is taken as the name
value and everything withing the '<>'s is taken as the e-mail
address value. This command is optional and if not included
the 'Supporter:' values will be used. If anonymity is desired
the command may be included with no values. See 'Supporter:'
for more details.
Response-number: #
This command indicates which Answer the major command will
apply to.
Response-text:
Everything following this command until a 'End-text' at the
beginning of a line is taken as the response text. Each line
must be less than 80 characters in length and there can't be
an 'End-text' string at the beginning of any line.
*Submit-question:
This command submits a FAQ, a response, and the associated
'Supporter:' of the response. 'Supporter:', 'Question-text:',
and 'Response-text:' are required sub commands.
'Question-author:', and 'Response-author:' are optional
commands.
*Submit-response:
This command submits a response to a FAQ with the associated
supporter. 'dbVersion:', 'Supporter:', 'Question-number:' and
Response-text are required sub commands. 'Response-author:'
is an optional sub command.
*Submit-support:
This command adds the 'Supporter:' name and address to the
supporter list of the 'Response-number:' response of the
'Question-number:' FAQ. 'dbVersion:', 'Question-number:',
'Response-number:' and 'Supporter:' are required sub commands.
Supporter: (name) <e-mail address>
This command specifies the supporters name (everything within
the '()'s and e-mail address (everything within the '<>'s
for the associated major command. Remember to use consistent
values here that don't conflict with other peoples names. A
good way to check if your name is unique is to submit a
'Change-name:' command with identical 'Old-name:' and
'New-name:' values.
To:
Same as 'Reply-to:'.
Traitor: (name) <e-mail address>
Similar to 'Supporter:'.
* This indicates a major command. Most other other commands
must appear in the context of (or after) a major command.
+ This indicates a "report control" sub command and must appear
after a 'Report:' command or a 'Change-name:' command. The
"report control" commands are: 'FAQ:', 'Response:', and
'Names:'. They use <support indicator> values to control
which entries are visited for reporting or name changing.
<support indicator> values:
All: Both supported and unsupported (traitor) entries.
Supported: Only supported entries.
Unsupported: Only un supported (traitor) entries.
<positive #> Indicates single question or response.
Not valid as a value for the 'Names:' command.
0 Neither supported nor unsupported (traitor) entries.
+Report control commands BNF:
[ Report: | Change-name:
[ FAQ: [ All | Supported | Unsupported | 0 | <positive #> ]
[ Response: [ All | Supported | Unsupported | 0 | <positive #> ]
[ Names: [ All | Supported | Unsupported | 0] ] ]* ]* ]*
============================================================================
Alphabetical listing of commands with description:
----------------------------------------------------------------------------
Change-name:
This command is used to change author and supporter name and
address values. If the values in the 'Old-name:' match
identically (other than case differences) the 'New-name:'
values will replace them. This command can also be used to
check for a unique name and address combination by having the
'Old-name:' and 'New-name:' values identical. The number of
name changes along with which name changes is returned in a
report. "+Report control" commands can be used in a similar
fashion to the 'Report:' command to specify particular names
to change. The default value, however, is everything
including unsupported and traitor entries unlike the 'Report:'
command which defaults to only includes supported entries and
supporters. In other words if no "+Report control" commands
are given all identical matches with 'Old-name:' values are
changed to 'New-name:' values.
dbVersion:
Every time the FAQ database is sorted a new dbVersion number
is stored with the Database. Major commands which reference
specific FAQs and/or Responses must include this command and
the number must match the value stored in the current
database. The command will fail otherwise. Each report
produced by the 'Report:' command indicates the dbVersion
value when the report was generated. This is a global command
so only one dbVersion is required per e-mail submittal.
So this is more like a *major command and, unlike other
'sub commands', may appear before other *major commands.
+FAQ: <support indicator>
There can be more than one of these per 'Report:' command.
See <support indicator> specifications below.
*Help:
This command will return a copy of this file.
Names: <support indicator>
The <support indicator> indicates which lists of names
(supporters, traitors, none[0] or all) to include in the
report. A single number <support indicator> is not valid
here. See <support indicator> specifications below.
New-name: (name) <e-mail address>
This is a 'Change-name:' sub command. Everything within the
'()'s is taken as the name value and everything withing the
'<>'s is taken as the e-mail address value. See
'Change-name:' for more info.
Old-name: (name) <e-mail address>
This is a 'Change-name:' sub command. Everything within the
'()'s is taken as the name value and everything withing the
'<>'s is taken as the e-mail address value. See
'Change-name:' for more info.
Question-author: (name) <e-mail address>
This command indicates the author of the question being
submitted. Everything within the '()'s is taken as the name
value and everything withing the '<>'s is taken as the e-mail
address value. This command is optional and if not included
the 'Supporter:' values will be used. If anonymity is desired
the command may be included with no values. See 'Supporter:'
for more details.
Question-number: #
This command indicates which FAQ the major command will apply
to.
Question-text:
Everything following this command until a 'End-text' at the
beginning of a line is taken as the question text. Each line
must be less than 80 characters in length and there can't be
an 'End-text' string at the beginning of any line in the
actual text since such will be the end of the command.
*Remove-support:
If you are not a supporter of the specified response to a FAQ
the command will fail. If the 'Supporter:' is a supporter of
the specified response then the name and address will be moved
to the traitor list of the response. 'dbVersion:',
'Question-number:', 'Response-number:', and 'Supporter:'
are all required sub commands.
Reply-to: <e-mail address>
This 'Reply-to:' command specifies which e-mail address
the response should be sent to. If not given the
"Reply-to:", "From:", or "from" value in the e-mail header
are used in this order. Some e-mail sending programs may use
an e-mail header format for which the intfaqserv program can
not get a proper return e-mail address. In this case a
'Reply-to:' command would be required. This command can be
included with any command.
*Report:
This command returns a FAQ report. With no "report control"
commands (indicated with +) a default report will be generated
including supported questions, responses, and the associated
supporters. "Report control" commands (see below) are
required to get unsupported answers, responses, and traitor
information.
+Response: <support indicator>
This command can be repeated more than once for each 'FAQ:'
command. See <support indicator> specifications below.
Response-author: (name) <e-mail address>
This command indicates the author of the response being
submitted. Everything within the '()'s is taken as the name
value and everything withing the '<>'s is taken as the e-mail
address value. This command is optional and if not included
the 'Supporter:' values will be used. If anonymity is desired
the command may be included with no values. See 'Supporter:'
for more details.
Response-number: #
This command indicates which Answer the major command will
apply to.
Response-text:
Everything following this command until a 'End-text' at the
beginning of a line is taken as the response text. Each line
must be less than 80 characters in length and there can't be
an 'End-text' string at the beginning of any line.
*Submit-question:
This command submits a FAQ, a response, and the associated
'Supporter:' of the response. 'Supporter:', 'Question-text:',
and 'Response-text:' are required sub commands.
'Question-author:', and 'Response-author:' are optional
commands.
*Submit-response:
This command submits a response to a FAQ with the associated
supporter. 'dbVersion:', 'Supporter:', 'Question-number:' and
Response-text are required sub commands. 'Response-author:'
is an optional sub command.
*Submit-support:
This command adds the 'Supporter:' name and address to the
supporter list of the 'Response-number:' response of the
'Question-number:' FAQ. 'dbVersion:', 'Question-number:',
'Response-number:' and 'Supporter:' are required sub commands.
Supporter: (name) <e-mail address>
This command specifies the supporters name (everything within
the '()'s and e-mail address (everything within the '<>'s
for the associated major command. Remember to use consistent
values here that don't conflict with other peoples names. A
good way to check if your name is unique is to submit a
'Change-name:' command with identical 'Old-name:' and
'New-name:' values.
To:
Same as 'Reply-to:'.
Traitor: (name) <e-mail address>
Similar to 'Supporter:'.
* This indicates a major command. Most other other commands
must appear in the context of (or after) a major command.
+ This indicates a "report control" sub command and must appear
after a 'Report:' command or a 'Change-name:' command. The
"report control" commands are: 'FAQ:', 'Response:', and
'Names:'. They use <support indicator> values to control
which entries are visited for reporting or name changing.
<support indicator> values:
All: Both supported and unsupported (traitor) entries.
Supported: Only supported entries.
Unsupported: Only un supported (traitor) entries.
<positive #> Indicates single question or response.
Not valid as a value for the 'Names:' command.
0 Neither supported nor unsupported (traitor) entries.
+Report control commands BNF:
[ Report: | Change-name:
[ FAQ: [ All | Supported | Unsupported | 0 | <positive #> ]
[ Response: [ All | Supported | Unsupported | 0 | <positive #> ]
[ Names: [ All | Supported | Unsupported | 0] ] ]* ]* ]*
This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 15:03:14 MST