ml> in the above: ml> 1. the first ITN,IVM apply to the f.n.z.domain.tld converted ml> connection address because there is no FQDN or IP number listed.
That is a nono. After the folding of fidonet.net the Fidonet community realised that depening on a third party over which Fidonet has no control is a bad idea. The nodelist is the primary source of Fdionet connection information. All the information to make a connection MUST be present in the nodelist. DNS distributed nodelists as documenetd in FTS-5004 are an /additional/ service, not a replacement for the nodelist.
ml> 2. the first IBN applies only to site1.tld. there is no ITN or IVM ml> there and the f.n.z.domain.tld doesn't handle it at all.
DNS distributed nodelists are a third part service. The Fidonet nodelist clerks have no control over it. They can not stop the operator of that service to include it,.
ml> 3. the second ITN applies only to site2.tld. there is no IBN or IVM ml> there.
ml> 4. the fourth site, site3.tld, handles all three connection types.
I have tried ro reverse engineer it back into a real physical system and with the exception of 1, I got something that translates back into a FTS-5000/FTS5001 compatible nodelist line as follows:
It is a mystery to me why anyone would compose such an exotic system. Why on earth would anyone with a multihomed connection - IBN is reachable via two different paths and so is ITN, so the system is multihomed - only make some servers available via multihoming and some others only via one path?
This look like a system with a multi personality disorder. The more logical and I also think better way to understand for humans is to use more than one node number.
This is how it was done in the POTS age when one had more than one lines with modems with different capabilities connected.
ml> intelligent mailers and nodelist using software would have no problem ml> with this... it should also allow for the Xx flags to be listed with ml> each as well as pretty much all other flags... i can easily see the ml> Txy flags being listed with INA flags indicating that sitex.tld is ml> operational at certain times...
Another one of your unrealistic exotic scenerios. "Smooth operation of the network" is not served by building system with excotic combinations of on-line times. Limited on-line times in addition of ZMH only makes sense for POTS systems where a singes line is shared between Fidonet and another service such as voice or fax. A classic POTS line can handle just one connection per physical line. Internet connection do not have that limitation. One physical line can carry many connection, so time sharing between services is not needed. All services can use the line simultaneously at all times.
Limiting time depending on service makes no sense.
If you had a shop I think you would quickly lose cunstomers if ther was a sign on the door.
Closed between 18:00 and 07:00 and bewteen 13:00 and 13:30 Open for selling eggs from 08:00 to 12:00 and 14:00 to 14:30 Open for selling milk from 07:00 to 07:30, 13:00 to 14:00 and 16:00 to 19:00 Open for bread from 06:00 to 15:00
etc...
ml> the sad thing is that the intelligence that mailer software used to ml> have has been lost...
It is those that demand that the systems covers more and more protocols in exotic scenarios that are partly to blame for that.
The popularity of binkd can be partly ascribed to it NOT being a Swiss army knife and only covering the basics needed to exchange files between systems.
