Subj : Re: BBSINFO Data Requirements
To   : stizzed
From : tenser
Date : Sun Jun 07 2020 01:20:04

On 04 Jun 2020 at 11:38p, stizzed pondered and said...
 
 st> Here is the latest compilation of information we have discussed
 st> including in the new BBSINFO DataFile (whatever form it takes).  I am
 st> posting this to further the conversation about the standard:
 st> 
 st> BBSINFO:
 st> 
 st>  Zone      // BBS ZONE NUMBER (224)
 st>  Net       // BBS NET NUMBER (10)
 st>  Node      // BBS NODE NUMBER (0)
 st>  BbsName   // BBS NAME (My New BBS)
 st>  City      // BBS Location (City)
 st>  State     // BBS Location (State)
 st>  Country   // BBS Location (Country)
 st>  Language  // BBS Language (ENG, SPN, FRC, GMN, etc)
 st>  SysopName // SYSOP NAME (Johnny SysOp)
 st>  Phone     // BBS PHONE NUMBER (888-555-1212)
 st>  BBSURI1   // FULL BBS URL W/PORT (telnet://bbs.domain.tld:23)
 st>  BBSURI2   // FULL BBS URL W/PORT (rlogin://bbs.domain.tld:513)
 st>  BBSURI3   // FULL BBS URL W/PORT (www://www.bbs.domain.tld:80)
 st>  BBSURI4   // FULL BBS URL W/PORT (ssh://bbs.domain.tld:22)
 st>  Nodes     // TOTAL # OF NODES SUPPORTED (DIALUP & TELNET)
 st>  Callers   // AVERAGE DAILY CALLERS TO THIS BBS (25)
 st>  Online    // BBS Operating Hours-GMT (0000-0000 or 0700-1800)
 st>  Software  // BBS SOFTWARE (Mystic v1.12 a45)
 st>  Delete    // FLAG FOR DELETION BY DOWNSTREAM SYSTEMS
 st>  Verified  // DATE INFO WAS VERIFIED (20200605)
 st>  LognType  // LOGIN TYPE (1=realname/2=handle/3=choic )
 st>  cType     // BBS TYPE (1=dialup/2=telnet/3=both

This is unstructured and basically a linear bag of fields;
but almost all structured formats can let you group things
together in more semantically meaningful ways.  Consider
the following, in a sort of pseudo-EBNF style grammar:
Let a token be followed by a `?` be considered optional:
that is, zero or one of the token.  Let tokens followed
by a `*` be considered repeated 0 or more times.  Let
tokens followed by a `+` denote 1 or more.  Let
`token1|token2` alternation, or either of those tokens.

ftnAddress := Zone? Net Node Point? Domain?
ftnMember := NetName ftnAddress+
Location := City State Country
Service := Name Host Port?
LoginType := (RealName|Handle|Either)
CharEncoding := (UTF-8|ASCII|ISOLATIN1|CP437)
BBSOtherData := NumNodes? AvgCallers? AvailTimes? LoginType?
BBS := Name SysOp Location? Language* ftnMember* (Phone|Service)+
       BBSOtherData? LastVerifiedTime CharEncoding*

I wouldn't bake a "deleted" flag into the data format.
Rather, if one wants to delete, that should be part of
a "delete this entry" sort of thing.

Note that this will map well to something like JSON or
whatever, or even DNS.  An example for my system might
be:

"FatDragon": {
    "name": "The Fat Dragon",
    "sysop": "Dan Cross",
    "location": { "city": "New York City" },
    "language": [ "English" ],
    "charencoding": [ "ASCII", "UTF-8" ],
    "ftn": [
        {
            "netname": "fsxnet",
            "ftnaddress": {
                "zone": 21, "net": 1, "node": 198, "domain": "fsxnet"
            }
        }
    ],
    "service": [
        { "name": "ssh", "host": "fat-dragon.org", "port": 22 },
        { "name": "http", "host": "fat-dragon.org", "port": 80 },
        { "name": "binkp", "host": "trunk.fat-dragon.org", "port": 24554 }
    ],
    "otherdata": { "numnodes": 1024 },
    "lastverified": "2020-06-06T13:13:13Z"
}

--- Mystic BBS v1.12 A46 2020/05/28 (Windows/32)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.