Hello Carol.

10 Nov 02 08:54, you wrote to me:

 MG>> The *C's have the power to make any nodelist changes they want to,
 MG>> and the FTSC is relegated to recording what has been accepted by
 MG>> them. If the FTSC ignores the wishes of the Coordinators, they
 MG>> become useless t this network.

 CS> Good points there.  That was one of the things I learned too (although
 CS> I already knew it).  The FTSC documents and clarifies existing
 CS> standards.  They also accept proposals for new ones but until in
 CS> actual use someplace, they stay as 'proposals' (FSP).

The proposals need to be clearly documented, and the experience of both
developers /and/ end users of the proposed new functions need to be taken
into consideration before anything should be declared a
"standard".

 CS> Actually getting a new flag authorized for example, is done by
 CS> asking
 CS> persmission of your own ZC.  If your ZC responds favorably, then you
 CS> can try it in your zone (or might be told a net or region to limit it
 CS> to).  RVIA for example started as a test limited to R13, then was
 CS> allowed wider spread.  Later the IC authorized it in the international
 CS> nodelist trailer.  For an example of a non-flag but similar, Z2
 CS> authorized testing of the 000- set for static IP's and later Z1 took
 CS> to it (after Z2 removed it I think).  Oh and lets not forget RPK and
 CS> NPK which Z2 needs.

I feel it should not be left to the ZC alone, or even to a small committee
to decide on what is and isn't a standard. Fidonet needs an open standards
process, similar to what goes on in the Internet with the RFC
documentation. All members of Fidonet should be allowed to contribute their
input.

 CS> There's a slightly bolder drive in the works just now, which is
 CS> to do further clarification on which of the many IP type entry
 CS> methods are 'most preferred' since obviously there are several
 CS> ways to do this.  I don't think anyone would mind if the IP
 CS> listing portion came with a bit more on what is the 'preffered'
 CS> method when there are several methods to chose from.

I have even bolder ideas. Watch for them in the Fidonews, if Bjorn decides
to publish what I've sent. If my ideas are not accepted in Fidonet, I fully
intend to implement them in SkyNet, and let the FTN users decide which way
is better.

 CS> While an FTS shouldnt reference an unofficial 'FAQ' there might
 CS> be a way to incorporate some of the base ideas from the one in
 CS> the subject line.  It's been posted enough for any to comment by
 CS> now if there are errors in it's methodology (or at least any
 CS> gross errors and yes, I fixed the 154/157 confusion).

The FSP's should be open to evolution, and the final declaration of a
"standard" should reference the complete set of FSP documents
written on that particular adoption along the way. That way, a programmer
not only sees the standard, but can understand the why and how of it, from
it's infancy to a highly developed format.

 MG>> FTSC may fancy itself some sort of "authority" based on some
 MG>> perceived techno-geeky intellectual hierarchy (read bovine
 MG>> scatology) expressed through the FTSC nomination and election
 MG>> process, but in reality they are far less important in the
 MG>> decision making process than the Coordin or even the end nodes, if
 MG>> enough of them protest loudly enough for a c

 CS> Grin, they just document.  Thats all.

Unfortunately, as we see here, some continue to be deluded on that point...

--- GoldED/386 3.0.1-dam3