*Nodelist Flag Changes Draft Document

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 

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.  

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 

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 

                         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