Hi Mark,

Wednesday October 23 2013 05:58, you wrote to me:

 ml> On Wed, 23 Oct 2013, Ulrich Schroeter wrote to Mark Lewis:

 US>>> CDP proposal
 US>>> FSP-1016.003  Automatic configuration of Points in Fidonet
 US>>> has answered this question regarding echo forwarding lists ....
 US>>> in section   3.1.2.1.2 ECHOZZZZ.ZIP and  3.2.2  Transmitting the
 US>>> application date

 ml>> -> Freq  ECHOLIST

 US>>> The only thing to consider ... nodes supporting HotDogED clients
 US>>> should add the freq magic ECHOLIST in their system and
 US>>> ECHOZZZZ.ZIP to be sent. So on the supporting system the echo
 US>>> uplink lists have to be compiled and named ECHOZZZZ.LST and
 US>>> zip'd thereafter ...  =;)

 ml>> is there anything wrong with sending the existing, published and
 ml>> distributed Echolist?

 US>> yes, it probably doesn't reflect the nodes "echoes" capabilities

 ml> that's why the request is passed on upstream to the feed's uplink for
 ml> processing... if they don't have the areatag, then they forward it to
 ml> their upstream

or not ... depends on the nodes echo forwarding rules
and here each sysop may have his own rule
its free to each sysop which echoareas he presents to his downlinks

only echoes that are still setup in the sysops tosser?
also a group of regional available echoes?
or dumb all and everything ?

the set of echoes may vary from system to system


 ml>  etc etc etc until it reaches "the top" and either finds
 ml> the area or not...

or the direct uplink reports "not avail"

 ml>  if the area is found, then it propogates back
 ml> downstream... if the area is not found, the "not found" message
 ml> should
 ml> travel back downstream as well so that the original node requesting
 ml> the area will know that it is not available...

 US>> so one node only supports the official "international echoes"
 US>> (known under BACKBONE.NA and ELSTYYMM
 US>> the next node supports international + zonal + regional specific
 US>> echoes and the 3rd supports all node 2 supports + have a list of
 US>> own nets and local areas, and also supports some specific areas
 US>> from other languages ESP.*, BR.*, RU.*

 ml> all of those would be listed in the %AVAIL response...

if you do all this manualy ... no problem
in the case you would like to automate this process
read-in the response of a received list of areatags and descriptions
to present the user to select one of it you're still running shortly
in the clash of a lot of different report format - one with a lot of cermon
starting with the list, one grouped into as many groups with header and footer
infos each, one splitted into x messages, another one all include in one, the
next one starts with symbols in front of the areatag, the next only lists
areatag dotted to a fixed column and than description wrapped in several lines
- still worse to redefine the wheel you have to "normalize" the different
report formats so you can automate this process

so why not use the existing fileformat of echo forwarding lists?
with a known standard   AREATAG description  ?
as every tosser supports?

eg I have about 10 different echo forwarding lists implemented into my tosser
to receive 10 different groups of echoes from 10 different sources
so my downlinks receives one list compiled out of these 10

CDP nodes are still present in the nodelist, who supports the echolist magic
with a standardized combined echo forwarding list of echoes an uplink
offers to his downlinks.

If a downlink wants more, that isn't present in this received combined list,
well, he has to go the long walk either way ...

Zone 1 may have only one uplink list, but zone 1 is not the whole world ..
there are other zones with quite more and different lists .. especialy Zone 2
has their own individual languages with individual sets of echoes
BR, ESP, GER, NL, RU as far as I know, but maybe others


 ml>  provided, of
 ml> course, that the feed has "properly" gathered those lists from their
 ml> upstream feed(s) and configured them in their tosser... without them,
 ml> the tosser can't forward unfullfilled requests upstream for
 ml> fullfillment so they are needed anyway...

as said before, I have around 10 different echo forwarding lists
some are automaticly distributed like backbone.na, many others I have to
manualy extract from areafix responses received from differnt link feeds, to
present it in the standardized echolist format
all them compiled together into one list ECHO0002.ZIP with file ECHO0002.LST
included and frequestable as magic ECHOLIST as per fsp-1016

 US>> so you have 3 different potential link partners with 3 different
 US>> capabilities. One uses backbone.na + local.na, the next uses list
 US>> fareas.bbs and a third uses the standardized ECHO0002.LST that is
 US>> a local compile of the lists the node supports

 ml> it doesn't matter where the feed comes from, does it? a point wants an
 ml> echo so they request it from my system... my system has lists for each
 ml> of my upstream feeds... my tosser finds the requested area listed in
 ml> one of those and sends the request to them for fullfillment... the
 ml> point system doesn't care where it comes from as long as they are able
 ml> to pull it from my system...

from where does your point downlink system knows about an echo from the
starting point ?

step back ... you nothing now about "areafix" .. "echoes" and so on ...
install the HOTDOGED application and ... ya what ?
go to the configuration section ... request echoareas ...
what echoareas ?
here you have to present a list .. a list of echoes that are
available from the nodesystem you've still connected to in your setup
while receiving a "standardized" filenamed echolist from the uplink of echoes
that are still available from this node system, maybe that the node only
offers a limited set of echoes, maybe he offers a full set of echoes, its
still an undef. set of echoes, quite different from system to system

the last time downlinks requested mass of international echoes was 15 years
ago (!) the downlinks requested only local, regional, and zonal echoes.
this did change in the last couple of months so I also see requests for
international echoes ... and while the auto forwarding via the default link
didn't worked I've manualy searched for other uplinks for the backbone.na set
of echoes


 ml>>  is the above perhaps talking about something
 ml>> else other than the Echolist?

 US>> a local compilation of one or more or many different echo
 US>> forwarding lists

 ml> the tossers do this with the %AVAIL request...

forget %AVAIL !!!
that is unusable for automatic processing
you know that unconditional forwarding is an optional switch in
many tossers ? and a node system may have it deactivated ?

you'll may respond, then change the link ... so you can switch from one to
another link until you'll find one, who offers a full set of echoareas
that are comfortable to you ... well .. but how gets the downlink the infos
of unstructured data of different areafix reports collected into a usable list
of well structured echolist format list ?



 ml>>  something, perhaps, like the list of
 ml>> available areas (%AVAIL) from the feed's uplinks?

 US>> some support, some may not ...

 ml> true... those that do not could loose market share ;)

 ml>>  where are other,
 ml>> unlisted, area names to be found?

 US>> default path: ask the NEC, REC, ZEC  =;)

 ml> that's not a distribution path... those are coordinator positions...
 ml> they are not required to distribute echomail and never have been...

if an area cannot be found -> ask Uplink, NEC, REC, ZEC

also if an area is in one of the many echo forwarding lists circulating
around, one link may have not the areas available and cannot request it, as he
is one of down- down- down- downlink of a distribution path and somewhere in
the middle the path is broken ... remember the Holger case with PCBOARD ...
you can request, request, request, but nothing happens ...

at some point you have to switch the level from automatic processing to manual
processing

whats automaticly available is simply compiled in one ECHOLIST for one
specific link ... and another ECHOLIST for another link

 ml> Zone1 dealt with dictators in those positions back in the 90s and
 ml> showed that free market is better... especially when some of those
 ml> *ECs were playing politics with the message areas... besides, *ECs are
 ml> created by their *C as an assistant to the *C... a *EC does not have
 ml> to exist for any *C...

similar here within Zone 2, but within Zone 2 each region had their own
strategy of echomail distribution .. some shared distribution, some built
their own, some other Regions participated on the existing infrastructure
This did work in the 90's and upto the mid 2000's since than international
echomail distribution felt asleep ... unorganized, still some remaining main
echo distribution systems, but in principle uncoordinated (this also applied
to the *EC structure that felt asleep ....)

Have a look into several areas paths and seenbys ... and you get an idea what
happens within Zone 2.. R50 has their own backbone, R24 has their own
backbone, now connected with the R28 backbone, R31 linked since several years
to the R24 backbone, other Regions have other individual link agreements ...


 ml>>  how is one to know of the existance
 ml>> of an area if it is not in the %AVAIL or %LIST areafix responses?

 US>> hearsay, discussions in echoes, requests in a sysops chatter

 ml> and if one is just joining and had nothing to go by other than lists
 ml> they can get from their feed?

switch to manual mode
ask uplink, NEC, REC, ZEC

 US>> freq echolist from a CDP flagged node in Zone 1 will probably
 US>> result in a complete different list than frequesting echolist
 US>> from a CDP flagged node in Zone 2, so the localy compiled
 US>> echolist is as is, a compilation of the echoes a downlink can
 US>> request via areafix from the node where the node/point is
 US>> connected to. A CDP system schedules a echolist freq monthly, so
 US>> if new areas are available, the compiled list will be updated.

 US>> The request is a kickoff for connecting to a node, you have no
 US>> info how fidonet works, whats echoareas are. Thats why the CDP
 US>> package starts with a compiled list of available echoareas a CDP
 US>> point can request via an option list. Here there is no joker
 US>> available ... If you want more, and have learnt more you can do
 US>> more like write a netmail to areafix of your uplink ... netmail
 US>> what ?   .-)

 ml>  ;)

 ml> oh yeah, i almost forgot [/devil's advocate] O:)

a few days ago I've received a request from R50 for a link, 'cause their main
uplink is no longer available (net 2411 closed October 3rd). Maybe the link
was active and reliable in the past, but the sysops decided to shut down their
net. Depending on the echolist they'll want via this link, its still a subset
of echoes available worldwide ...
The sysops of echomail hubs works mostly manualy to establish new links so no
longer working paths can be recovered .. but not all delivers such support.
So some say, here is the list of available echoes. Thats it. Otherwise search
for another uplink .. here I can only speak for R24 .. and R24 is still in
recovery mode ... The backbone.na set is now recovered, so therefor the fast
initializing of HOTDOGED did work, but for all the rest (of about 10 different
sets of zone, regional, net echolists) revovery still continues ...


 ml> )\/(ark
 ml> -$- FMail/Win32 1.60
 ml>  $ Origin:  (1:3634/12.71)

regards, uli   ;-)

---
 * Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)