home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / FSC.ZIP / FSC-0009.TXT < prev    next >
Text File  |  1987-11-15  |  9KB  |  180 lines
  1. FSC-0009
  2.  
  3. *Nodelist Flag Changes Draft Document
  4.  
  5. The following is a proposed change to the nodelist.  Please  send 
  6. your  comments  to  either  Ken  Kaplan  at 100/22,  Ray Gwinn at 
  7. 109/634,  or David Dodell at 114/15.  We will not be replying  to 
  8. all  comments  but wish to get a general feeling from the network 
  9. about this proposed change.  
  10.  
  11.  
  12.                    Nodelist Flag Draft Document 
  13.                     Primary Author: Ray Gwinn
  14.                   Secondary Author: David Dodell
  15.                Contact 114/15 or 1/0 with comments   
  16.                        Version 1 (11-15-87)
  17.  
  18.  
  19. I proposed that the Nodelist (comment) Flags be replaced  with  a 
  20. capabilities identifier.  
  21.  
  22. After  all,  the  bottom  line  is  that  we  want  to  know  the 
  23. capabilities of the remote node before it is  contacted.  If  the 
  24. remote  is  not capable of performing the desired function,  then 
  25. there is no need to contact it.  
  26.  
  27. The problem(s) with the existing method  is  that  it  originally 
  28. started  as  a  comment  field  and  was not planed.  At the time 
  29. SEAdog was the only  "extended  protocol"  program  around.  But, 
  30. along  came  Opus  with a different "extended protocol".  I think 
  31. that additional flags like WZ, BR, WR,  etc is only extending the 
  32. previously  unplanned  system  and  will  lead to problems in the 
  33. future.  For example, XP today includes file update requests, but 
  34. XP a year ago did not.  So,  a node using SEAdog V3.xx will  have 
  35. an  XP  flag  but  it  is not capable of doing update requests (I 
  36. think).  Thus,  XP does not really tell you what the remote  node 
  37. is capable of doing.  
  38.  
  39. The  capabilities  identifier that I propose will do nothing more 
  40. than define the program(s) that  the  remote  node  is  using  to 
  41. accept  incoming  calls/mail/requests.  Some may say that this is 
  42. nothing more than the product code that  already  exists  in  the 
  43. mail  packet.  The  primary  difference  is that the capabilities 
  44. identifier  will  exist  in  the  nodelist.   This  means  it  is 
  45. available  without contacting the remote node,  while the product 
  46. code  is  not.   Also  the  product  code  is  limited   to   256 
  47. possibilities.  
  48.  
  49. I  assume that it is desired that the nodelist flags field be two 
  50. non-control  characters.   If  so,   then  I  propose  that   the 
  51. capabilities  identifier  be  a  two digit,  base 36 number.  The 
  52. digits being 0 through  9  and  A  through  Z  and  are  assigned 
  53. sequentially.  For example, Fido may be 01 and Dutchie may be 02.  
  54. Also note that as defined, XP and WZ are valid.  However, I think 
  55. they  should  be  done  away  with,  and  identifiers be assigned 
  56. starting with 00 (00 meaning generic FTSC net mail protocol).  
  57.  
  58. This number, once converted to binary, can be used by programmers 
  59. as an index into application specific data bases or  tables.  One 
  60. example   is   a  simple  program  that  will  tell  a  user  the 
  61. capabilities of a remote node.  Given the node's address and  the 
  62. nodelist,  the  program  could  search  the  nodelist  to get the 
  63. capabilities  identifier.   Then  the  program  could  use   that 
  64. identifier   as   an  index  into  a  data  base  to  obtain  the 
  65. capabilities of the remote node and display  them  to  the  user.  
  66. Another  example  is  a program that can use the identifier as an 
  67. index into a capabilities  table  that  allows  determination  in 
  68. advance  that  the remote is capable of the desired session prior 
  69. to contacting it.  
  70.  
  71.  
  72.                           Implementation
  73.                             ----------
  74.           
  75. First,  all nodes in the  network  are  assigned  a  capabilities 
  76. identifier  of  00.  This  is the capabilities code of a net mail 
  77. program  that  meets  the  basic   requirements   of   the   FTSC 
  78. specification.   Once  again,  the  purpose  of  this  identifier 
  79. (except 00) is to define the program(s) that the node is using to 
  80. process calls/requests/mail.  Also remember that  the  identifier 
  81. reflects  the  mail  handler.  For  example,  TBBS with a BINKLEY 
  82. front end will be identified by its BINKLEY identity.  
  83.  
  84. The  program  author  (or  project   leader)   will   request   a 
  85. capabilities   identifier   from  the  assigner.   Who  does  the 
  86. assigning is another subject.  Along with the request must  be  a 
  87. written  and detailed description of all enhances features of the 
  88. program.   Remember,  we  are  dealing  with  automated  contacts 
  89. between  nodes.  In  this  context,  the  ability of a program to 
  90. handle 50 simultaneous callers is not an enhanced feature.  
  91.  
  92. The list of features can be provided to  other  authors  so  that 
  93. they  may  consider  a  compatible  feature.  Note,  that  if the 
  94. description of the enhanced features is not sufficient for  other 
  95. authors  to  add  a  compatible feature,  then the program may be 
  96. assigned the basic 00 capabilities flag.  This little enforcement 
  97. rule  has  the  potential  of  lifting  a  tremendous  burden  of 
  98. documentation  from  the  FTSC.  If  the  committee accepting the 
  99. written definition is programmers, the documentation is likely to 
  100. be understandable.  I think the same committee should assigns new 
  101. capabilities codes (other than those grandfathered).  The ego  of 
  102. the    program   authors   would   probably   insure   sufficient 
  103. documentation for a capabilities identifier other than 00.  
  104.  
  105. After  consideration,   the  FTSC  could  choose  to  adopt   the 
  106. definition  (possibly modified) as a standard.  I feel this gives 
  107. the a creative programmer's new features a way into the  nodelist 
  108. and  the  FTSC  the  ability  to consider enhancements with 20/20 
  109. hindsight.  At the same time,  the  FTSC  must  only  modify  the 
  110. provided  documentation  to  define  a  new  standard  instead of 
  111. starting  from  scratch.  But,  I'm  drifting,  this  is  another 
  112. subject.  
  113.  
  114. If a new revision of the same program has additional capabilities 
  115. that  need  to  be defined,  then the author should request a new 
  116. capabilities code.  There should be a policy that only one or two 
  117. revisions back will have individual capabilities identifiers.  If 
  118. revisions more than one or two old are still in use they  can  be 
  119. assigned the basic 00 identifier.  
  120.  
  121. The program authors should be required to prominently display the 
  122. capabilities  identifier.  This  will  allow  the Sysop to easily 
  123. provide the identifier to his network coordinator  for  inclusion 
  124. in  the  nodelist.  This  a  basically  a  take off of the ringer 
  125. equivalent code that you find in your modem manual.  
  126.  
  127.  
  128. As I have defined it, the committee that assigns the capabilities 
  129. identifiers can not  reject  the  new  features.  They  can  only 
  130. reject  the  documentation  of  the  new  features  as  not being 
  131. understandable.  This should keep most developers  happy  because 
  132. no one can tell them not to do something.  It should make the job 
  133. of  the FTSC simpler because they will only accept documentation, 
  134. not create it.  The  ego's  of  the  developers,  anxious  to  be 
  135. identified in the nodelist, should keep the documentation flowing 
  136. to the FTSC.  
  137.  
  138. As  pointed out by David Dodell,  the same type of identifier can 
  139. be applied to modems.  That is modem 00 can be a 1200 baud  Hayes 
  140. (true) compatible, type 02 can be a USR Courier, etc.  
  141.  
  142. What I have proposed here solves many problems, but not all.  For 
  143. example,  there  is  no way to tell when the wierd BBS has SEAdog 
  144. running.  So, a CM type flag is still required.  
  145.  
  146. I  think  that  3  flags  will  take  care  of  everything.   One 
  147. identifies  the  mail handler,  another identifies his modem type 
  148. and a third  should  identify  when  mail/file  requests  can  be 
  149. accepted.  
  150.  
  151.  
  152.                          The other flags           
  153.                             ---------
  154.  
  155.  
  156. The  other  two  flags  would  represent mail reception times and 
  157. modem type.  
  158.  
  159. For example the flag 00 would represent mail can only be received 
  160. during NMH.  Flag 01 would mean mail could be received 24  hours, 
  161. identical  to  the  meaning of the CM flag now.  Other variations 
  162. could be: 
  163.  
  164.    00 National Mail Hour Only for Mail 
  165.    01 Continuous Mail 24 hour/day 
  166.    02 Continuous Mail 24 hour/day with 24 hr File Request Capability 
  167.    03 CM 24 hrs/day, File request all but NMH 
  168.  
  169. The third flag would represent modem types:
  170.  
  171.    00 300 baud Bell standard
  172.    01 1200 baud Bell standard
  173.    02 2400 baud 
  174.    03 1200 baud w/MNP
  175.    04 2400 baud w/MNP
  176.    05 USR HST Modem
  177.    06 Telebit Trailblazer Modem
  178.    07 Hayes V9600 Modem
  179.    08 Microcom Modem 9600 baud
  180.