Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    HOTDOGED    |    Support for the HotDogEd software    |    1,000 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 118 of 1,000    |
|    mark lewis to Ulrich Schroeter    |
|    No Echolist with hotdogED?    |
|    23 Oct 13 05:58:46    |
      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 zip'd        US>> 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               that's why the request is passed on upstream to the feed's uplink for       processing... if they don't have the areatag, then they forward it to their       upstream etc etc etc until it reaches "the top" and either finds the area or       not... if the area is found, then it propogates back downstream... if the area       is not found, the "not found" message should travel back downstream as well so       that the original node requesting 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.*              all of those would be listed in the %AVAIL response... provided, of course,       that the feed has "properly" gathered those lists from their upstream feed(s)       and configured them in their tosser... without them, the tosser can't forward       unfullfilled requests upstream for fullfillment so they are needed anyway...               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 a        US> local compile of the lists the node supports              it doesn't matter where the feed comes from, does it? a point wants an echo so       they request it from my system... my system has lists for each of my upstream       feeds... my tosser finds the requested area listed in one of those and sends       the request to them for fullfillment... the point system doesn't care where it       comes from as long as they are able to pull it from my system...               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               the tossers do this with the %AVAIL request...               ml> something, perhaps, like the list of        ml> available areas (%AVAIL) from the feed's uplinks?               US> some support, some may not ...              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 =;)              that's not a distribution path... those are coordinator positions... they are       not required to distribute echomail and never have been... Zone1 dealt with       dictators in those positions back in the 90s and showed that free market is       better... especially when some of those *ECs were playing politics with the       message areas... besides, *ECs are created by their *C as an assistant to the       *C... a *EC does not have to exist for any *C...               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               and if one is just joining and had nothing to go by other than lists they can       get from their feed?               US> freq echolist from a CDP flagged node in Zone 1 will probably        US> result in a complete different list than frequesting echolist from        US> a CDP flagged node in Zone 2, so the localy compiled echolist is as        US> is, a compilation of the echoes a downlink can request via areafix        US> from the node where the node/point is connected to. A CDP system        US> schedules a echolist freq monthly, so if new areas are available,        US> the compiled list will be updated.               US> The request is a kickoff for connecting to a node, you have no info        US> how fidonet works, whats echoareas are. Thats why the CDP package        US> starts with a compiled list of available echoareas a CDP point can        US> request via an option list. Here there is no joker available ...        US> If you want more, and have learnt more you can do more like write a        US> netmail to areafix of your uplink ... netmail what ? .-)               ;)              oh yeah, i almost forgot [/devil's advocate] O:)              )\/(ark              --- FMail/Win32 1.60        * Origin: (1:3634/12.71)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca