Articles
back to main table of contents back to fidonews.orgZone 2 nodelist flags
Frank Ellermann, 2:240/5815.1
This article informs about known differences of FidoNet zone 2 nodelist flags from FTS-0005.003. The ultimate sources for these informations are the current zone 2 nodelist epilog and the setup for flag corrections at Z2C, but it may be difficult to get these sources for readers in other zones.
FTS-0005 flags
The following flags are used as specified in FTS-0005.003:
CM Node accepts mail 24 hours a day
MO Node does not accept human callers
LO Node accepts calls only from valid listed node
numbers in the current FidoNet nodelist
V21 ITU-T V21 300 bps full duplex
V22 ITU-T V22 1200 bps full duplex
In zone 2 a value of 1200 in the former "baud rate" field implies V22. Today only two nodes not supporting at least V22bis or ISDN still exist in the zone 2 segment, therefore the flags V21 and V22 are obsolescent. Both flags should be dropped from FTS-0005.
V29 ITU-T V29 9600 bps half duplex V33 ITU-T V33
V33 cannot be used in connecting Fido nodes over public dial-up lines and is most probably a historical error in FTS-0005. This flag should be removed from FTS-0005 a.s.a.p. A similar argument is applicable on V29, and few nodes flagging V29 today all support at least V32. The next version of FTS-0005 should drop V29.
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
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. In zone 2 all old flags except from FSC-0062 flags are upper case, and a NODEDIFF changing this convention would be annoying. 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 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
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 there is only one node in FidoNet still flagging MAX, this flag is obsolete and should be dropped from FTS-0005. The flags HST, H14, and CSP should be marked as obsolescent.
MNP Microcom Networking Protocol error correction
V42 ITU-T LAP-M error correction w/fallback to MNP 1-4
-> V42B ITU-T LAP-M error correction w/fallback to MNP 1-5
As mentioned above FTS-0005 specifies V42b (capital V, small b). In zone 2 all case-insensitive flags are listed in upper case.
The next version of FTS-0005 will probably adopt the better V42B and MNP definitions of the zone 3 nodelist epilog. 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 1-4, and in this sense V42B implies MNP.
In zone 2 MNP is considered as redundant, if V42B is flagged or implied by other flags like H16, ZYX, or Z19.
MN No compression supported 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 five 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).
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.
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) -> 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) -> ZEC Zone Echomail Coordinator (at most one per zone)
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.
Flag implications
Flag implications directly or indirectly specified in FTS-0005:
HST => MNP H14 => MNP HST H16 => MNP HST H14 V42b => V42 (MNP ?) V32b => V32
Flag implications specified in the zone 2 nodelist epilog:
HST => MNP H14 => HST MNP -> H16 => V42 MNP V42B H14 HST -> V42B => V42 MNP -> ZYX => V42 MNP V42B V32B -> Z19 => V42 MNP V42B V32B ZYX V32B => 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 one of the following implications could be added in zone 2:
VFC => V32 V32B VFC => V32 V32B 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.
"Baud rate" field
The former "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 only nodes. No more V21 or Bell 103 modems are listed today.
Obscure "baud rate" values 19200 and 38400 specified in FTS-0005 have not been used in the FidoNet nodelist. So all a reasonable nodelist compiler can do today, is treat 300 as indicator for ISDN 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 33600. 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, 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 only (for historical reasons) 1200 V22 or Bell 212A (obsolete) 2400 implies V22bis 9600 default, used with V32, HST, H96, PEP, CSP 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) 57600 used with "X2" clients
The following values should be specified in FTS-0005, because they are already used in nodelists of other FTNs:
empty no value, useful for Pvt nodes or in point lists 19200 used with V110L, V32T, or ZYX (obsoleting Z19) 38400 used with V110H 57600 used with V120L or "X2" 64000 used with V120H, X75, or other ISDN equipment
Allowing more than 12 speed values or allowing ISDN speeds could break old software. Therefore the transition could be done in two steps, first add all non-ISDN speeds (ISDN only shown as 300).
Later remove 300 (ISDN only) and 1200 (obsolete) replacing 300 by 19200, 38400, 57600, or 64000.
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 epilog Arjen Lentz FSC-0091.001 David J. Thomas FSC-0062.003 Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV Jim Barchuk LNDL 2.7 Marius Ellen FASTV7 2.03j (but I still prefer 1.45b ;-) Jan Vermeulen, Jan Ceuleers, Ian Smith, and many others...
back to articles table of contents back to main table of contents back to fidonews.orgA reply to "Fidonews,
The "lard ass"
of newsletters"
By Tony Dunlap, 1:2220/30
I was reading the paper the other day and noticed in the want ads a Maytag wringer washer for sale for $35.00. There was also an article with "Your Twelve Favorite Recipes Using Yogurt" (Not that I'd ever eat anything with a name that sounds like something that had already been eaten (then disposed of)). Then of course there were the funnies (most of which weren't), and the bridge column. I am not interested in any of these things, but I at least glance at them (mainly in hope of gaining a glimmer of understanding of the deranged minds of people who would be interested in such things <g>).
The point I am trying to make is that Fidonews is for all members of Fidonet, not just the majority, and if a article is found useful by just one member, it belongs there.
As for it's size, come on! All of last year's Fnews in their distrubuted format (LZH and ZIP) will fit on one high density floppy (Try to store a year's worth of newspapers in that space!)
By the way, just for fun I called about the wringer washer... It's gone.
---
back to articles table of contents back to main table of contents back to fidonews.orgOoh, ow! You wound me!
by Gary Gilmore, 1:2410/400
Well, it seems that it's ok to write something -for- Fidonews, just as long as you don't -talk- about Fidonews. <sigh> I thought the "editorial" about my article was a little out of line, but thought "what the hell, I'll respond". The Fidonews editor's comments are quoted...
cb> He doesn't say how long he's been around but only refers to
cb> the output of Tees, the previous Editor as example of FidoNews
cb> size past.
Gee, I didn't know that mattered. I guess it's part of a Fido "elite-ism" of "my board is older than yours, so you're not as good as me", which I've always found silly. Heck, I've seen BBS systems that have been up for a month that have floored me, and I've seen very old BBS systems that were total garbage, so what's the difference? For what it's worth, my BBS has been in constant operation since January 9th, 1988. I've been in Fidonet since 1990. (Somewhere around the summer of that year, if I recall right. My system was even a Computer Shopper Magazine "BBS Of The Month" for May of 1991.. not that it means a whole lot in the big picture.
Now, does any of that make my comments more or less valid? <shrug> I don't think so. We're Fidonet sysops, this is Fidonews, and that means this is the place where we can comment. ...and our comments shouldn't be cast aside with editorials trying to make them seem less valid than the next persons.
cb> Since Tees didn't bother to actively edit FidoNews many times,
cb> it's hardly surprising many of his Issues were miniscule or
cb> Editorial only phosphor padding.
Oh geez... now it's "slag the old editor" time. I find it humorous that the term "phosphor padding" is used here, when this past issue contains yet more FTSC bulletins to puff up the S'nooze. Ah well...
cb> FidoNews has been all sizes the past 13 years from 5K to 157K.
But I do think the content has varied wildly. Sometimes great stuff, sometimes nothing but dreck. I know the contributors have the burden of making Fidonews what it is, but I still don't think intentionally puffing it up makes it better.
cb> Nobody has to read it; part or all of it.
Very true, and perhaps the more dry it gets, the less it's read. I can't count the times I've said "Did you read <article name> in Fidonews?" to some fellow sysops, and they almost always say "Ah, I never read that thing". Too bad. I do. All the time.
cb> The History and Standards series is part of what FidoNet is and
Sure is! I don't think it needs to be completely reprinted though, since it's already available elsewhere. Those that really care to read it will go get it. Those that don't are (to quote myself) "furiously hitting the page down key" to avoid it, so what's the use? Got me.
cb> going to keep going this way. There are FIVE FSCs in this Issue.
cb> There are only sixty or so more to go. [grin]
Thanks for the warning! I guess it'll be safe to read Fidonews again sometime after the next 13 issues if one wants to avoid them. <laugh>
cb> The software list is also an important part of the FidoNews
cb> mission and we all are indebted to Peter Popovich for the
cb> Herculean labors he
Umm, I do believe that I gave credit -and- thanks to Peter. What I did say is that Peter should be given a little break, and only have to have a listing ready monthly. That's all is really needed, since software isn't going to change that fast, and if "Brand X" drops support this week, waiting for a notice 3 weeks from now won't kill anyone. (And it'll give Peter more time to get good follow up information on these packages.)
cb> the Echomail weenies flee FidoNet
Echomail weenies? Hmmm.. I don't know what's wrong with echomail, but you seem to not like those that use it, judging by how many times you use this phrase in your editorial.
cb> for the apparently greener pastures of Internet mailing lists,
Funny this is here, since you're promoting a mailing list version of Fidonews. Imagine! <laugh> Indeed, there's more -Internet- promoting of Fidonews (in the Fidonews) than there is of promoting how to get it via Fidonet.
cb> Those who can't, get jobs as critics. I'm doing and teaching.
Those that can't take criticism shouldn't be editors, I guess. Sorry to see you take it so personally, and feel the need to turn to thinly veiled insults in order to rebut what I've said, Chris.
Oh well. C'est la vie.
back to articles table of contents back to main table of contents back to fidonews.org