RE: META: Frequently Debated Topics

Brent Allsop (allsop@swttools.fc.hp.com)
Thu, 4 Mar 1999 09:33:50 -0700

> 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


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!


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] ]    ]*    ]*    ]*