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)