NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/alt/bbs/8171

Internet Message Format | 1993-01-25 | 6.1 KB

Xref: sparky alt.bbs:8171 comp.bbs.misc:1868
Newsgroups: alt.bbs,comp.bbs.misc
Path: sparky!uunet!newsflash.concordia.ca!nstn.ns.ca!news.ucs.mun.ca!csd.unb.ca!UNBVM1.CSD.UNB.CA
From: T0FG000 <[e-mail]>
Subject: Re: DTS-0001 proposed standard
Message-ID: <[e-mail]>
Lines: 112
Sender: [e-mail]
Organization: The University of New Brunswick
References: <[e-mail]> <[e-mail]>
Date: Mon, 25 Jan 1993 05:22:27 GMT

In article <[e-mail]> [e-mail] (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:  [e-mail]                      |
           [e-mail]   |
Fidonet:  1:255/14.1                        |