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)