Text 10055, 261 rader
Skriven 2013-08-27 16:16:46 av Ulrich Schroeter (2:244/1120)
Kommentar till text 10042 av Mark Lewis (1:3634/12.0)
Ärende: Internet access - Fidonet Policy thoughts ....
======================================================
Hi Mark,
Monday August 26 2013 21:00, you wrote to me:
ml> On Mon, 26 Aug 2013, Ulrich Schroeter wrote to Joe Delahaye:
JD>> Re: Internet access
JD>> By: mark lewis to Joe Delahaye on Sun Aug 25 2013 14:29:33
JD>> ...
>>> some months later to carry message area traffic and became known
>>> as echomail... echomail has always revolved around user's
>>> traffic...
JD>> Of course, but to this day, nowhere does it state that you have
JD>> to run a BBS. A mailer will suffice. No BBS, no users. No
JD>> users, means no echomail eminating from your system, other then
JD>> what you the operator write.
ml>
US>> p4.07 intro
ml>
US>> This document establishes the policy for sysops who are members
US>> of the FidoNet organization of electronic bulletin board systems.
ml>
US>> conclusion: every node listed in nodelist is a sysop with a
US>> running bulletin board system ... aka BBS =:D
ml>
ml> it may say that but even back in the 80s there were MO (Mail Only)
ml> systems and they did not run any BBS software... they were either HUBs
ml> of some sort or they were private systems with no BBS or users... in
ml> some cases, they actually did run a BBS and they did have users but
ml> this was not acvertised in the nodelist and contacting them via the
ml> advertised nodelist method(s) resulted in no access to the BBS...
ml>
US>> The first step in obtaining a current nodelist is to locate a
US>> FidoNet bulletin board.
ml>
ml> no... just a fidonet related system that carries the necessary
ml> software, policy document and nodelist files...
you're doubt Policy 4.07 ?!? the fidonet's bible ?-)
all sentences are copied and pasted 1:1 out of P407 ,-)
US>> A coordinator is encouraged to operate a public bulletin board
US>> system which is freely available for the purpose of distributing
US>> Policy, FidoNews, and Nodelists to potential new sysops.
ml> "encouraged" is the operative word here...
sure ..
P407 is full of "BBS" references ... starting with "defining a group of BBS
systems forming a net" (in my words)
but isn't the topic I want to focus on ... more on later ...
US>> Dissemination of this information to persons who are potential
US>> FidoNet sysops is important to the growth of FidoNet, and
US>> coordinators should encourage development of new systems.
ml>
ml> yes... however, the information and files can still be gathered
ml> without a BBS...
ml>
US>> Policy, FidoNews, and the nodelist are the glue that holds us
US>> together. Without them, we would cease to be a community, and
US>> become just another random collection of bulletin boards.
ml>
ml> true... without the strict definition of "BBS"...
ml>
US>> All above sections speaks about "Bulletin Board Systems", not in
US>> Systems (Nodes), running a mailer
ml>
ml> hey, you can't really blame the "armchair lawyers" who put P4
ml> together, can you?
:D
ml> then again, many don't take current policy in its
ml> entirity, either... just like EP1, they pick and choose the parts
ml> that fit them at the moment...
so we may come to the conclusion, that P407 is outdated ... not entirely
but in specific sections, can we?
US>> In Ward's mail writing, that running a BBS on a POTS line makes
US>> no sense nowadays ... but there is an increase of running Telnet
US>> BBS systems servicing Fido-over-IP, so which makes sense ..
ml> yes... pretty much...
US>> What I'll try to focus on is, that P4.07 now is a 24 years old
US>> policy The "ideas" to group "Bulletin Board Systems" together to
US>> be listed as Fidonet members was based by 1989's technique. Now
US>> the world moved forward, Fidonet still exist ... but the
US>> requirements still did change
ml>
ml> true...
ml>
US>> We have to switch between POTS, ISDN, IP, maybe more comes in the
US>> future?!?
ml>
ml> more is already here and has been for ages... i've yet to see a
ml> totally radio operated system properly listed in the nodelist only by
ml> their radio capabilities... they were forced to have POTS and/or
ml> internet connectivity...
ml>
ml> this is one reason why africa ended up falling apart in the
ml> nodelist... there were other problems as well but fidonet used to
ml> travel via packet radio until some pright bulb figured out how to use
ml> TCP/IP over packet radio and lessen the transfer rates (at 9600) even
ml> more... but at least they did have "live" bidirectional comms...
ml>
US>> We have to deal with probably no POTS BBS system remaining,
ml>
ml> wrong... i'm still POTS capable as are many others... specifically
ml> because of what happens when storms and other natural events take out
ml> the connection capability...
:D
ok ok ok ... 1 POTS system remaining ... :D
the real challenge is, to get the problems fixed, that focus fidonet
onto one specific physical layer definition
Fidonet's practice has shown, that it can survive if we exclude specific
P407 definitions, or make an update on these specific definitions, that allows
variations of connection layers ...
The challenge is, how to define it in a policy ?
fts documents only documents practice, but the Policy is a document, how we
want to interact ...
To ban POTS is the wrong signal ... somewhere later there is a definition, that
encourage developers also to implement other protocols, but this isn't the
topic we have to focus on
Probably we have to go back to Tom Jennings philosophy
(that he gave in an interview) forming a network of
independent nodes to have a free independant network
collected, defined by the nodelist
having in mind, that in todays world we have as many
independant physical transport layers to connect
nodes together, but not all can support all the layers.
To focus on one layer that is used by the majority doesn't makes
sense either ... as you've shown with the packet radio sample ...
there are probably much more connectivity layers we don't have
heard before that developers will try to use to connect a
fidonet system.
So here we should rethink, how we can bring in P407 in shape
with current situation with POTS, IP, Packet radio? and probably
other layers and a solution, that allows nodes to communicate
with others using a different connection layer that one
cannot support
Probably it doesn't have been picked up, as nobody still has an answer?!?
maybe "dynamic inteligent routing" is an answer?
maybe "using nearest elevator systems" (similar to Zone gateways solution)
is an answer?
There is one definition in Policy to use "local" areas.
The reason for this clause is, that nodes do not have to pay unforseen
expenses while calling other nodes.
If I check the IP network, the whole world is the "local area" as I do not have
to pay any extra fees for calling a node in my own city (Frankfurt/Germany) or
if I call a node in Australia or if I call a node in the US
One idea in the development of FoIP was to move IP nodes into its own region
long time region 55 did run within zone 2
Maybe, we have to rethink, to use different Zones for different connection
layers?
But what maybe the result if one has a POTS line supported under zone 1
and an IP line supported under zone .. eg 8 ?
If I myself have a zone8 aka, I can contact the node directly by his zone8 aka
or via POTS if I have a zone2 aka (rethoughts still to continue)
The main question out of these rethinking is, that the requirement
that each node is able to contact another node directly can no longer stand
as its still current practice, and practice has shown that it still works
so therefor its necessary to update this policy paragraph ?
US>> but we have a couple of Telnet BBS systems. How a POTS user can
US>> connect into a Telnet BBS system ?!? (the question still makes
US>> no sense ... we probably have lesser POTS systems running than
US>> the nodelist tells. My assumption is, that 90% of all fidonet
US>> traffic is handled via FoIP
ml>
ml> true to an extent... as for POTS users connecting to a telnet only
ml> system, that's easily handled via an intermediary system that offers a
ml> bridge between the two systems...
:)
US>> An update of Policy 4.07 still hasn't picked up by anyone so its
US>> an undone task. The open question, if its still necessary or can
US>> we live with this 24 years, imperfect policy these days ?
ml> policy simply needs some updating... the problem is conforming to the
ml> existing methodology...
US>> A rethinking about CMH is necessary, as it doesn't apply to the
US>> majority of all systems (times of multilines, FoIP with
US>> multitasking, splitting services BinkP / Telnet) indicates that
US>> this paragraph requires an update.
ml> CMH? crash mail hour? continuous mail hour?
aeh .. ZMH ... long time not used ... as my systems are CM since starting
with fidonet and I do not take care so much on this definition, excepts
its configured in the mailers since years, so what ...
US>> To implement a mechanism, that allows several different physical
US>> layers to communicate via an elevator concept
ml> in a manner of speaking, yes... as i note above...
US>> But these are not the only topics ...
ml> true...
US>> The days are counted, until my POTS line dies by ISP restictions
US>> same for ISDN ... so I'm no longer policy conform running a POTS
US>> line ?!? ?-)
ml>
ml> i refuse to give up my copper connection specifically because it is
ml> all too possible (and has happened in recent times) that the internet
ml> will not be accessible or operational for any specific entity... in
ml> almost all cases in the last 20+ years that my internet has been
ml> inaccessible, i've still had POTS to fall back on... there has only
ml> been a very few times that my copper didn't work for direct and
ml> dedicated connections... those are getting harder and harder to
ml> maintain, though, as more and more systems fall victim to the hype and
ml> propeganda :(
the idea is not to ban out any systems .. its the contrary .. bring in more
systems with a global definition, that allows systems to communicate :)
from other policies works my experience is, as less you are specific about a
definition in technical terms, as more you are able to fix a certain problem
technicaly
Like the global rules about XAB and not to be easily annoyed ...
these 2 clauses works since 25 years and will work in 25 years too :)
To be strict where its needed, to be open where it allows growing
and development
eg. Fidonet is a group of sysops forming the net by using FTN technology
systems to communicate and transfer informations, defined by the fidonet
nodelist
where the FTN technology definition is outsourced to the FTS documentation :)
One requirement that can be defined:
that each node is able to connect another node at the same physical layer
(but there may exist several different physical layers.....)
The answer to transport informations between different layers maybe
to use "elevator" systems or leave it open to developers ...
the new definition "elevator systems" may give room, to operate via
zone gates, or define new protocols via FTS that allows inteligent routing
between different physical layers via "elevator systems"
ok, enough for today .. I have to leave for today ..
ml> )\/(ark
ml> $ Origin: (1:3634/12)
regards, uli ;-)
---
* Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)
|