Hello mark,

On Saturday October 04 2014 13:29, you wrote to Alexey Vissarionov:

 ml> eg:
 ml>  ,12,some_system,some_location,a_sysop,#-###-###-####,33600,XA,V34,CM,
 ml> / ITN,IVM, / INA:site1.tld,IBN, / INA:site2.tld,ITN,
 ml> / INA:site3.tld,IBN,ITN,IVM, / PING

 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:

,12,some_system,some_location,a_sysop,#-###-###-####,33600,XA,V34,CM,
INA:site3.tld,IBN,ITN,IVM,IBN:site1.tld,ITN:site2.tld,PING

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.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111