Articles

• FidoNet on the Internet project starting
• FidoNet dies a slow death!
• Nodelist flags
• Responses to articles in 14-47
• New Echos

FOTI (Fidonet On The Internet)

From: davec@trak-one.co.uk (Dave Carter)
Date: 26 Nov 97 02:48:07 +0000
Subject: FOTI (Fidonet On The Internet)
Organization: The TRAK-ONE! BBS
To: cbaker84@digital.net

Hi Chris,

For the first time in my life, I'd like to submit something to Fidonews please! :-)

--/// Snip ///--

Hi Folks!,

FOTI (Fidonet On The Internet) is a new project being coordinated by a number of people in the UK with an interest in the future of Fidonet, and we're looking for help from any Fidonet echo moderators and Fidonet shareware authors around the world.

FOTI includes sections about Fido-related shareware/freeware programs, and echomail conferences available around the world - there is even an opportunity for each program or echo to have it's own mini web-site, if it doesn't already have one elsewhere :-)

Initially, it would be great if any author or moderator with WWW access could pop onto the site at http://www.trak-one.co.uk/foti [faulty URL [jb 4/25/01]], and take a look at the format of the information we're already carrying. Then, put together some information that you'd like shown (if it's already in HTML, then great), and send it to us so that we can include it.

Once you have something to send, please use one of the following methods to submit your info:

* Upload it to ftp://ftp.trak-one.co.uk/incoming [faulty URL [jb 4/25/01]] (active from Friday 28th November), and send an e-mail to input@foti.trak-one.co.uk telling us it's there (Please give the filename and program/echo-tag it refers to).

* File attach it to an e-mail to input@foti.trak-one.co.uk or netmail to me at 2:25/999 or 2:254/60.

This part of the FOTI project relies on YOU make it a success!

The site will be updated each Saturday with submissions received during the previous week .... Please help - Don't miss out! :-)

Join us every Saturday at 11 am on the site for live chat about the future of Fidonet!

Cheers,
Dave -[ davec@trak-one.co.uk ]-
FOTI (Fidonet On The Internet) * http://www.trak-one.co.uk/foti [faulty URL [jb 4/25/01]]

--/// Snip ///--

Thanks,

Dave

--
| Dave Carter -[ davec@trak-one.co.uk ]- Fidonet: 2:254/60
| Sysop of the TRAK-ONE! BBS and Fidonet <> Internet Gateway
| Data: +44 (0)181-407-0013 Web: http://www.trak-one.co.uk [faulty URL [jb 4/25/01]]

FidoNet dies a slow death!
by: Bobby Queen 1:3667/5
changes to 1:18/178 on 11/28/97

Well to show how bad FidoNet is hurting our local Net 3667 is being dissolved this week due to the NC/NEC and 3 more BBS's quitting all at once.

This means my node number is being changed to a regional independent due to the fact that the next closest net is still LD to me.

I am going to do my best in the limited time my RC Ken Tuley is giving me to try to get enough BBS's here in town hooked up so we can resurrect Net 3667 again out of the ashes.

I think the reason Net 3667 never took off was the NC/NEC was charging an outrageous amount of CRP. That is one of the main problems that is still hiding in FidoNet today.

As the Internet becomes more popular it is hurting us BBS's but it is also making it easier for us to get our FidoNet mail and files via FTP and other Internet means. So lets each one contact a few local boards this next week that are not in FidoNet and see if we can not reverse this backwards slide that FidoNet is in.

Bobby Queen

Zone 2 nodelist flags
Frank Ellermann, 2:240/5815.1

Nodelist flags

Publication: FSP-Z2 (number to be assigned)
Revision: 6
Title: Zone 2 nodelist flags
Author: Frank Ellermann, 2:240/5815.1
Revision Date: 27 November 1997
Expiry Date:

Contents:

1. Introduction
2. FTS-0005 flags
3. User flags
4. Approved zone 2 user flags
5. Flag implications
6. Invalid combinations
7. Baud rate field
8. Thanks to...

1. Introduction

This document informs about known differences of FidoNet zone 2 nodelist flags from FTS-0005.003. The ultimate sources for these informations are the current Z2 nodelist epilogue and the setup for flag corrections at Z2C, but it may be difficult to get these sources for readers in other zones.

All changes since version 5 are marked by a bar at the left edge.

All changes in this HTML version are marked in red. There are no fixed 'left edges' in HTML [jb]

It is (again) possible to list V32b and V42b in zone 2, upper case V32B or V42B is not more enforced. Currently new flags needed for IP-connectivity are under test in zone 2 (only internally), e.g.

-> VM

VModem, default port 3141, dummy country code 000-

-> IFC

IFCico, default port 60179, dummy country code 000-

-> BND

BinkP, default port 24544, dummy country code 000-

-> IP

general IP connectivity, dummy country code 000-

-> TELN

Telnet dummy country code 000-

2. FTS-0005 flags

CM

Continuous Mail, node accepts mail 24 hours a day

MO

Mailer Only (no BBS)

LO

Listed Only, node accepts calls only from listed node numbers in the current FidoNet nodelist

-> V21

ITU-T V21 300 bps full duplex (obsolete)

V22

ITU-T V22 1200 bps full duplex (obsolescent)

In zone 2 the value 1200 in the baud rate field implies V22. Only two nodes not supporting at least V22bis, ISDN, or IP still exist in the zone 2 segment. Flag V22 is almost obsolete, and V21 is already removed in Z2. Both flags should be dropped from the next FTS-0005 version.

V29

ITU-T V29 9600 bps half duplex (obsolescent)

-> V33

ITU-T V33 14400 bps half duplex (obsolete)

V33 cannot be used in connecting FidoNet nodes over public dial-up lines and is most probably a historical error in FTS-0005. A very similar argument is applicable on V29, all nodes flying this flag support at least V32. Today only one node in Z2 still flies V29, and V33 is already removed in Z2. Both flags should be dropped in the next FTS-0005 version.

V32

ITU-T V32 9600 bps full duplex

V32b

ITU-T V32bis 14400 bps full duplex (implies V32)

V34

ITU-T V34 28800 bps full duplex (33600 bps option)

FTS-0005 specifies V32b and V42b (capital V and small b), current nodelist practice in FidoNet shows all combinations of small and capital letters for flags. This was no problem before FSC-0062 introduced case-sensitive flags. The best solution is to stick to the current practice and treat all old flags as case-insensitive.

H96

Hayes V9600

HST

USR Courier HST up to 9600 (implies MNP)

H14

USR Courier HST up to 14400 (implies HST)

-> H16

USR Courier HST up to 16800 (implies H14 and V42b)

MAX

Microcom AX/96xx series (almost obsolete)

PEP

Packet Ensemble Protocol

CSP

Compucom Speedmodem

-> ZYX

Zyxel series 16800 bps (implies V32b and V42b)

-> V32T

V.32 Terbo 19200 bps (implies V32b)

VFC

V.Fast Class 28800 bps (should imply V32b and V42b)

If a flag directly or indirectly implies other flags, then these other flags are not shown in a nodelist entry, because this would be redundant. Unfortunately the rules for redundancies in zone 2 and FTS-0005 are different. Zone 2 continued to avoid redundancy with most "new" flags, but FTS-0005.003 specified no redundancies for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this context are flags approved by FidoNet International Coordinators since 1989, when FTS-0005.TXT, the predecesssor of FTS-0005.003, was published.

For details see the chapter "implications" below, for now only note, that in zone 2 H16 implies V42b, ZYX implies V32b and V42b, and V32T implies V32b.

Zone 1 and zone 2 have introduced a user flag Z19 approved by the corresponding Zone Coordinator. User flags are discussed later, for now only note, that in zone 2 ZYX is specified as Zyxel 16k8, while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag for all Zyxel protocol speeds.

Today only one node in FidoNet still really flies MAX, this flag is obsolete and should be dropped from FTS-0005. The flags CSP (7 nodes worldwide) and H96 should be marked as obsolescent.

MNP

Microcom Networking Protocol 2-4 error correction

V42

ITU-T LAP-M error correction w/ fallback to MNP 2-4

V42b

ITU-T V.42bis BTLZ data compression over V.42 LAP-M

The next version of FTS-0005 should adopt the better V42b and MNP definitions of the zone 3 nodelist epilogue. FTS-0005.003 specifies an implication of V42 by V42b, but the exact meaning of the flag MNP is unclear. Most probably this flag was meant to indicate support of MNP 2-4, and in this sense V42 implies MNP. Note the difference between the flag V42b (implying V42) and the standard V.42bis (not necessarily based on LAP-M as data link layer protocol), without this difference the flag V42b would be ambiguous for combined modem and ISDN node entries.

MN

No compression supported in insecure inbound

XA

Bark and WaZOO file/update requests

XB

Bark file/update requests, WaZOO file requests

XC

Bark file requests, WaZOO file/update requests

XP

Bark file/update requests

XR

Bark and WaZOO file requests

XW

WaZOO file requests

XX

WaZOO file/update requests

These flags are equivalent in FTS-0005 and in the zone 2 segment.

Gx.

x Gateway to domain 'x..x'

Valid values for this flag are assigned by the Fido International Coordinator, FTS-0005.003 explicitly mentions GUUCP. In zone 2 only GUUCP gateways are flagged.

#01

Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A

#02

Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A

-> 08

Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A

#09

Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A

#18

Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A

#20

Zone 6 mail hour (20:00 - 21:00 UTC) w/ Bell 212A

The variants !01, !02, !08, !09, !18, and !20 indicate missing Bell 212A support. In zone 2 #02 or !02 would be obviously redundant.

Today less than four 1200 modems (V22 or Bell 212A) are listed. A future version of FTS-0005 should drop !mn variants together with V21 and V22 flags.

Further most non-CM systems flagging #mn or !mn today probably want to show additional online times instead of additional mail hours. As soon as FSC-0062 flags have been approved by the IC or adopted as FTS by the FTSC, the following version of FTS-0005 should mark #mn as obsolescent and recommend the more flexible FSC-0062 flags (see below).

3. User flags

An example for one of several problems in zone 2 with user flags:

...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC

These flags indicate a modern Zyxel ISDN-modem and two additional user flags ENC and NEC. This possible user flags string contains 34 characters, but at most 32 characters are allowed in FTS-0005.

...,U,Z19,V110L,V110H,X75,ISDNA,ISDNB,ISDNC

During the period for the replacement of old by new ISDN flags (several months !) many nodes listed both old and new flags for maximal compatibility, and no problems with nodelist compilers or mailers caused by too long user flags strings were reported.

Therefore the length limit in FTS-0005 is probably unnecessary and at least inconsequent: Other nodelist fields like the system name are unlimited, so why only restrict the user flags string ? To help developpers an upper limit of e.g. 255 characters for a nodelist line and 63 characters for fields 3 to 6 would be more useful.

The next problem with user flag strings as specified in FTS-0005 is their introduction by the letter U with no comma following:

Nodelist compilers could parse ...,UISDN,USR in user flags ISDN and USR. But USR cannot be approved as "real" flag, because the combination ...,USR,UISDN would then be parsed in SR and UISDN.

Other side effects of the FTS-0005 specification are additional difficulties in finding flags. Almost all flags are separated by a comma, only the first user flag can be an exception to this simple rule. If the order of user flags has no meaning, then...

...,UV120L,V120H
...,UV120H,V120L

... are equivalent. A "simple" solution of this problem could be to treat UV120L as synonym for V120L, and UV120H as synonym for V120H. Similar problems show up, if user flags are counted, etc.

Obviously a nodelist compiler looking for user flags has always to consider the case "user flag separated by comma". In zone 2 this idea was simply extended to the first user flag:

All flags are separated by commas. Flags not yet approved by the International Coordinator or the FTSC (i.e. user flags only used experimentally or locally) are separated by a new pseudo flag U.

-> U

pseudo flag to the left of at least one user flag

All flags following this pseudo flag U are user flags, all flags before this pseudo flag are "real" flags specified in FTS-0005 or approved by the International Coordinator.

Because this definition should be compatible with any reasonable software implementation based on FTS-0005.003, and simplifies the handling of user flags significantly, a future FTS-0005 version will hopefully adopt it.

4. Approved zone 2 user flags

In zone 2 user flags have to be approved by the Zone Coordinator. Currently the following zone 2 user flags exist:

-> V110L

ITU-T V.110 19k2 async 'Low' (former ISDNA)

-> V110H

ITU-T V.110 38k4 async 'High' (former ISDNB)

-> V120L

ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8

-> V120H

ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8

-> X75

ITU-T X.75 SLP (single link procedure),
64kbit/s B channel; layer 2 max. framesize N1 = 2048,
window size W = 2, frame numbering modulo 8;
layer 3 transparent (no packet layer)

-> ISDN

Other configuration, used only if none of above fits

These ISDN flags follow the specification in FSC-0091.

-> Tyz

Online time flags as specified in FSC-0062

The flag Tyz is used by non-CM nodes online not only during ZMH, y is a letter indicating the start and z a letter indicating the end of the online period as defined below (times in UTC):

A  0:00, a  0:30, B  1:00, b  1:30, C  2:00, c  2:30,
D  3:00, d  3:30, E  4:00, e  4:30, F  5:00, f  5:30,
G  6:00, g  6:30, H  7:00, h  7:30, I  8:00, i  8:30,
J  9:00, j  9:30, K 10:00, k 10:30, L 11:00, l 11:30,
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,
S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,
V 21:00, v 21:30, W 20:00, w 20:30, X 23:00, x 23:30.

For example TuB shows an online period from 20:30 until 1:00 UTC.

-> Z19

Zyxel series 19200 bps (implies ZYX)

-> X2C

x2 client w/ 56000 bps (should imply V34 and V42b)

-> X2S

x2 server w/ 64000 bps (should imply V34 and V42b)

-> K12

Systems offering all educational K12-conferences

-> ENC

The node accepts inbound encrypted mail

-> NC

Network Coordinator (only if the NC is not the host)

-> NEC

Net Echomail Coordinator (at most one per net)

-> REC

Region Echomail Coordinator (at most one per region)

Redundant AKAs used to indicate echomail coordination in zone 2 are no longer permitted. One *EC flag is valid for all AKAs of a given sysop.

5. Flag implications

Flag implications directly or indirectly specified in FTS-0005:

HST

=gt; MNP

H14

=gt; MNP HST

H16

=gt; MNP HST H14

V42b

=gt; V42 (MNP ?)

V32b

=gt; V32

Flag implications specified in the zone 2 nodelist epilogue:

HST

=gt; MNP

H14

=gt; HST MNP

-> H16

=> V42 MNP V42b H14 HST

-> V42b

=> V42 MNP

-> ZYX

=> V42 MNP V42b V32 V32b

-> Z19

=> V42 MNP V42b V32 V32b ZYX

V32b

=gt; V32

-> V32T

=> V32 V32b

-> V110L

=> ISDN

-> V110H

=> ISDN

-> V120L

=> ISDN

-> V120H

=> ISDN

-> X75

=> ISDN

The latter ISDN flag redundancies are a consequence of FSC-0091. Maybe some of the following implications could be added in zone 2:

VFC

=gt; V32 V32b MNP V42 V42b

X2C

=gt; V34 MNP V42 V42b

X2S

=gt; V34 MNP V42 V42b

Flag implications (i.e. not listing redundant flags) have several advantages: Some old nodelist tools are unable to handle too long lines. Old flags like HST, MNP, V42, or V32 vanish automatically, if they are implied by H16, V42b, V32b, or better. Redundancies defined globally for the whole nodelist help to avoid flag errors.

6. Invalid combinations

All file request flags exclude each other (at most 1 is possible): XA, XB, XC, XP, XR, XW, and XX. For flag checkers only supporting implications a good approximation based on FTS-0005 definitions is

XA

=gt; XW XR XP XB XC XX,

XB

=gt; XW XR XP,

XC

=gt; XW XR XX,

XR

=gt; XW,

XX

=gt; XW.

Further X2C cannot be combined with X2S, and FSC-62 Tyz-flags are not possible with CM. Also Tyz with y = z is of course incorrect.

Some modem protocols are "proprietary" in a sense, that all today known modems can fly at most one of the corresponding modem flags: MAX, CSP, H96, PEP, HST, H14, H16, ZYX, and Z19.

A few "old" modem protocol flags are known to be invalid if used together with "new" protocol flags, i.e. each "old" flag excludes all "new" flags and vice versa:

"Old"

in this sense are MAX, CSP, H96, HST, H14, V32, and PEP.

"New"

in this sense are X2S, X2C, V34, VFC, V32T, and H16.

For Z2 add ZYX as "old" and Z19 as "new". A simple REXX script to test some known inconsistencies is available as NLSCHECK.REX at the site of the author. While erroneously listing redundant flags causes no harm, other errors like combining V34 with HST or Z19 with H16 indicate serious problems, which can result in connection failures or other damage.

7. Baud rate field

The baud rate field 7 in the nodelist as specified in FTS-0005 is nearly useless today: Except from a few remaining 1200 and 2400 nodes almost all nodelist entries show either 9600 for all modem protocols better than V22bis or 300 for ISDN (or IP) only nodes. No more V21 or Bell 103 modems are listed for more than 2 years.

The baud rate values 19200 and 38400 specified in FTS-0005.003 have not been used in the FidoNet nodelist. So all a reasonable nodelist compiler can do today, is treat 300 as indicator for ISDN or IP only, and treat unknown or missing values in field 7 like 9600.

A new meaning for field 7 as speed field could be really useful. An example is ZYX, if we would have 16800, 19200, 28800, and 33600 as speed values, then their combination with ZYX is all we need technically, Z19 would be unnecessary. Another example is HST, flags H14 and H16 are unnecessary, if HST is combined with 9600, 14400, 16800, 28800, or better. Variants of PEP could be shown in the speed field without new flags. "Enhanced V32.terbo" could be shown by 21600.

Most important: V34 may have the famous bug not allowing connects from new "V34+", unless the caller disabled symbol rate 3429. If "V34+" is indicated by speed 33600 or better, then an appropriate setup for all kinds of V34 connects is possible.

A future version of FTS-0005 hopefully allows the following speed values in field 7:

300

reserved for ISDN or IP only (for historical reasons)

1200

obsolete (either V.22 in Z2 / Z3, or Bell 212A in Z1)

2400

implies V22bis, qualifies as least common denominator

9600

default, used with PEP, V32, HST, H96, (CSP), (MAX)

12000

rare variant of V32

14400

used with V32b or HST (obsoleting H14)

16800

used with ZYX or HST (obsoleting H16)

19200

used with V32T or ZYX (obsoleting Z19)

21600

rare variant of V32T (no "H21" needed)

28800

used with VFC or V34

33600

used with V34 (no V34+ or V34b needed)

56000

used with X2C, X2S, or V.PCM

Allowing more than 12 speed values or allowing speed values above 64000 could break existing software (MakeNL, V7). Therefore the next step in FidoNet could be, to add 12000, 14400, 16800, 19200, 21600, 28800, 33600, and 56000, where 19200 is already specified in FTS-5 since 1989.

8. Thanks to...

Ben Baker

St. Louis nodelist format

Rick Moore

FTS-0005.TXT

David Nugent

FTS-0005.003 and NLTOOLS

Jonny Bergdahl

ERRFLAGS 2.6

Ward Dossche

Zone 2 nodelist epilogue

David J

ZThomasZ FSC-0062.003 (FRL-0062)

Jan Ceuleers

FSC-0075.001 (FRL-0075)

Arjen Lentz

FSC-0091.001 (FRL-0091)

Leonard Erickson

CHECKNL 2.14 and many discussions in NET_DEV

Jim Barchuk

LNDL 2.7

Marius Ellen

FASTV7 2.04

Jan Vermeulen, Ian Smith, Gisbert Rudolph, Carlos Fernandez Sanz, Tom Schlangen, Craig Ford, Pedro Lima, and many others...

- eof -

Responses to articles in 14-47
by Lee Kindness, wangi@earthling.net

A number of responses from articles in FIDONEWS 14-47

Things really do from bad to worse...

> From: Rich Veraa
> Subj: Unsolved Mysteries, "How far from Ontario to Malaysia?"
> Host,163,Ottawa_163,Ottawa_ON,Christine_Labonte,
> 1-613-742-7612,9600,XA,CM,V42b,V32b
> ,134,Valley_of_Wind,Kuala_Lumpur_MALAYSIA,Maulvi_Bakar,
> 60-3-712-5570,9600,V34, V32b,V42b,ZYX,MNP,CM,XA
> Does anyone know howcome a net in Ontario lists a node in Malasia?

And can I ask you why it matters? This sort of geographical nonsense is damaging to Fidonet - it merely gives some "power hungry fiends" something to worry about. Do a bit of research and find out about Fidonet in Asia and you might see why a node would want to be in zones 1 or 2...

> From: "Piotr Kosibowicz" <kosi333@polbox.com>
> Subject: How to defend against defaming in a public
> conference?, "Echomail defamation?"
> I am writing for the advice how to force a fidouser to send
> an apology note to a Polish conference BUY_SELL.POL.

Dry your eyes man. Fidonet is not about forcing anyone to do anything.

> From: Steve Woodmore <steve@proteus.demon.co.uk>
> Subject: Re: have your retired again?, "Ex-ZEC2 confirms
> leaving FidoNet"
> The same old thing, every time you try and achieve
> something, there are always people being destructive
> and disruptive. [...]

Life then?

> Come and visit the worlds fastest talker If you thought
> you could talk fast, then you are wrong As featured in
> the 1990,1991,1992,1993,1994,1995,1996,1997 Guinness Book of

<Yawn>, yes Steve - but you never could COMMUNICATE!

But it's nice to see some people still doing the 'decent' thing. Hail Damian Walker and congratulations to Odinn Sorensen, lets hope you're a touch more active than Mr. Nugent was in his later years as FTSCC.

New Echos you may not be aware of!
by: Bobby Queen 1:3667/5 changing to 1:18/178 on 11/28/97

I just wanted to make everyone aware of some new echos that i have been able to get backboned recently. Some are a month old or older but not many participants yet.

LORD2_CHAT

These 3 are devoted to Lord II the new Online game from

LORD2_SYSOP

Seth Able Robinson the author of the original L.O.R.D.

LORD2_IGM

and Planets TEOS!

IRC_CHAT

These are real new and are devoted to Internet Relay

IRC_SCRIPTS

Chat discussions known as IRC.

ART_BELL

Devoted to discussing the Art Bell show.

Then here are some older ones that I recently updated or are still needing participants.

ET_SIGHTINGS

Devoted to sightings of Extra Terrestrials.

I_UFO

May soon be merged with ET_SIGHTINGS. Watch for a notice on this in the future.

WILDCAT4

For discussions pertaining to the dos version of Wildcat.

WC4DOS

For discussions pertaining to the dos version of Wildcat.

And then 2 that are going strong but I still welcome more of you to AREAFIX.

NASCAR

For discussions of NASCAR stock car racing in all forms.

CLASSIFIEDS

For individuals to buy, sell and trade their personal items.

So AREAFIX your choices today and join in on the fun in all these exciting echos.

Bobby Queen