Text 10088, 543 rader
Skriven 2013-08-28 15:23:35 av Ulrich Schroeter (2:244/1120)
Kommentar till text 10059 av Mark Lewis (1:3634/12.0)
Ärende: Internet access - Fidonet Policy thoughts ....
======================================================
Hi Mark,
Tuesday August 27 2013 15:13, you wrote to me:
ml> BTW: i have fixed the nasty quotes your editor made... my editor does
ml> NOT quote blank lines... no editor should prefix quotes to blank
ml> lines... i have also inserted some (proper) blank lines to separate
ml> the quoted sections for readability...
probably fixed while changing one switch in the editors config ...
ml> On Tue, 27 Aug 2013, Ulrich Schroeter wrote to Mark Lewis:
US>>> p4.07 intro
US>>>
US>>> This document establishes the policy for sysops who are members
US>>> of the FidoNet organization of electronic bulletin board
US>>> systems. conclusion: every node listed in nodelist is a sysop
US>>> with a running bulletin board system ... aka BBS =:D
ml>> it may say that but even back in the 80s there were MO (Mail
ml>> Only) systems and they did not run any BBS software... they were
ml>> either HUBs of some sort or they were private systems with no BBS
ml>> or users... in some cases, they actually did run a BBS and they
ml>> did have users but this was not acvertised in the nodelist and
ml>> contacting them via the advertised nodelist method(s) resulted in
ml>> no access to the BBS...
US>>> The first step in obtaining a current nodelist is to locate a
US>>> FidoNet bulletin board.
ml>> no... just a fidonet related system that carries the necessary
ml>> software, policy document and nodelist files...
US>> you're doubt Policy 4.07 ?!? the fidonet's bible ?-)
US>> all sentences are copied and pasted 1:1 out of P407 ,-)
ml> the conclusion is not... that is your writing...
my conclusion started 2 sentences below ...
starting with "P407 is full of "BBS" references ...."
what probably policy writers had in mind if they've wrote
the policy, in defining "what makes Fidonet" ...
Back in 1989 it was the time of the BBS scene
in the DVD "BBS Documentary"
Part1 Baud
Part2 Sysops and Users
Part3 Make It Pay
Part4 Fidonet
Part5 Art Scene
Part6 HPAC
Part7 No Carrier
Part8 Compression
Part4 starts with the message "Fidonet is a strange beast" =:D
the link: http://www.bbsdocumentary.com/
(thanks to Steven Leeman from Belgium, forwarding this link :) ...)
in the first days, the nodelist was a list of sysop who used the program "FIDO"
to connect to other systems ... History moved forward and several other mailers
speaking FTN protocols appears and to be listed in the nodelist, that was a
handwritten list in the early days with system name, phonenumber, probably
connection parameters and the sysops name, moved forward from the 2D to 4D
addressing we have today. First electronicaly distributed nodelist starts day#
219 in 1987 ...
As I've started back in 1989, I've started with BBS'ing, got the info from
other sysops how to exchange BBS's boards mails with other BBS's that did
result in my first fidonet listing :)
The focus by these days was still on BBS systems ... exchanging mails out of
BBS'ses to another BBS so that one question probably can be read at another BBS
system gets a response, from a BBS user who can give an answer to the question
One idea of many BBS sysops was to extend the potential users base who can
communicate via mails
so the policy definition was the try to define the scope of "fidonet sysops"
Policy speaks about users and points, not to be "fidonet members" per
definition, they are still "users" ...
This definition relates to the necessity that responsibily needs
to be defined. In the case, something goes wrong, you catch the fidonet systems
sysop, but you probably cannot catch the user who was a onetime user in a bbs
...
If you look around to other policies (non-fidonet policies) the responsibility
is defined either way .. so its defined in Fidonet policy too.
The procedures of change management (adding new systems, removing systems)
is defined by the *C structure
So all elements that defines a policy are there
The policy also covers 2 parts: the technical part and the social part
The technical part is mostly outsourced to FTS documentation, the social part
is defined by the 2 major XAB/AB rules. Fidonet's court (internal arbitration)
referenced to the *C structure
The organisations "internal arbitration" system probably requires some
better explanation, but it still stands. From another project, the problem with
arbitration is, it follows the international arbitration act 1974, that have
been accepted by most countries, but not all (and that is a problem)
The principle definition of arbitration is, that it seperates criminal acts
from other acts. Criminal acts aren't covered by arbitration.
some more words about arbitration system you can read here =:)
http://en.wikipedia.org/wiki/International_arbitration and
http://wiki.cacert.org/Arbitration/FAQ and
http://www.austlii.edu.au/au/legis/cth/consol_act/iaa1974276/
ok, I've left the path =:)
the definition of responsibilities and defining the group of "fidonet"
membership was a mixture back in 1989 as P407 was written ...
Having in mind, that the BBS sysops running a frontend software "FIDO"
to exchange the mails from BBS'ses, that users had written ...
Today the focus moved from BBS systems to individual node systems, that may
have, or may not have a BBS system or aediquate software running behind the
frontend.
If we talk today about a fidonet system, we think about our running
(frontend) mailer, capable supporting FTN protocols.
This is also what has been distinguished by P407, but that it doesn't clearly
states (compare the P407 intro ... that describes a group of BBS systems ...)
One problem that may araise, while reducing the definition to
frontend systems, that connects with FTS compatible protocols together
is, that points aren't covered by current P407 .. with a definition
of FTN compatible frontends, they'll probably are ...
To keep current definition, write down the definition "FTN compatible frontends
down to Node level" :)
the "points out of scope status" simplifies the online times status definitions
ok, much stuff to consider :)
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...
US>> sure ..
ml> right... it does not mandate or require... this is in much the same
ml> way that "make available" does not mean "to deliver" (directly or
ml> routed) eg:netmail ;)
(my first conclusion started here ....)
US>> P407 is full of "BBS" references ... starting with "defining a
US>> group of BBS systems forming a net" (in my words)
US>> but isn't the topic I want to focus on ... more on later ...
ml> see my previous about the "armchair lawyers" who wrote policy...
ml> [trim]
ml>> then again, many don't take current policy in its entirity,
ml>> either... just like EP1, they pick and choose the parts that fit
ml>> them at the moment...
US>> so we may come to the conclusion, that P407 is outdated ... not
US>> entirely but in specific sections, can we?
ml> no, that's not what i said... if it were, then why haven't "you guys"
ml> rewritten that piece of trash echo policy thing? it is much worse and
ml> handled even moreso...
ep1 isn't on my radar and isn't on the radar of P407 either ...
Despite the fact I've worked on the project "R24 Echo Reorg 2012" last year,
my focus never was echomail policies ... but my focus is still
on the major policy :)
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>> true...
US>>> We have to switch between POTS, ISDN, IP, maybe more comes in
US>>> the future?!?
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
ml>> only by their radio capabilities... they were forced to have POTS
ml>> and/or internet connectivity... this is one reason why africa
ml>> ended up falling apart in the nodelist... there were other
ml>> problems as well but fidonet used to travel via packet radio
ml>> until some pright bulb figured out how to use TCP/IP over packet
ml>> radio and lessen the transfer rates (at 9600) even more... but at
ml>> least they did have "live" bidirectional comms...
US>>> We have to deal with probably no POTS BBS system remaining,
ml> why? it is possible that when the world goes to hell in a handcart,
ml> POTS will come back specifically because it works and allows
ml> communications... i suspect that radio will actually be first,
ml> though...
ml> are there really any ISDN systems left?
ml> but even so, all that is needed is bridge systems...
ok, elevator, bridge ... is only a naming ...
my "elevator" definition comes from past Novell times, as data transfer
has been optimized with an elevator system, where the rings will be filled step
by step in one direction, before the heads arm turns in direction
I've moved this picture into the multiple layers picture
-----------------:
-----------------:
-----------------:
-----------------:
where as many layers can exist and the elevator connects the floors
of undef count
A "bridge" connects two ends of "floors"
+--+
----------------- ----------------
without any direction, where to connect a 3rd "floor"
This is from the try to visualize potential concepts
With an elevator it says, that each "floor" can be connected
The elevator concept may integrate a prioritize system
eg by speed, by costs, by whatever definition
The sample also follows the Empire State Building concept ...
you enter the building from the street and wants to
reach the roof top you first have to use the elevator
to floor (was it 56? 57?) than to change the elevator
that goes to the roof ...
another word for "elevator" maybe "switches", as switches
covers the concept of "routing" within the system
"bridges" in networking concepts are dumb machines
without own inteligence, only to transport one packet
over the bridge into another segment
ml>> wrong... i'm still POTS capable as are many others...
ml>> specifically because of what happens when storms and other
ml>> natural events take out the connection capability...
US>> :D
US>> ok ok ok ... 1 POTS system remaining ... :D
US>> the real challenge is, to get the problems fixed, that focus
US>> fidonet onto one specific physical layer definition
ml> policy is not the place for that... the tech specs are the proper
ml> place... have you looked at FTS-0001? specifically the section (G or H
ml> IIRC) that asks for more input concerning other connection methods??
yes, the basic requirements (1.), levels of compliance (2.) and the
Session Layer Protocol (D.) are the essential topics one may use as a reference
that POTS is the only one counting physical layer, despite the fact
under paragraph D the exact definition is "It is currently
assumed to be over the DDD telephone network via modems."
By re-reading it again and again, I think given definition is a bit
weak and subject to many interpretations, that can be circumvented
using a modified phrasing:
Top 1., section 2:
current:
A FidoNet implementation must be able to call other nodes ...
proposed:
Any 2 Fidonet systems using one physical layer must be able to call other
nodes ...
so there is an implicite definition, that there is no one specific layer, but
its open to several layers ...
How does this sounds ?-)
following the questionable sections from fts-0001:
> commented
fts-0001.015 (1990-08-30)
..............................................................
1. Basic Requirements for a FidoNet Implementation
Compatibility is a set of abilities which, when taken as a whole, make
it safe to list a net or node in the FidoNet nodelist. In other words,
if another node should attempt contact, does it have a reasonable
chance of successful communication? This is a social obligation, as
the calling system pays money for the attempt. Conversely, an
implementation should be able to successfully contact other systems,
as life is not a one-way street.
A FidoNet implementation must be able to call other nodes and transfer
messages and files in both directions. This includes pickup and poll.
A FidoNet implementation must be able to accept calls from other nodes
and transfer messages and files in both directions. This includes
pickup.
> Section doesn't reflect that other physical layers are possible
> and "must" emphasizes this :-P
(...)
A FidoNet implementation must route messages which do not have files
attached through net hosts as shown in a FidoNet format nodelist.
> I "must" route through net hosts?!? ?-))))))
2. Levels of Compliance
This documents represents the most basic FidoNet implementation. A
future document will define well tested extensions which are optional
but provide sufficient additional function that implementors should
seriously consider them. ....
> The BinkP protocol has been set as a defined standard and has shown
> proof of concept for FidoNet over IP connections. So why should the new
> protocol only be "optional" ?!? and isn't specific to a physical
> layer?!? its more a relation of physical layer used and available
> protocols ... so level of compliance varies
D. Session Layer Protocol : Connecting to Another FidoNet Machine
A session is a connection between two FidoNet machines. It is currently
assumed to be over the DDD telephone network via modems. ...
> simple fix by Top 1, section 2 :)
..............................................................
Now the next problem:
fts-0001.015 is copyrighted material (!)
"Copyright 1986-90, Randy Bush. All rights reserved. A right to
distribute only without modification and only at no charge is granted."
This is a BIG FAT problem, as this document probably no longer can be updated
:-(
maybe relates to other fts-documents too ?!? (I don't have an overview here)
History did change, several other projects in the world shows how document
licensing may work for an open community
So that no one has an exclusive copyright permission over a certain
essential document. This can be covered by a paragraph in an updated document,
that defines the license model under which documents can be freely distributed
and updated.
GPL, CC are open license models that reflects the requirements of an open
community.
For fts-0001 probably a rewrite is required :-P
and the rewrite to be referenced in an updated Policy
This means, some work to do, but it isn't impossible ...
US>> Fidonet's practice has shown, that it can survive if we exclude
US>> specific P407 definitions, or make an update on these specific
US>> definitions, that allows variations of connection layers ...
US>> The challenge is, how to define it in a policy ?
ml> no... the challenge is to get policy updated in the first place... the
ml> last attempt(s) failed...
Before starting work in detail probably a survey may help, to collect
the ideas, to get the response from different zones. With such a feedback, you
get a roadmap in which direction we can go and if there is a chance to get a
new proposal pushed thru
Some ideas I've still posted. If the word gets spread out, probably some more
experts in writing policies may gets involved, helping in getting the work done
:)
US>> fts documents only documents practice, but the Policy is a
US>> document, how we want to interact ...
ml> the FTSC documents more than practise, really... but some have
ml> perverted the actions and definitions over the years :?
you'll probably can provide me with some samples by NM ?-)
US>> To ban POTS is the wrong signal ... somewhere later there is a
US>> definition, that encourage developers also to implement other
US>> protocols, but this isn't the topic we have to focus on
ml> agreed on POTS but i'm not sure what you are trying to say after
ml> that...
US>> Probably we have to go back to Tom Jennings philosophy
US>> (that he gave in an interview) forming a network of
US>> independent nodes to have a free independant network
US>> collected, defined by the nodelist
US>> having in mind, that in todays world we have as many
US>> independant physical transport layers to connect
US>> nodes together, but not all can support all the layers.
ml> agreed and therein comes more of the pervisions mentioned above...
that probably lasts out of controversy fts-0001 interpretations ?!?
simple fix shown above :)
but this simple fix also requires a fix in Policy first ...
so here we have a hen / egg problem ... we can break
it isn't impossible, if a majority follows the update proposals
US>> To focus on one layer that is used by the majority doesn't makes
US>> sense either ... as you've shown with the packet radio sample ...
US>> there are probably much more connectivity layers we don't have
US>> heard before that developers will try to use to connect a
US>> fidonet system.
ml> africa's system worked well and transferred major quantities of actual
ml> discussion... when they switched to TCPIP over those same 9600 radio
ml> links, there was a huge loss in discussion traffic transferred during
ml> any period of time because the networking protocols took up so much
ml> more room...
One guy I've first met in 2009 currently still stays in Africa
Well, I understand the problems here. Connection is possible, but difficult.
Probably requires special solutions, that are outside current technical
specifications
I think, there exist enough technical knowledge around to get the difficulties
sorted out and proposed in a solution. With some widened open definitions, that
prevents exclusivity, to one solution, we probably have a chance to get
such problems fixed :)
US>> So here we should rethink, how we can bring in P407 in shape with
US>> current situation with POTS, IP, Packet radio? and probably other
US>> layers and a solution, that allows nodes to communicate with
US>> others using a different connection layer that one cannot support
ml> policy points to the tech spec which is where they should be laid
ml> out...
yes and no ... no and yes ...
one problem I've discovered in some other discussions is the
undefined license model for essential documents, that requires to be fixed.
Once fixed, updates on tech specs becomes much easier :)
The second point is, to break the barriers that only one solution
"must" exist .. but it can be far more possible to have "several" solutions
:D
with reference to TJ philosophy the simple question is:
what do we want?
Move forward in TJ's philosophy to be open to any directions? so that everyone
may reach another one without any restrictions? or do we want to move forward
with the same philosophy that everyone may reach another one with some
restrictions?
some restrictions to read here as:
that node A is only connected to physical layer 1 and node B is only connected
to physical layer 2 and exchange of information goes via one
elevator/bridge/switch system
see fts-0001 E.2. Transport Layer Protocol: Routing
o If there are files attached, then a message must be sent directly to
its destination.
With a policy definition like:
risks:
two nodes at different physical layers may loose some features (eg. file
attachments) that are available to systems that are using the same physical
layer
Such a definition will reduce the requirement that netmails with file
attachments are a default definition, but file attachments
is an optional feature, that may be not available while using different
physical layers between two systems
file attachments ... one area where file attachments maybe required is the
distribution of nodelist and fidonews ... but here distribution path is related
to a network where the node has connected to. So probably there still exist a
direct uplink at the same physical layer so that routing is NOD here.
US>> Probably it doesn't have been picked up, as nobody still has an
US>> answer?!?
ml> there may never be until after all the "little kings" are gone...
give kids a challenge and they'll be busy for a while :D
US>> maybe "dynamic inteligent routing" is an answer?
US>> maybe "using nearest elevator systems" (similar to Zone gateways
US>> solution) is an answer?
ml> bridge systems?
read my thoughts above
US>> There is one definition in Policy to use "local" areas.
US>> The reason for this clause is, that nodes do not have to pay
US>> unforseen expenses while calling other nodes.
ml> yes... it was also perverted into being a political tool or weapon...
ml> it is still used as such today... witness the recent timmermans
ml> related fiasco from which more information is coming concerning it...
yes, this is one of the triggers of rethinking (again) what I've still have
running as a background task for a longer time
Everytime discussions started about non-Pots only nodes, Pvt nodes,
nodes not sitting in the physical area of a defined net ("apparently" not
localy listed) and I've asked my contact partners, if it makes any difference
in the case a Policy update will take place, I've received a positive response
It seems, there is a majority asking for an update, but nobody will do the
real hard work ... :-P
One of the requirements to start with the project "Policy Update 2013"
is to get some more feedback from the nodes.
A 2nd requirement is to find some more interested people who have some spare
time to work on this project in a team
Third requirement: to find some experts with experiences writing policies
Forth requirement: to find some open minded people willing in practicle
workaround findings (visionarys, developers) and someone with experience in
project management
probably a team of 4-10 people so the work can be shared
ml> )\/(ark
ml> $ Origin: (1:3634/12)
regards, uli ;-)
---
* Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)
|