home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS 1992 September / Simtel20_Sept92.cdr / msdos / packet / mb1107.arc / SID.DOC < prev    next >
Text File  |  1989-01-22  |  4KB  |  113 lines
  1.  
  2.  
  3.        System IDentifiers (SIDs)
  4.  
  5.  
  6. The initial exchange between "smart" MailBox systems uses what is called
  7. an "SID", short for System IDentifier. All future work on MailBox systems
  8. should adopt this standard. It will help to remove a GREAT deal of
  9. confusion as to which systems have what features, and how one should
  10. interface to them. In the longer future, perhaps all this junk can be
  11. done away with, and the computers can talk to each other in a more
  12. natural way.
  13.  
  14.  
  15.      The system identifier is structured:
  16.  
  17.      "[f1-f2-f3]"
  18.  
  19. The dashes delimit the end of the first field and the start of the last.
  20. There might be only one dash, if f2 is void. f2 may contain dashes.
  21.  
  22. f1, f2, and f3 may not contain "[" or "]".
  23.  
  24. f1 is the author identification. It may not contain a dash.
  25. Normally it will contain a few characters from the authors callsign.
  26.  
  27. f2 is author specific data.
  28. It may contain anything the author wishes, for example software version.
  29. It may contain dashes.
  30.  
  31. f3 is the supported feature set. It may not contain a dash.
  32. It contains a string of non-numeric characters, one for each negotiable
  33. feature supported. Each character may also have trailing digits, giving
  34. the revision of that feature. If there is no trailing digit, the
  35. feature revision is revision zero.
  36.  
  37.  
  38. Defined features are:
  39.  
  40.  
  41. C - Supports "forwarding" of date and time.
  42. H - Supports hierarchical routing.
  43. Y - Supports YAPP binary protocol.
  44. $ - Supports BID. MUST BE LAST CHARACTER IN f3 (downward compatibility).
  45.  
  46.  
  47. The existance of the system ID implies that the system supports
  48. reverse forwarding and OK/NO message rejection.
  49.  
  50. Some examples of existing standard system identifiers:
  51.  
  52. [RLI-5.12-$]          - w0rli version 5.12, supports BID
  53. [RLI-9.05-CH$]          - w0rli version 9.05, supports Clock, BID, H routing.
  54. [CBBS-5.1-$]          - ag3f release of the rli/gyq cbbs.
  55. [MBL-5.12-$]          - wa7mbl V5.12, supports BID.
  56. [MBL-RLI3.2J2.5-$]    - jr1ede unix port of rli/gyq cbbs version 3.2
  57. [4RE-2.3-MH$]          - aa4re V2.3, supports MID, BID, and H routing.
  58.  
  59.  
  60. There is some older code still running that requires special case handling.
  61. In these cases there is no f3 or feature letters.
  62.  
  63. Rule: OK/NO message rejection is required, and BID is supported.
  64.  
  65. [MBL320]       - "old" wa7mbl systems.
  66. [MBL=RLI]       - ja0isk port of rli/gyq cbbs for NEC 9800
  67.  
  68.  
  69.  
  70.     The connect rules:
  71.  
  72. Send the SID as first line at connect.
  73. Answer the SID (when seen as a command) with a short command prompt.
  74.  
  75.  
  76.     The forwarding rules:
  77.  
  78. If you do not see an SID at connect, use the old style fowarding.
  79. This handles the case of Xerox 820 systems, for example.
  80.  
  81. If you do see an SID at connect, answer with your SID.
  82. Use whatever features are appropriate.
  83.  
  84.  
  85. Special case: MBL3 or MBL= seen at connect.
  86. Reply with [MBL-xxx], where xxx is anything you like.
  87. Continue with reverse forwarding and OK/NO message rejection.
  88.  
  89.  
  90.       The message entry command:
  91.  
  92. Sx TO [@ BBS[.LOC]] [< FROM] [$BID]
  93.  
  94. x may be B, T, or P.
  95. If x is absent, P is assumed if TO is a callsign, otherwise B is assumed.
  96. The $ is not part of the MID (or BID), but identifies the field.
  97. There is no space between the $ and the BID.
  98.  
  99.  
  100.       OK/NO message rejection.
  101.  
  102. Instead of sending the "S" command and Title, send only the "S" command.
  103. The remote system will reply with either OK or NO, possibly followed by
  104. some text. If the resonse is NO, it will be followed by a prompt. If the
  105. response is OK, then go ahead and forward the message. Usually, NO will
  106. only be seen if you attempt to forward a message with MID already known
  107. to the recieving system. It may also be seen in the case of full disk, or
  108. any other reason the system does not want the message. Possiblities under
  109. discusion range from "I do not handle NTS traffic." to "I do not know that
  110. user, nor any route to reach him."
  111.  
  112.  
  113.