DTS-0001 proposed standard

T0FG

unread,

Jan 24, 1993, 12:35:26 AM1/24/93

to

Proposed DTS-0001 0.07 beta standard follows:

| - Will Burrow
| Internet: t0...@unb.ca
| wi...@p1.f14.n255.z1.fidonet.org)
| Fidonet: 1:255/14.1
`--------------------------------------------------------------------
+-----------------------------------------------------------------------+
| Document: DTS-0001 (Doorware Technical Standard doc 0001) |
| Version: 0.07 beta |
| Date: January 14, 1992 |
+-----------------------------------------------------------------------+

I. NOTES ABOUT THIS DOCUMENT

Any line in the DTS-0001 document beginning with a | means that it is
an update from the previous version.

Any line in the DTS-0001 document beginning with a * means that it is
currently under debate.

This document is put together in the attempt to establish a standard
file format for information to be passed between BBS software and BBS
doorware. Please leave comments about missing (non-board specific)
information or settings that require ammendment. This can only be a
standard if everyone agrees upon its contents. Please contribute.

The file that these settings appear in should be called DROPFILE.###
where ### represents the node which is creating the dropfile. For
example Node 1 would create DROPFILE.001. The dafault filename for
single node BBS is DROPFILE.001.

If the users information is changed by the door called with the
DROPFILE file, these changes should be written to a new file called
CHANGES.### where ### represents the node which is going to read in
the changes and alter the users account. This file is optional. It is
only intended for those BBS's which support bidirectional information
to be passed between the board and doors.

It should be assumed that any door requiring this file will find it
in the default BBS directory (thus you must tell the door where it
is.)

Doorware authors using this format should include a freeware copy of
a dropfile conversion utility that will convert other dropfile files
to the DTS-0001 format. This utility is as yet undeveloped. If
people would supply me with other dropfile standards, I could start
compiling a list and shall write this program for DOS based machines.

The information being passed from BBS software and doors should be in
the following format. These configuration settings should not be
limited to appear in the dropfile in any specific sequence.

Settings found in DROPFILE.### should not be required. There should
be developed a list of default settings for each entry.

II. STANDARD DATA VALUES

Some standard formats are proposed for information appearing inside
the DROPFILE.### file. These are:

| Phone numbers: <country>-<area>-<exchange>-<number>
| This is the format adopted by the Fidonet standard and is
| used in many applications.
|
| Dates: <month>/<day>/<year>
| The year should be expressed as a four digit quantity due to
| the impending year 2000. Month ranges from 0 and 12, day ranges
| from 1 to 31, and year ranges from 0 to 32767 <g>.
|
| Times: <hour>:<minute>
| expressed in 24 hour format. Hour ranges from 0 to 23 and
| minute ranges from 0 and 59.
|
| Time till/left: <minutes>
| All time until and time left commands should be expressed in
| minutes. Minutes range from 0 to 32767.
|
| Net addresses: <zone>:<net>/<node>.<point>@<organization>
| Expressed as a 5d net address including the zone, network,
| node, optional point, and optional organization. These values
| (except the organization of course) have values between 0 and
| 32767.
|
| File sizes: <kilobytes>
| Expressed in number of kilobytes. Kilobytes range from 0 to
| 2147483647 (signed long).
|
| Ons and offs: <n|0>
| Expressed as the value n or 0 for ON or OFF whereas n is any
| non-zero value.
|
| Modes: <mode1> [,<mode2>...]
| The display modes supported by the user are as follows (one or
| more of these may appear separated by commas):
|
| Key Description
| ----------- ---------------------------------------
| ANSI (use ANSI codes)
| AVATAR (use Avatar codes)
| VT100TAB (use VT100 tab codes)
| VT102 (use VT102 codes)
| VT52 (use VT52 codes)
| YALE (use YALE BBS codes)
| CBM (use Commodore set)
| IBM (use IBM set)
| HIGH (accept high bit ascii / don't remap)
| TTY (don't accept high bit ascii / remap)
| ETGC (ETGC graphics protocol)
| NAPLPS (NAPLPS graphics protocol)
| COLOR (use color information)
| MONO (use monochrome information)
|
| Protocols: <protocol>
| The protocols are defined below. These are expressed as a string
| not more than 16 characters in length.
|
| Protocol Description
| ----------- ---------------------------------------
| CISB CompuServe B-Modem
| JMODEM J-Modem protocol
| KERMIT Kermit
| TELINK Telink
| XMODEM X-Modem
| XMODEM1K X-Modem 1k
| YMODEM Y-Modem
| YMODEMG Y-Modem G
| ZMODEM Z-Modem
| ZMODEMCRC Z-Modem CRC
| ZMODEMRR Z-Modem Recover/Resume
|

III. CONFIGURATION SETTING

All the information found in the DTS-0001 style drop file is in the
format LABEL = DATA. The infomation may appear in any order. The
settings are not columnated (equal sign does not appear in the same
place all the time).

A. System configuration settings (one for each node):

BOARD = <board name>
| Description: This setting contains the name of the BBS.
| Range: String not more than 32 character in length.
| Example: BOARD = Any ol' BBS

SOFTWARE = <bbs software tag>
| Description: This setting briefly describes the bbs software
| creating the dropfile.
| Range: String not more than 32 character in length.
| Example: SOFTWARE = TAG BBS 2.6c9z gamma

NETADDRESS = <node address [, node address ...]>
| Description: This setting lists the fido-type net addresses
| for the system.
| Range: As per FTS-0005.
| Example: NETADDRESS = 1:234/567.8, 75:1234/56

MAXSECURITY = <maximum security level of node>
| Description: This setting contains the maximum security level
| used by the BBS. In most cases, this value will
| be identical to the SysOp's security level.
| Range: 0 - 2,147,483,647 (signed long integer)
| Example: MAXSECURITY = 255

SYSOP = <sysops name>
| Description: This setting contains the name of the SysOp.
| Range: String not more than 32 characters in length.
| Example: SYSOP = John Q. Public

MAXBAUD = <maximum baud of node>
| Description: This setting contains the maximum baud rate for
| this node. This is the maximum baud of the modem
| or the rate at which the modem is locked at.
| Range: 0 - 2,147,483,647 (signed long integer)
| Example: MAXBAUD = 38400

DATABITS = <databits>
| Description: This setting contains the number of databit the
| communications port is using.
| Range: 7 or 8 (signed integer).
| Example: DATABITS = 8

PARITY = <parity>
| Description: This setting contains the parity type that the
| communications port is using.
| Range: String containing N, E, O, M, or S.
| Example: PARITY = N

STOPBITS = <stopbits>
| Description: This setting contains the number of stopbit the
| communications port is using.
| Range: 0, 1, or 2 (signed integer).
| Example: STOPBITS = 0

NEXTEVENT = <minutes until next event>
| Description: This setting contains the number of minutes until
| the next system event.
| Range: 0 - 32767 (signed integer)
| Example: NEXTEVENT = 90

B. User configuration settings (one for each user):

USER = <users name>
| Description: This setting contains the name of the user.
| Range: String not more than 32 characters in length.
| Example: USER = John Dough

USERAKA = <users handle>
| Description: This setting contains the handle or AKA of the
| user.
| Range: String not more than 32 characters in length.
| Example: USERAKA = File Monger

ORIGIN = <users origin>
| Description: This setting contains the city/state from where
| the user is calling.
| Range: String not more than 32 characters in length.
| Example: ORIGIN = Lake Placid, NY

VOICEPHONE = <users voice number>
| Description: This contains the users voice telephone number.
| Range: As per FTS-0005.
| Example: VOICEPHONE = 1-518-555-1234

DATAPHONE = <users data number>
| Description: This contains the users data telephone number.
| Range: As per FTS-0005.
| Example: DATAPHONE = 1-518-555-9876

PASSWORD = <users password>
| Description: This setting contains the users system password.
| Range: String not more than 32 characters in length.
| Example: PASSWORD = QWERTY

SECURITY = <users security level>
| Description: This setting contains the security level of the
| user.
| Range: 0 - 2,147,483,647 (signed long integer)
| Example: SECURITY = 30

CALLS = <total calls by user>
| Description: This setting contains the total number of calls
| to the bbs the user has made to date.
| Range: 0 - 32,767 (signed integer)
| Example: CALLS = 135

LASTCALLED = <date of last call>
| Description: This setting contains the date of the users last
| call to the bbs.
| Range: (see formats above : Dates)
| Example: LASTCALLED = 12/31/1999

LASTTIME = <time of last call>
| Description: This setting contains the time at which the user
| logged off the bbs during his/her last call.
| Range: (see formats above : Times)
| Example: LASTTIME = 23:45

THISTIME = <time of this call>
| Description: This setting contains the time at which the user
| logged onto the bbs during this call.
| Range: (see formats above : Times)
| Example: THISTIME = 14:02

HEIGHT = <users screen rows per page>
| Description: This setting contains the number of rows the
| users screen is configured with.
| Range: 1 - 32767 (signed integer).
| Example: HEIGHT = 24

WIDTH = <users screen row width>
| Description: This setting contains the number of columns the
| users screen is configured with.
| Range: 1 - 32767 (signed integer).
| Example: WIDTH = 132

EXPIRES = <account expiration date>
| Description: This setting contains the date when the users
| account on the bbs will expire.
| Range: (see formats above : Dates)
| Example: EXPIRES = 12/31/1999

PROTOCOL = <users protocol of choice>
| Description: This setting contains the upload/download
| protocol of choice for the user.
| Range: (see formats above : Protocols)
| Example: PROTOCOL = ZMODEM

UPLOADS = <users total number of uploads>
| Description: This setting contains the total number of uploads
| the user has made toward the bbs.
| Range: 0 - 32767 (signed integer)
| Example: UPLOADS = 156

DOWNLOADS = <users total number of downloads>
| Description: This setting contains the total number of
| files the user has downloaded from the bbs.
| Range: 0 - 32767 (signed integer)
| Example: DOWNLOADS = 21

DOWNLOADMAX = <users download maximum K>
| Description: This setting contains the maximum number of
| kilobytes of files the user may download from
| the bbs before being restricted in some manner.
| Range: (see formats above : File sizes)
| Example: DOWNLOADMAX = 875

BIRTHDAY = <users bithdate>
| Description: This setting contains the users date of birth.
| Range: (see formats above : Dates)
| Example: BIRTHDAY = 4/21/1960

C. Special request commands

REQFILE = <file name>[, <file name>...]
| Description: This setting contains one or more files that
| the user is requesting for download.
| Range: String not more than 64 characters in length.
| Example: REQFILE = c:\bbs\files\textdoc.zip

REQFILES = <files filelist name>
| Description: This setting contains the name of a file which
| contains a list of files that the user is
| requestiong for download.
| Range: String not more than 64 characters in length.
| Example: REQFILES = c:\bbs\filelist.txt

D. Message handling commands

MSGAREA = <text description of message area replying to>
| Description: This setting describes the area to where the
| message is going to be posted in.
| Range: String not more than 32 characters in length.
| Example: MSGAREA = DoorWare Echo (FidoNet)

REPLYINGTO = <name of person replying to>
| Description: This setting contains the name of the person
| to whom the message is in respond to.
| Range: String not more than 32 characters in length.
| Example: REPLYINGTO = Margaret Thompson

REPLYTOPIC = <topic reply is about>
| Description: This setting contains the topic or subject
| to which the message is being made.
| Range: String not more than 32 characters in length.
| Example: REPLYTOPIC = Those long stringy thing?

QUOTEFILE = <file containing message replying to>
| Description: This setting contains the file that contains
| the text to which the message can be quoted from.
| Range: String not more than 64 characters in length.
| Example: QUOTEFILE = c:\bbs\quote.txt

REPLYFILE = <file that will contain new message>
| Description: This setting contains the file that will contain
| the newly created message.
| Range: String not more than 64 characters in length.
| Example: REPLYFILE = c:\bbs\message.txt

Please contribute to this proposal. I will attempt to ammend and
append ideas and will repost updated docs as soon as they become
available to me.

Chris Petrilli

unread,

Jan 24, 1993, 11:05:53 AM1/24/93

to

[ Narrow-minded DOS drivel deleted. ]

While I think that there is an excellent concept in standardizing BBS
software so that it can talk to eachother, the document you sent out is
worthless to a large number of people. There are more people on Usenet
than on FideNet, so the mail addresses are useless. Why don't people
just use the standards that are already there.

Mail: RFC822 with MIME extensions for multi-media
News: RFC1032 with use of the "X-*" header extensions
Config file: Is it really that important?
Dates: Try the internaltional standards: DAY MON YEAR
Phone numbers: Same thing: ISO standard: +1 XXX XXX XXXX

Seems to me that this is creating yet another set of "standards" for use
by a group of people who are destined to exclude others. I honestly
can't use anything that is in the document because it flies in the face
of the standards that I use daily (ie, Internet standards and
International standards) Seems to me that the intellegent thing to do
would be to adopt these standards, and if you want to do something
useful, create a "document of documents" that could be used by others,
ie. a list of topics and the corresponding RFC or ANSI or whatever
document is appropriate. The one thing that NEEDS standardization is
user file maintanance. The system I'm writing uses a relational
database with "transaction processing" capability, but then I'm not
writing a "DOS BBS".

Remember, not everyone uses COMMAND.COM as their shell. (And thank gods
for small favors like that :-) Don't be so narrow in focus. The
Internet has developed a lot of standards and they've been tested,
implemented, and PROVEN interoperable with hundereds of thousands of
machines all over the world, why re-invent the wheel? Especailly when
the one you're inventing is square?

Chris
--
| Chris Petrilli ____
| petr...@gnu.ai.mit.edu ``Quayle is a bozoe.'' \ /
| I don't even speak for myself. \/

Mikael Cardell

unread,

Jan 24, 1993, 5:40:29 PM1/24/93

to

I fully agree with you concerning standards, but some thing in your
message seemed odd. Like your way of writing dates. The ISO stanard
dfor this is YYYYMMDD and, if intended for human readers, YYYY-MM-DD
not DAY MON YEAR as you suggested.

--
mikael cardell <car...@lysator.liu.se>

S P U N K P R E S S

T0FG000

unread,

Jan 25, 1993, 12:22:27 AM1/25/93

to

In article <1juep1...@life.ai.mit.edu> petr...@hal.gnu.ai.mit.edu (Chris Petrilli) writes:
>[ Narrow-minded DOS drivel deleted. ]
>
>While I think that there is an excellent concept in standardizing BBS
>software so that it can talk to eachother, the document you sent out is
>worthless to a large number of people. There are more people on Usenet
>than on FideNet, so the mail addresses are useless. Why don't people
>just use the standards that are already there.

Note: this is not an attempt to standardize BBS software! Only the
interface between BBS software and external programs. BBS software
design is intentionally left out of this document. Further, it is not
intended to restrict other means that the BBS and external software
may use to communicate with each other, only to provide one method that
is satisfactory for both BBS authors and door authors in a BBS-software
independent fashion.

This is one attempt to generate and support standards that do exist.
The document was created over the Fidonet system, and the standards
in place in that network obviously hold large sway in the document.
Personally, such issues as date format I have brought up already. I
am Canadian, and do not use the American month/day/year format
either. The issue with mail addresses supporting other networks is
an important one - since BBS systems that attempt to use this
interface will find the Fidonet format useless if they do not
themselves use Fidonet.

Note also, that the document does not set out ways in which to
create meaningful output -- that is up to the 'door' (software) that
reads the 'dropfile'. Systems that are integrated with respect to mail
functions or other utilities that do not require using an external
program will not need to generate the dropfile. The intention is to
provide an interface between the BBS software and the external
software. If data items are not required to be communicated between
the two pieces of software, they are ignored. (eg. the PORT datum
may well be useless under Unix, where the port is the terminal port
in use at the time. Under DOS, the port in use may be unknown.)
Should the 'external' software not be concerned with mail functions,
it would not need to know the address of the user.

So the possibility of tokens defined that are never used on a
particular system does exist, but is not intended to be a
limitation.

>
> Mail: RFC822 with MIME extensions for multi-media
> News: RFC1032 with use of the "X-*" header extensions
> Config file: Is it really that important?
> Dates: Try the internaltional standards: DAY MON YEAR
> Phone numbers: Same thing: ISO standard: +1 XXX XXX XXXX

>Seems to me that this is creating yet another set of "standards" for use
>by a group of people who are destined to exclude others.

The intention is to allow as many people and systems to use the
document as possible. The use of tokens instead of fixed position
data items is intended to allow the addition of further tokens as
required, while not in any way affecting backward compatibility.
Further, it is being created over networks, with the intention of
adding as many ideas as possible. This is its first foray into
Internet from Fidonet. I am sure there are more details that must
be considered when and if it makes its way to WWIVnet.

>I honestly
>can't use anything that is in the document because it flies in the face
>of the standards that I use daily (ie, Internet standards and
>International standards) Seems to me that the intellegent thing to do
>would be to adopt these standards, and if you want to do something
>useful, create a "document of documents" that could be used by others,
>ie. a list of topics and the corresponding RFC or ANSI or whatever
>document is appropriate. The one thing that NEEDS standardization is
>user file maintanance. The system I'm writing uses a relational
>database with "transaction processing" capability, but then I'm not
>writing a "DOS BBS".

Perhaps the application of this document is not relevant to your
situation at all. However, the problem of conflicting with current
standards is a problem. It is compliant with Fidonet standards as
well as other standards (for terminal type for example). As for
user file maintenance, this is a problem with DOS BBS authors...
door authors comply in this area to whatever the BBS author sets
out. Unfortunately in the area of BBS to door dropfiles, there are
several dozen formats, many with the same _name_, causing confusion
as to exactly what is expected.

>
>Remember, not everyone uses COMMAND.COM as their shell. (And thank gods
>for small favors like that :-) Don't be so narrow in focus. The
>Internet has developed a lot of standards and they've been tested,
>implemented, and PROVEN interoperable with hundereds of thousands of
>machines all over the world, why re-invent the wheel? Especailly when
>the one you're inventing is square?

In the DOS BBS world, the wheel is vaguely polygonal. Being square
is an advancement. :) The standard is not an attempt to interface
machines, it is solely a device that communicates with programs
'external' to the BBS software. I don't have a Unix BBS, so I am
unsure of what needs exist in that particular area. If you have
particular indications of Internet standards that define this area,
I would be pleased to see those as well. Before I go, I would like
to know where the repositary is for the RFC-* documents? The one
relevant to mail software may be required in order to correctly
implement Internet style addressing...

Thanks for your input,
Will.

---------------------------------------- William Burrow
Internet: t0...@unb.ca |
wi...@1.f14.n255.z1.fidonet.org |
Fidonet: 1:255/14.1 |

T0FG

unread,

Jan 25, 1993, 12:31:09 AM1/25/93

to

In article <C1Dqz...@lysator.liu.se> car...@lysator.liu.se (Mikael Cardell) writes:
>I fully agree with you concerning standards, but some thing in your
>message seemed odd. Like your way of writing dates. The ISO stanard
>dfor this is YYYYMMDD and, if intended for human readers, YYYY-MM-DD
>not DAY MON YEAR as you suggested.

I will raise the issue of date order again. I have since come
across ISO documents concerning the intentions of having the
YYYYMMDD format, and it would appear to be easy to implement the ISO
standard format in human readable format without breaking the
American (read non-Canadian) style proposed in that document.

That and the mail address and mail subject line issues. Of
particular interest to me, is how are mailers in the Unix
environment interfaced to BBS software (ie. how is the data
concerning user mail addresses, etc. handled?)

Chris Petrilli

unread,

Jan 25, 1993, 12:11:34 PM1/25/93

to

In article <25JAN93.01...@UNBVM1.CSD.UNB.CA> T0...@UNB.CA (T0FG000) writes:
>Note: this is not an attempt to standardize BBS software! Only the
>interface between BBS software and external programs. BBS software
>design is intentionally left out of this document. Further, it is not
>intended to restrict other means that the BBS and external software
>may use to communicate with each other, only to provide one method that
>is satisfactory for both BBS authors and door authors in a BBS-software
>independent fashion.

The problem I have is that it creates yet another set of "islands" in
the network that have to be interfaced. Given, those islands are
larger, but they are still islands. It would be better to ignore the
"operating system specific" concepts and go for REAL standards that are
usable by everyone rather than a subset. There's so much that is left
out of this document that it's difficult to use.

>This is one attempt to generate and support standards that do exist.
>The document was created over the Fidonet system, and the standards
>in place in that network obviously hold large sway in the document.
>Personally, such issues as date format I have brought up already. I
>am Canadian, and do not use the American month/day/year format
>either. The issue with mail addresses supporting other networks is
>an important one - since BBS systems that attempt to use this
>interface will find the Fidonet format useless if they do not
>themselves use Fidonet.

The best thing to do is just simply adopt the Internet standard which
will allow for almost anything on the face of the planet. The date
standard I mentioned is the european one, not the american one.

>In the DOS BBS world, the wheel is vaguely polygonal. Being square
>is an advancement. :) The standard is not an attempt to interface
>machines, it is solely a device that communicates with programs
>'external' to the BBS software. I don't have a Unix BBS, so I am
>unsure of what needs exist in that particular area. If you have
>particular indications of Internet standards that define this area,
>I would be pleased to see those as well. Before I go, I would like
>to know where the repositary is for the RFC-* documents? The one
>relevant to mail software may be required in order to correctly
>implement Internet style addressing...

RFCs and other Internet documents are available via anonymous FTP at
nic.ddn.mil. There's an index file there (there are currently 1400 RFCs
and several hundered Internet Drafts).

Bill Fenner

unread,

Jan 25, 1993, 12:29:46 PM1/25/93

to

In article <24JAN93.01...@UNBVM1.CSD.UNB.CA> T0FG <T0...@UNB.CA> writes:
|Proposed DTS-0001 0.07 beta standard follows:
|

|| Net addresses: <zone>:<net>/<node>.<point>@<organization>
|| Expressed as a 5d net address including the zone, network,
|| node, optional point, and optional organization. These values
|| (except the organization of course) have values between 0 and
|| 32767.

Well, that's great for FidoNet, but what about WWIVnet, VirtualNet, RIME,
and the Internet, which use different forms of addressing? You'd be better
off with allowing arbitrary strings in the net address field.

|| File sizes: <kilobytes>
|| Expressed in number of kilobytes. Kilobytes range from 0 to
|| 2147483647 (signed long).

Why would you ever use a negative file size? (And why not say "signed 32-bit
quantity, instead of using the barely useful number 2147483647?)

| PORTADDR = <addr>
|| Description: This setting contains the i/o address for the
|| communication port. This value must be expressed
|| as an decimal integer.

Even though these are almost always specified in hex. That makes sense.

| USER = <users name>
|| Description: This setting contains the name of the user.
|| Range: String not more than 32 characters in length.

This seems like an awfully arbitrary limit. Why limit any of these strings
at all?

| EXPIRES = <account expiration date>

You don't allow "none" as a date, requiring BBS's that do not expire accounts
to make up bogus expiration dates.

Once again, there seem to be arbitrary, restrictive string ranges here.
Has no one heard of malloc?

| MSGAREA = <text description of message area replying to>

|| Range: String not more than 32 characters in length.
|

| REPLYINGTO = <name of person replying to>

|| Range: String not more than 32 characters in length.
|

| REPLYTOPIC = <topic reply is about>

|| Range: String not more than 32 characters in length.

This one is especially ridiculous, and makes this format completley useless
for use on BBS's that have USENET - subjects are quite often longer than
32 characters.

Bill

Peter Busser

unread,

Jan 26, 1993, 9:00:21 AM1/26/93

to

petr...@hal.gnu.ai.mit.edu (Chris Petrilli) writes:

>[ Narrow-minded DOS drivel deleted. ]

>While I think that there is an excellent concept in standardizing BBS
>software so that it can talk to eachother, the document you sent out is
>worthless to a large number of people.

The same goes for other things. E.g. I'm not interested in RBBS discussions,
but does that mean that I have to flame people who do?

>There are more people on Usenet
>than on FideNet, so the mail addresses are useless.

Try:

Joe.User@p<point#>.f<node#>.n<net#>.z<zone#>.fidonet.org

It'll work.

>Why don't people
>just use the standards that are already there.

Because everyone thinks to know how to do things better than everyone else.
Not just better, but "The Best Way to do Things Ever<tm>".

> Config file: Is it really that important?

It is if you want real open systems (i.e. where every part can be replaced by
some other (equivalent) part).

> Phone numbers: Same thing: ISO standard: +1 XXX XXX XXXX

^^ That should be +31!

(Not everyone lives in the States. :-)

>Seems to me that this is creating yet another set of "standards" for use
>by a group of people who are destined to exclude others.

That's IMHO often not the first intention, but an unfortunate side effect.

>Remember, not everyone uses COMMAND.COM as their shell. (And thank gods
>for small favors like that :-) Don't be so narrow in focus.

You bet I thank the gods for that (I'll do an extra #offer to please them the
next time I play nethack :).

>The
>Internet has developed a lot of standards and they've been tested,
>implemented, and PROVEN interoperable with hundereds of thousands of
>machines all over the world, why re-invent the wheel?

I think that that is the main reason why people shouldn't try to insist on
making their own protocols (so called "standards").

>Especailly when
>the one you're inventing is square?

Greetings,
Peter Busser
--
Hacktic Network Association, bringing Internet to the people

Peter Busser

unread,

Jan 26, 1993, 9:29:54 AM1/26/93

to

petr...@hal.gnu.ai.mit.edu (Chris Petrilli) writes:

>The problem I have is that it creates yet another set of "islands" in
>the network that have to be interfaced. Given, those islands are
>larger, but they are still islands.

That is the difference between the bottom up and top down approach. You
propose a top down approach. The proposed bottom up approach (i.e. the TDS-0001
document) will solve the short term problems of a small group of people. And
a top down approach would solve long term problems. So I don't think that
either way is "better" than the other as they have different goals. In short,
it is good to have a short term solution, but it would be even better to have
a long term solution, a real generic standard, as well.

>It would be better to ignore the
>"operating system specific" concepts and go for REAL standards that are
>usable by everyone rather than a subset. There's so much that is left
>out of this document that it's difficult to use.

Well, then you're going to talk about functionality and not about
implementation. That would still allow for different implementations of the
same standard to be incompatible. Have a peek in comp.mail.misc, there is a
discussion about "the UNIX mailbox format". All mailboxes use a RFC-822 type
message layout, but there are nevertheless many incompatibilities.

>The best thing to do is just simply adopt the Internet standard which
>will allow for almost anything on the face of the planet. The date
>standard I mentioned is the european one, not the american one.

That won't help the people that are stuck with FidoNet stuff at all. The
only thing for MS-DOS that looks like a BBS (flames >/dev/null please) and
does USENET and e-mail is Waffle.

>RFCs and other Internet documents are available via anonymous FTP at
>nic.ddn.mil. There's an index file there (there are currently 1400 RFCs
>and several hundered Internet Drafts).

You can also get them by sending e-mail to <something>@nic.ddn.mil, but I
forgot the <something> part.

Peter Busser

unread,

Jan 26, 1993, 9:32:25 AM1/26/93

to

fen...@postscript.cs.psu.edu (Bill Fenner) writes:

>| REPLYTOPIC = <topic reply is about>
>|| Range: String not more than 32 characters in length.

>This one is especially ridiculous, and makes this format completley useless
>for use on BBS's that have USENET - subjects are quite often longer than
>32 characters.

Not just for USENET, FidoNet uses 72 characters for the subject if I remember
correctly.

Robertc. Moldenhauer

unread,

Jan 26, 1993, 9:27:10 AM1/26/93

to

In article <1juep1...@life.ai.mit.edu> petr...@hal.gnu.ai.mit.edu (Chris Petrilli) writes:

>[ Narrow-minded DOS drivel deleted. ]
>
>While I think that there is an excellent concept in standardizing BBS
>software so that it can talk to eachother, the document you sent out is
>worthless to a large number of people. There are more people on Usenet
>than on FideNet, so the mail addresses are useless. Why don't people
>just use the standards that are already there.
>
> Mail: RFC822 with MIME extensions for multi-media
> News: RFC1032 with use of the "X-*" header extensions
> Config file: Is it really that important?
> Dates: Try the internaltional standards: DAY MON YEAR

Yes, makes much more sense.

> Phone numbers: Same thing: ISO standard: +1 XXX XXX XXXX

He did suggest this, BTW, +1 is only the USA and Canada, +44 would be the
UK, etc. Also 7 digit phone numbers are *NOT* all that common outside
North America and many countries don't have city/region/area codes, a
proper french telephone number would be: +33 XX XX XX XX

Jim Wenzel

unread,

Jan 27, 1993, 5:54:00 AM1/27/93

to

Peter Busser * That won't help the people that are stuck with FidoNet

stuff at all. The only thing for MS-DOS that looks like
a BBS (flames >/dev/null please) and does USENET and
e-mail is Waffle.

= = =

Incorrect.. PCBoard w/UUPCB software does UseNet quite well. Usenet
messages are imported directly into the PCBoard message bases.
---
* SM 1.06 A0059 * One person with courage is a majority. - Andrew Jackson

Chris Petrilli

unread,

Jan 27, 1993, 11:43:24 AM1/27/93

to

"Peter" = pe...@globv1.hacktic.nl (Peter Busser)
"Me" = petr...@hal.gnu.ai.mit.edu (Chris Petrilli)

Me> The problem I have is that it creates yet another set of "islands" in
Me> the network that have to be interfaced. Given, those islands are
Me> larger, but they are still islands.

Peter> That is the difference between the bottom up and top down
Peter> approach. You propose a top down approach. The proposed bottom
Peter> up approach (i.e. the TDS-0001 document) will solve the short
Peter> term problems of a small group of people. And a top down
Peter> approach would solve long term problems. So I don't think that
Peter> either way is "better" than the other as they have different
Peter> goals. In short, it is good to have a short term solution, but
Peter> it would be even better to have a long term solution, a real
Peter> generic standard, as well.

The problems I see stem from the incompatibilities between the long
term and short term goals. It seems to me that FidoNet (and the other
networks) long for connectivity to the Internet, but right now, the
only way to do so is thorugh all kinds of gateways that are flakey at
best. If they really want to work with the Internet, then they should
be moving toward the Internet standards, otherwise, it'll never be
anything more than a kludge. The introduction of a new small set of
standards is fine, but it should be a transisition point to the final
stage, and the standards offered are nothing like what would be
required, and would present the need for yet another revision of the
software, rather than just a small modification.

Me> It would be better to ignore the "operating system specific"
Me> concepts and go for REAL standards that are usable by everyone
Me> rather than a subset. There's so much that is left out of this
Me> document that it's difficult to use.

Peter> Well, then you're going to talk about functionality and not
Peter> about implementation. That would still allow for different
Peter> implementations of the same standard to be incompatible. Have a
Peter> peek in comp.mail.misc, there is a discussion about "the UNIX
Peter> mailbox format". All mailboxes use a RFC-822 type message
Peter> layout, but there are nevertheless many incompatibilities.

If the standard is complete they will interoperate. The RFC822
standard does not specific mailbox format, it simply specifies mail
header and body formats and needs. The reason there are
incompatibilities (and there are not many) is that there are two or
three different mods to the standard "Unix mailbox," such as the RAND
MH pack format and the Bablyl format. If you offer a standard to this
then you fix the problem if people comply with it. I though the goal
was to make them interoperate rahter than making them all look alike?

Me> The best thing to do is just simply adopt the Internet standard
Me> which will allow for almost anything on the face of the planet.
Me> The date standard I mentioned is the european one, not the
Me> american one.

Peter> That won't help the people that are stuck with FidoNet stuff at
Peter> all. The only thing for MS-DOS that looks like a BBS (flames
Peter> >/dev/null please) and does USENET and e-mail is Waffle.

It has always been my opinion that FidoNet is broken since it is
incompatible with all the standards that are dominant in other
computer communities, and it was short sighted not to adopt the
Internet standards. You're gonna have to change some day, might as
well change now.

Larry Snyder

unread,

Jan 28, 1993, 6:22:22 AM1/28/93

to

pe...@globv1.hacktic.nl (Peter Busser) writes:

>Not just for USENET, FidoNet uses 72 characters for the subject if I remember
>correctly.

TBBS crops the subject length to something quite a bit smaller

--
Larry Snyder internet: la...@gator.use.com
keeper of the Gator uucp: uunet!gator!larry

Tim Pozar

unread,

Jan 28, 1993, 1:19:56 AM1/28/93

to

pe...@globv1.hacktic.nl (Peter Busser) writes:
>fen...@postscript.cs.psu.edu (Bill Fenner) writes:
>
>>| REPLYTOPIC = <topic reply is about>
>>|| Range: String not more than 32 characters in length.
>
>>This one is especially ridiculous, and makes this format completley useless
>>for use on BBS's that have USENET - subjects are quite often longer than
>>32 characters.
>
>Not just for USENET, FidoNet uses 72 characters for the subject if I remember
>correctly.

You do... From FTS-0001.A12....
---

1. Application Layer Data Definition : a Stored Message

Stored Message

Message = fromUserName(36) (* Null terminated *)
toUserName(36) (* Null terminated *)
subject(72) (* see FileList below *)
DateTime (* message body was last edited *)
| timesRead (* number of times msg has been read *)
destNode (* of message *)
origNode (* of message *)
cost (* in lowest unit of originator's
currency *)
origNet (* of message *)
destNet (* of message *)
| destZone (* of message *)
| origZone (* of message *)
| destPoint (* of message *)
| origPoint (* of message *)
replyTo (* msg to which this replies *)
AttributeWord
nextReply (* msg which replies to this *)
text(unbounded) (* Null terminated *)

DateTime = (* a character string 20 characters long *)
(* 01 Jan 86 02:34:56 *)
DayOfMonth " " Month " " Year " "
" " HH ":" MM ":" SS
Null

DayOfMonth = "01" | "02" | "03" | ... | "31" (* Fido 0 fills *)
Month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
"Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
Year = "01" | "02" | .. | "85" | "86" | ... | "99" | "00"
HH = "00" | .. | "23"
MM = "00" | .. | "59"
SS = "00" | .. | "59"

AttributeWord bit meaning
--- --------------------
0 + Private
1 + s Crash
2 Recd
3 Sent
4 + FileAttached
5 InTransit
6 Orphan
7 KillSent
8 Local
9 s HoldForPickup
10 + unused
11 s FileRequest
12 + s ReturnReceiptRequest
13 + s IsReturnReceipt
14 + s AuditRequest
15 s FileUpdateReq

s - need not be recognized, but it's ok
| + - not zeroed before packeting

Bits numbers ascend with arithmetic significance of bit position.

--
Internet: po...@kumr.lns.com FidoNet: Tim Pozar @ 1:125/555
Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
Voice: +1 415 788 2022

Tim Pozar

unread,

Jan 29, 1993, 11:29:45 AM1/29/93

to

jim.w...@grapevine.lrk.ar.us (Jim Wenzel) writes:
>Peter Busser * That won't help the people that are stuck with FidoNet
> stuff at all. The only thing for MS-DOS that looks like
> a BBS (flames >/dev/null please) and does USENET and
> e-mail is Waffle.
> = = =
>
> Incorrect.. PCBoard w/UUPCB software does UseNet quite well. Usenet
> messages are imported directly into the PCBoard message bases.

and UFGATE and FSUUCP and FREDMAIL...

Tim

lai...@lub001.lamar.edu

unread,

Jan 29, 1993, 12:31:12 PM1/29/93

to

In article <1297.49...@grapevine.lrk.ar.us>, jim.w...@grapevine.lrk.ar.us (Jim Wenzel) writes:

> Peter Busser * That won't help the people that are stuck with FidoNet
> stuff at all. The only thing for MS-DOS that looks like
> a BBS (flames >/dev/null please) and does USENET and
> e-mail is Waffle.

>>JIM WENZEL WRITES:

> Incorrect.. PCBoard w/UUPCB software does UseNet quite well. Usenet
> messages are imported directly into the PCBoard message bases.

Absolutely, positively correct. Not only does PC-Board do that, so does
UltraBBS, of which I have several USENET feeds. It all works nicely.
You can even do the feed via QWK packets if you like. A lot easier than
a mailer package, but still 100% the fun involved...

-------------------------------------------------------------------------------
INTERNET: lai...@lub001.lamar.edu philli...@hal9k.ann-arbor.mi.us
The HAM Connection (409)833-1795 FIDO/USENET/WNET/ HAYES 144 V.32B/V.42B
" Per the boss, I gotta say, these are my opinions, not my employers thoughts"
-------------------------------------------------------------------------------

Leonard Erickson

unread,

Jan 29, 1993, 11:51:59 AM1/29/93

to

petr...@hal.gnu.ai.mit.edu (Chris Petrilli) writes:

>In article <25JAN93.01...@UNBVM1.CSD.UNB.CA> T0...@UNB.CA (T0FG000) writes:
>>Note: this is not an attempt to standardize BBS software! Only the
>>interface between BBS software and external programs. BBS software
>>design is intentionally left out of this document. Further, it is not
>>intended to restrict other means that the BBS and external software
>>may use to communicate with each other, only to provide one method that
>>is satisfactory for both BBS authors and door authors in a BBS-software
>>independent fashion.

>The problem I have is that it creates yet another set of "islands" in
>the network that have to be interfaced. Given, those islands are
>larger, but they are still islands. It would be better to ignore the
>"operating system specific" concepts and go for REAL standards that are
>usable by everyone rather than a subset. There's so much that is left
>out of this document that it's difficult to use.

Excuse me, but i fail to see *how* this creates the sort of islands you are
talking about. This is a proposal for a standard *data exchange format*
between programs running on the same *MS-DOS* machine. Most of what is
"left out" is problable stuff that is totally irrelevant to the situation.

I suggest that you find out *what* a "door program" is before you
try to critique a standard for how it should interface with a BBS
program.

>>This is one attempt to generate and support standards that do exist.
>>The document was created over the Fidonet system, and the standards
>>in place in that network obviously hold large sway in the document.
>>Personally, such issues as date format I have brought up already. I
>>am Canadian, and do not use the American month/day/year format
>>either. The issue with mail addresses supporting other networks is
>>an important one - since BBS systems that attempt to use this
>>interface will find the Fidonet format useless if they do not
>>themselves use Fidonet.

>The best thing to do is just simply adopt the Internet standard which
>will allow for almost anything on the face of the planet. The date
>standard I mentioned is the european one, not the american one.

The date standard you mentioned is fine. But the others don't really apply.

--
Leonard Erickson leo...@qiclab.scn.rain.com
CIS: [70465,203] 7046...@compuserve.com
FIDO: 1:105/51 Leonard....@f51.n105.z1.fidonet.org
(The CIS & Fido addresses are preferred)

Bill Fenner

unread,

Jan 29, 1993, 2:56:56 PM1/29/93

to

In article <1993Jan29....@qiclab.scn.rain.com> Leonard....@f51.n105.z1.fidonet.org writes:

|petr...@hal.gnu.ai.mit.edu (Chris Petrilli) writes:
|>The problem I have is that it creates yet another set of "islands" in

|>the network that have to be interfaced....

|
|Excuse me, but i fail to see *how* this creates the sort of islands you are
|talking about.

How about the arbitrary length limits on many of the strings in the file?
If I'm running BBS software that has longer data for some of those fields
(like, say, subjects longer than 32 characters), then I have to create some
sort of translation between my system and a door that requires this file
format.

Bill

Peter Busser

unread,

Jan 31, 1993, 7:03:30 PM1/31/93

to

leo...@qiclab.scn.rain.com (Leonard Erickson) writes:

>petr...@hal.gnu.ai.mit.edu (Chris Petrilli) writes:

>Excuse me, but i fail to see *how* this creates the sort of islands you are
>talking about. This is a proposal for a standard *data exchange format*
>between programs running on the same *MS-DOS* machine. Most of what is
>"left out" is problable stuff that is totally irrelevant to the situation.

The problem is probably the interpretation of the word "standard". You
interpret it as a "MS-DOS based (single tasking) BBS system" whereas Chris
Petrilli probably interprets it as "general standard for (almost) every BBS
system on (almost) every computer". The proposed standard is more or less
suitable for the first definition, but it is clearly not for the second.

The "MS-DOS based (single tasking) BBS systems" are just an island, regardless
how big it is. I think that for instance Atari ST based systems have the same
problem. And systems like Waffle, and Magpie, that do not support FidoNet
could also have the same problem. This standard addresses a wide enough
problem to allow for a solution with a wider scope.

>I suggest that you find out *what* a "door program" is before you
>try to critique a standard for how it should interface with a BBS
>program.

Calm down, there is no need to flame.

>>>either. The issue with mail addresses supporting other networks is
>>>an important one - since BBS systems that attempt to use this
>>>interface will find the Fidonet format useless if they do not
>>>themselves use Fidonet.

>>The best thing to do is just simply adopt the Internet standard which
>>will allow for almost anything on the face of the planet. The date
>>standard I mentioned is the european one, not the american one.

>The date standard you mentioned is fine. But the others don't really apply.

Why not, is it so hard to write a standard that also allows other network
addresses to be used? If you could really care less about other networks,
then why not define that the zone number should be between 1 and 9? Don't
think that a standard, that *allows* several types of network addresses to be
used, *forces* every application to understand them all. That would be
illogical.

Kennelmeister

unread,

Jan 31, 1993, 10:03:58 PM1/31/93

to

leo...@qiclab.scn.rain.com (Leonard Erickson) writes:

> Excuse me, but i fail to see *how* this creates the sort of islands you are
> talking about. This is a proposal for a standard *data exchange format*
> between programs running on the same *MS-DOS* machine. Most of what is
> "left out" is problable stuff that is totally irrelevant to the situation.

MS-DOS?

Fido wasn't started on MS-DOS, and many machines on Fido AREN'T
MS-DOS. A lot of major Fido nodes are running U*IX. Some are even
minis or mainframes.

Stop and think. I personally know 6 different platforms that are used
for fido, let alone the different platforms that are used for Internet,
WWIV or whatever.

Your Islands will be of MS-DOS platforms. A network is not limited to
any one type of machine.

--
Alan Brown. (SysAdmin)
dog...@dogbox.acme.gen.nz Palmerston North
Dawghaus BBS -> +64 (6) 357-9245 New Zealand
"A wet and windy place in the South Pacific"

Grant DeLorean

unread,

Feb 2, 1993, 1:25:12 AM2/2/93

to

dog...@dogbox.acme.gen.nz (Kennelmeister) writes:

>Fido wasn't started on MS-DOS, and many machines on Fido AREN'T
>MS-DOS. A lot of major Fido nodes are running U*IX. Some are even
>minis or mainframes.

FidoNet was named for the BBS software Fido, which is what started
the whole thing. An MS-DOS program. FidoNet was very antagonistic
to non-MS-DOS systems early on. I was one of the folks trying
something different and got nothing but flak for it, even though it
worked OK.

>Stop and think. I personally know 6 different platforms that are used
>for fido, let alone the different platforms that are used for Internet,
>WWIV or whatever.

I was on the beta team for the port of Binkley et al to the Atari ST
(which incidentally wasn't what I was refering to above, this was
a side deal). The Amiga has Fido software, so there are two. The Macs
also have it, and QNX (what I was running) also has it. The CoCo has
some as well, which amazing in itself. Add in MS-DOS and there are
your 6. There aren't UNIX systems or mainframes running serious Fido
sites, the software just isn't there (and neither is the motivation
to debug what is there). Where the motivation is is for Fido and
WWIV sites to connect to UseNet sites (leaving out the InterNet, which
is a hard as opposed to soft network).

--
\ Grant DeLorean - IHMSA & NRA Life Member - (gr...@bluemoon.use.com) /

Good leaders being scarce, following yourself is allowed.

Bill Fenner

unread,

Feb 2, 1993, 2:04:37 AM2/2/93

to

In article <BHy0XB...@dogbox.acme.gen.nz> dog...@dogbox.acme.gen.nz (Kennelmeister) writes:
|MS-DOS?
|

|Fido wasn't started on MS-DOS...

Really? I'm sure Tom Jennings would be surprised to discover this...

Bill

T0FG000

unread,

Feb 3, 1993, 7:21:48 PM2/3/93

to

Ok, we seem to be coming to some agreement as to what problems the
DTS proposal actually has, and some solutions for those problems. I
have already submitted suggestions to accomodate other address
formats and the ISO date format. I also suggested longer lines, and
got a reply to the effect that 64 character lines would be proposed.
I detect that this may not be exactly what everyone here would like
to hear.

I will send a summary of suggestions that I have heard and I would
like to see, that reflect differences from the last crisis :) (wish
this newsgroup were being gated to Fido as well, would simplify my
position). I will list them here for all to comment on:

1) Allow address formats of any network. Use a network identifier
as the first item of the 'data' portion of the ADDRESS item.
Suggest that symbols such as FTN, RFC (is this copyrighted?), WWIV,
CITADEL, BANG, etc. be
used for Fidonet compatible, Internet domain style, WWIV, Citadel
style, bang path, etc. addresses, respectively.

2) Allow comm port identifiers to be flexible, but must be
understood by the system in question. For DOS, the COMx format
would still hold. For other systems, must be understood by programs
using that system.

3) Allow lines to be flexible in length, but only represent n
aracters as required. Where n is some number everyone will argue
endlessly about. (So this idea is not so hot, but it gets around
limitations that do exist, without arbitrarily putting an upper
bound on anything - more can be used without breaking any rules, and whe
n the time comes to increase the required length, nothing should
break.)

4) Someone suggested cc: and bcc: tokens to me at one time. How
about adding REPLYCC and REPLYBCC tokens to the message section (D?)
of the proposal?

5) ISO phone numbers. Sorry, forgot to look this up. Really. The
format shown isn't cast in stone, so it can wait for a short while
anyways.

6) Some other miscellaneous stuff. I think tightening up the wording ab
out what an external program should do when an event is to occur (ie
the door should exit back to the calling routine), more clearly
defining what the ranges used mean (0 to 32767 *means* 0 to 32767,
not some other values that some compiler's datatype allows, for
example) and perhaps suggesting the document go through a spell checker.
:) :) (At least I didn't get flamed for that, yet. :) )

Can't think of anything else at the moment. I guess I'll leave it
at that for now. One other problem that 'may' have occurred, is
that the Fidonet DOORWARE echo may have been dropped from Fidonet
backbone distribution, meaning that the only discussion on this
topic might be in these areas and private e-mail. Oh well. Be that
as it may, I hope that DTS may continue to grow into a useful
document.

ater, Will.

---------------------------------------- William Burrow
Internet: t0...@unb.ca |

wi...@p1.f14.n255.z1.fidonet.org | I'm not UNB, thats
Fidonet: 1:255/14.1 | someone else...

ns...@acad3.alaska.edu

unread,

Feb 4, 1993, 6:17:05 AM2/4/93

to

Maybe move the discussion over to comp.bbs.development newsgroup when and if it
comes about.. We shall see..

I like so far what I have seen..

==
Michael Adams alias Ghost Wheel/Morgoth NS...@acad2.alaska.edu

Jeffrey Grimmett 9999

unread,

Feb 9, 1993, 10:10:49 AM2/9/93

to

Quoth fen...@postscript.cs.psu.edu (Bill Fenner):

Heh, no doubt! I wouldn't be suprised if Tom were still using the _same_
peecee he wrote Fido 1.0 on :-)

--
####################@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@#####******************
Jeff Grimmett [SuperBitMap BBS] @ fido!1:202/739.0 [619-460-7290]
jeff_g...@f739.n202.z1.fidonet.org @ jgr...@TorreyPinesCA.ncr.com
WAAAAAAAAAARRRRRGG!!!!! (tension breaker, had to be done)
*******************************************************************************

David Reeve Sward

unread,

Feb 9, 1993, 4:43:13 PM2/9/93

to

Excerpts from netnews.alt.bbs: 9-Feb-93 Re: DTS-0001 proposed standard
by Jeffrey Grimmett@TorreyP

> ]> |MS-DOS?
> ]> |
> ]> |Fido wasn't started on MS-DOS...
> ]>
> ]> Really? I'm sure Tom Jennings would be surprised to discover this...
>
> Heh, no doubt! I wouldn't be suprised if Tom were still using the _same_
> peecee he wrote Fido 1.0 on :-)

You can ask him if you *really* want to - although he may very well just
ignore your question. tom.je...@f23.n1.z1.fidonet.org

:)
--
David Sward campus: x4405 email: swa...@cmu.edu or ds...@andrew.cmu.edu

Hamish Moffatt

unread,

Feb 10, 1993, 7:01:38 PM2/10/93

to

In <03FEB93.21...@UNBVM1.CSD.UNB.CA> T0FG000 <T0...@UNB.CA> writes:

>1) Allow address formats of any network. Use a network identifier
>as the first item of the 'data' portion of the ADDRESS item.
>Suggest that symbols such as FTN, RFC (is this copyrighted?), WWIV,

RFC isn't specific enough; a later RFC could define an incompatible address
format and then an author using this program would not know which to use
RFC822 is the exact one.

>CITADEL, BANG, etc. be

RFC822 may cover bang paths too, I'm not sure.

>2) Allow comm port identifiers to be flexible, but must be
>understood by the system in question. For DOS, the COMx format
>would still hold. For other systems, must be understood by programs
>using that system.

COMx isn't specific enough. I have COM3 on IRQ5, and COM3 is connected to
my second modem. How will software know where to find COM3 from this
information? I would suggest, perhaps "COMx" for DOS (BIOS-defined)
serial ports, "FOSSILx" for fossil driven ports. The fossil can be told of
new IRQs much easier than DOS can, and the FOSSIL can map virtual port numbers
to different real ports, if you move your modem for example.
What about COMx.OS2 and the like? How about an 0x<base>/<irq> format for
non-FOSSIL odd ports?

Hamish

--

Hamish Moffatt, ham...@cloud.apana.org.au APANA: The Australian Public
Cloud Nine BBS, 3:635/552@fidonet Access Network Association.
Melbourne Australia 58:4100/43@intlnet Mail in...@apana.org.au
Titanic Software. Voice: +61-3-803-1326 for information.

Hamish Moffatt

unread,

Feb 13, 1993, 11:57:55 PM2/13/93

to

David Reeve Sward <swa...@CMU.EDU> writes:

> You can ask him if you *really* want to - although he may very well just
> ignore your question. tom.je...@f23.n1.z1.fidonet.org

1:1/23 is the Fidonet address, and the (soon) new Fidonet editor
wouldn't be too impressed if you all sent mail there..

1:125/111 is his real address, from memory, or

tom.je...@fidosw.fidonet.org

hamish

Mikael Cardell

unread,

Feb 15, 1993, 6:48:26 AM2/15/93

to

The address you mention for Tom Jennings is not correct. Consider
this:

11 bodil $ finger to...@fido.wps.com
[fido.wps.com]
Login: tomj Name: Tom Jennings
Directory: /home/tomj Shell: /bin/csh
On since Sat Feb 13 11:05 (PST) on console, idle 0:04
Plan:

Internet: to...@fido.wps.com [140.174.77.1]
FidoNet: Tom Jennings, 1:125/111@fidonet

Home Phone: +1-415-555-1212
Bank Acct #: 0099-23-34556
Bank Balance: $-23.19 On Vacation til: DOOMSDAY
Bankcard PIN: SHRIMP_ME Major appliances owned: UPON REQUEST
Maiden's name: Lill Street address: 1 Main St, Notown UZA
Favorite color: red Cash stored in: UPPER RIGHT HAND DRAWER

What's in YOUR .plan file?

12 bodil $
--
mikael cardell <car...@lysator.liu.se>

S P U N K P R E S S

meckle...@gmail.com

unread,

Sep 8, 2017, 9:12:46 PM9/8/17

to

On Sunday, January 24, 1993 at 12:35:26 AM UTC-5, T0FG wrote:
> Proposed DTS-0001 0.07 beta standard follows:
>
>

> | This document is (C) 1993 Daniel Mecklenburg, and is posted to the
> | Internet newsgroups with permission.
> | Daniel can be reached directly at:
> | Fidonet: 1:325/608
> | Internet: Daniel.Me...@f608.n325.z1.fidonet.org

Funny stumbling into this post after all these years! Ha!

David Solimano

unread,

Nov 8, 2017, 11:50:41 PM11/8/17

to

I hope you're still reading your Fidonet mail . . .