The following is a proposed change to the nodelist. Please send
your comments to either Ken Kaplan at 100/22, Ray Gwinn at
109/634, or David Dodell at 114/15. We will not be replying to
all comments but wish to get a general feeling from the network
about this proposed change.
Nodelist Flag Draft Document
Primary Author: Ray Gwinn
Secondary Author: David Dodell
Contact 114/15 or 1/0 with comments
Version 1 (11-15-87)
I proposed that the Nodelist (comment) Flags be replaced with a
capabilities identifier.
After all, the bottom line is that we want to know the
capabilities of the remote node before it is contacted. If the
remote is not capable of performing the desired function, then
there is no need to contact it.
The problem(s) with the existing method is that it originally
started as a comment field and was not planed. At the time
SEAdog was the only "extended protocol" program around. But,
along came Opus with a different "extended protocol". I think
that additional flags like WZ, BR, WR, etc is only extending the
previously unplanned system and will lead to problems in the
future. For example, XP today includes file update requests, but
XP a year ago did not. So, a node using SEAdog V3.xx will have
an XP flag but it is not capable of doing update requests (I
think). Thus, XP does not really tell you what the remote node
is capable of doing.
The capabilities identifier that I propose will do nothing more
than define the program(s) that the remote node is using to
accept incoming calls/mail/requests. Some may say that this is
nothing more than the product code that already exists in the
mail packet. The primary difference is that the capabilities
identifier will exist in the nodelist. This means it is
available without contacting the remote node, while the product
code is not. Also the product code is limited to 256
possibilities.
I assume that it is desired that the nodelist flags field be two
non-control characters. If so, then I propose that the
capabilities identifier be a two digit, base 36 number. The
digits being 0 through 9 and A through Z and are assigned
sequentially. For example, Fido may be 01 and Dutchie may be 02.
Also note that as defined, XP and WZ are valid. However, I think
they should be done away with, and identifiers be assigned
starting with 00 (00 meaning generic FTSC net mail protocol).
This number, once converted to binary, can be used by programmers
as an index into application specific data bases or tables. One
example is a simple program that will tell a user the
capabilities of a remote node. Given the node's address and the
nodelist, the program could search the nodelist to get the
capabilities identifier. Then the program could use that
identifier as an index into a data base to obtain the
capabilities of the remote node and display them to the user.
Another example is a program that can use the identifier as an
index into a capabilities table that allows determination in
advance that the remote is capable of the desired session prior
to contacting it.
Implementation
----------
First, all nodes in the network are assigned a capabilities
identifier of 00. This is the capabilities code of a net mail
program that meets the basic requirements of the FTSC
specification. Once again, the purpose of this identifier
(except 00) is to define the program(s) that the node is using to
process calls/requests/mail. Also remember that the identifier
reflects the mail handler. For example, TBBS with a BINKLEY
front end will be identified by its BINKLEY identity.
The program author (or project leader) will request a
capabilities identifier from the assigner. Who does the
assigning is another subject. Along with the request must be a
written and detailed description of all enhances features of the
program. Remember, we are dealing with automated contacts
between nodes. In this context, the ability of a program to
handle 50 simultaneous callers is not an enhanced feature.
The list of features can be provided to other authors so that
they may consider a compatible feature. Note, that if the
description of the enhanced features is not sufficient for other
authors to add a compatible feature, then the program may be
assigned the basic 00 capabilities flag. This little enforcement
rule has the potential of lifting a tremendous burden of
documentation from the FTSC. If the committee accepting the
written definition is programmers, the documentation is likely to
be understandable. I think the same committee should assigns new
capabilities codes (other than those grandfathered). The ego of
the program authors would probably insure sufficient
documentation for a capabilities identifier other than 00.
After consideration, the FTSC could choose to adopt the
definition (possibly modified) as a standard. I feel this gives
the a creative programmer's new features a way into the nodelist
and the FTSC the ability to consider enhancements with 20/20
hindsight. At the same time, the FTSC must only modify the
provided documentation to define a new standard instead of
starting from scratch. But, I'm drifting, this is another
subject.
If a new revision of the same program has additional capabilities
that need to be defined, then the author should request a new
capabilities code. There should be a policy that only one or two
revisions back will have individual capabilities identifiers. If
revisions more than one or two old are still in use they can be
assigned the basic 00 identifier.
The program authors should be required to prominently display the
capabilities identifier. This will allow the Sysop to easily
provide the identifier to his network coordinator for inclusion
in the nodelist. This a basically a take off of the ringer
equivalent code that you find in your modem manual.
As I have defined it, the committee that assigns the capabilities
identifiers can not reject the new features. They can only
reject the documentation of the new features as not being
understandable. This should keep most developers happy because
no one can tell them not to do something. It should make the job
of the FTSC simpler because they will only accept documentation,
not create it. The ego's of the developers, anxious to be
identified in the nodelist, should keep the documentation flowing
to the FTSC.
As pointed out by David Dodell, the same type of identifier can
be applied to modems. That is modem 00 can be a 1200 baud Hayes
(true) compatible, type 02 can be a USR Courier, etc.
What I have proposed here solves many problems, but not all. For
example, there is no way to tell when the wierd BBS has SEAdog
running. So, a CM type flag is still required.
I think that 3 flags will take care of everything. One
identifies the mail handler, another identifies his modem type
and a third should identify when mail/file requests can be
accepted.
The other flags
---------
The other two flags would represent mail reception times and
modem type.
For example the flag 00 would represent mail can only be received
during NMH. Flag 01 would mean mail could be received 24 hours,
identical to the meaning of the CM flag now. Other variations
could be:
00 National Mail Hour Only for Mail
01 Continuous Mail 24 hour/day
02 Continuous Mail 24 hour/day with 24 hr File Request Capability
03 CM 24 hrs/day, File request all but NMH
The third flag would represent modem types:
00 300 baud Bell standard
01 1200 baud Bell standard
02 2400 baud
03 1200 baud w/MNP
04 2400 baud w/MNP
05 USR HST Modem
06 Telebit Trailblazer Modem
07 Hayes V9600 Modem
08 Microcom Modem 9600 baud
