Copyright 1990, Fido Software. All rights reserved. Duplication
and/or distribution permitted for noncommercial purposes only.
For use in other circumstances, please contact Fido Software.
FidoNews is published weekly by the System Operators of the
FidoNet (r) International BBS Network. It is a compilation of
individual articles contributed by their authors or authorized
agents of the authors. The contribution of articles to this
compilation does not diminish the rights of the authors.
You are encouraged to submit articles for publication in
FidoNews. Article submission standards are contained in the file
ARTSPEC.DOC, available from node 1:1/1. 1:1/1 is a Continuous
Mail system, available for network mail 24 hours a day.
Fido and FidoNet are registered trademarks of Tom Jennings of
Fido Software, Box 77731, San Francisco CA 94107, USA and are
used with permission.
Opinions expressed in FidoNews articles are those of the authors
and are not necessarily those of the Editor or of Fido Software.
Most articles are unsolicited. Our policy is to publish every
responsible submission received.
Table of Contents
1. EDITORIAL ................................................ 1
FidoNews Archiving -- the view from the City Desk ........ 1
2. ARTICLES ................................................. 4
Something We Can All Agree On ............................ 4
LHARC, The Snooze, IFNA, and Iraq ........................ 7
TechCon-I, the Report (part 1) ........................... 9
3. LATEST VERSIONS .......................................... 15
Latest Software Versions ................................. 15
4. NOTICES .................................................. 18
MetroFire [1:135/14] Moves Again! ........................ 18
The Interrupt Stack ...................................... 19
FidoNews 7-34 Page 1 20 Aug 1990
A funny thing happened this summer. FidoNews changed its default
archiver. It broke a few batch files. And FidoNet survived!
Thank God for those little miracles.
This has been a fascinating story. Certainly the best one I know
of that concerns FidoNews itself. But it's starting to get
boring now, and I'm going to have to bring it to a close.
I have heard the words "insolent" and "arrogant" used to describe
our actions. I'm not really sure where the insolence comes in.
I'll have to wait until somebody explains that to me. As for
arrogance -- if you're a software author in FidoNet and you're
not arrogant yet, just wait a week or so, it's a communicable
disease here. I've seen no cure as yet either, except perhaps
for complete removal of the cause. So I'm arrogant. So sorry.
That doesn't mean that I don't care about FidoNet at large. I
do. Enough to be keeping my eyes open for potential problems and
to take action when it appears warranted. I saw a potential
problem. It appeared to require action. I took action. Harry
took the heat. His call. I was willing to. I do now.
There have been several objections to the change. Most of them
were not objections to the dropping of ARC. Most actually
protested the use of LHArc rather than ZIP. We'll cover that
issue later in this editorial. The complaints which I want to
address first are from those who felt we had acted unreasonably
in making the change without advance notice.
Did your batch file break? I apologize. Should I have given you
some warning so you could fix it beforehand? Maybe. Would this
advance notice have been interpreted as license to start a
NET_DEV-style filibuster? I think so.
I'm a great fan of Grace Hopper, whose favorite admonition is
that it's often (I think she says "always" rather then "often",
actually) easier to apologize than to ask permission. With that
in mind, we decided to avoid the filibuster by presenting you
with a fait accompli.
However, before FidoNews went out in a .LZH file, I consulted the
International Coordinator, the Zone 1 Coordinator, and the holder
of the Trademark. Nobody cautioned me not to do it. Nobody told
me not to do it. I had either an implicit or explicit go-ahead
from each (though TJ made a point of not wanting to "meddle", one
way or the other). Nobody felt that the world would come to an
end if I made the change. Nobody felt that Dan Quayle would wind
up as the U.S. President as a consequence of the lack of advance
notice. End of story. We did it.
FidoNews 7-34 Page 2 20 Aug 1990
That's why there was no advance notice. I still feel that it was
the only way to make this change. To those of you who are still
offended that I didn't appear at your doorstep, prostrate myself,
and ask for your divine consent -- I'm sorry. But you're the
kind of person Grace had in mind, and I'll not be asking your
permission the next time I have an idea either.
Let's get down the the "ARC versus the world" issue now. When
you really get down to cases, it's the only part that matters.
This has nothing to do with the SEA vs. PKware lawsuit. I made
this decision before reading the materials that seem to be
floating around the net -- in fact, I haven't read them yet for
this very reason.
ARC 5.12 was a standard that is still very widespread. But SEA
is breaking this standard themselves in their new product, which
works best in its (DEFAULT!) incompatibility modes. This is
nothing new for ARC. It's part of ARC's evolutionary history. I
know that many of you are familiar with the message "Sorry, I
can't unpack this archive. You need a newer version of ARC."
This inconvenience was offset by the improvements offered, and
for those people who were using ARC on other platforms -- new
source code to port.
ARC 6.0 changed all that. For apparently obvious reasons, the
widespread distribution of source code ended. As the gain
involved in moving to 6.0 was small and the public was still
angry over the Katz lawsuit (whether they were right or wrong in
this regard, the fact remains that they were ANGRY), not too many
people in FidoNet actually used it -- and those people were
generally savvy enough to keep 6.0 archives off the public net.
ARC 7.0 is a better product than 6.0. In fact, MUCH better. It
will sell, in my opinion. To neophytes, in many cases. This
makes the .ARC extension a shaky one for people who are still
running ports of 5.12.
Why? Consider those users who have no archiving software. They
download FNEWSxxx.ARC. Then they download XARC or whatever to
unarc it. In the process of registering their shareware ARC
software or using XARC etc, they are very likely to find
themselves on the business end of a sales pitch for ARC 7.0.
Many people confronted with this pitch are likely to buy -- hell,
why not? Then they archive something up. Then they upload it.
Then if you're not running DOS or OS/2 you will not be able to
access the contents of that archive, since there is no source
available for any dearchiver and SEA is only releasing DOS and
OS/2 software. That's intolerable.
FidoNews 7-34 Page 3 20 Aug 1990
I hope the people at SEA do well. They are hard-working people
and they deserve to benefit from the fruits of their labors. But
I don't want to be in a position to help confuse the .ARC
standard, which in my opinion is now locked at 5.12, through
indirect marketing of ARC 7.0. I also do not want to somehow
become victimized by it through receipt of ARC 7.0 archives that
I can't unpack. So I won't distribute .ARC files.
Most people think that if I don't use ARC, I should use ZIP. I
think not. I know that there is code about for unzippers and
that archive formats are documented. But ZIP could wind up on
the same path as ARC, and since there are other archivers which
are not being developed or distributed with commercial gain in
mind, I'd rather pass on ZIP.
Zoo is another standard. It's not too bad, in terms of
compression. It's about on a par with ARC 5.12, in fact. But
these days that's not too good. Rumors abound that Rahul Dhesi
is adding better compression methods to it, but as yet --
nothing. That's the only bad thing I can say about it. Its
structures are well thought out, in terms of portability. In
fact, its portability is outstanding.
LHArc is Freely Available with source in both Intel assembler and
ANSI C. No marketing pitch, no fancy sales talk, always up to
date on all platforms. And it's about as good as anything else
(and MUCH better than ARC 5.12!). It's slower than most, but the
bottom line is connect time. Smaller archives cost less to move.
I chose LHArc because it was unencumbered with commercial intent
or pretense (as is also the case with Zoo), and because it
compresses much better. I intend to stay with it. There will be
no change in archive format for the forseeable future. We've
made our change and we're going to stick with it.
I might add that for those of you who are getting FidoNews via
file request from 1:1/1, you can request FIDONEWS to get the .LZH
file and FIDOTEXT to get the uncompressed .NWS file. I don't
know of anyone who can do file requests but can't uncompress a
.LZH file, but you never know.
Thanks for listening. This thread is now ended. Let's try to
get conversation regarding FidoNews back to what's in it and not
what it's in.
Cheers,
Vince
-----------------------------------------------------------------
FidoNews 7-34 Page 4 20 Aug 1990
I am one-half of the Fidonet hub for Rochester, New York
(260/2xx). Part of the thrill of being in Fidonet is wondering
what other people are going to do, and how it will affect you.
The recent Fidonews fiasco is a beautiful case in point.
A well-meaning individual decided to make a change for the
better, and used LHARC to compress Fidonews. That well-meaning
individual probably didn't consider the number of people in the
network who _expect_ or _need_ to have Fidonews be compressed as
something resembling an ARC file. (Reminder: please write a
"registered trademark" symbol after "ARC" in the preceding
sentence on any printouts of this issue of Fidonews.)
I really wouldn't have minded so much if I would have been given
warning. As it turns out, we have a node in our hub which cannot
decompress LHARC files-- he is running on a Tandy Color Computer,
and nobody has ported LHARC for his machine. This means I have
to spend time and effort in decompressing and recompressing the
Fidonews for him. Should I have to?
But enough of my bitching-- anyone can complain. I have a
solution that with enough people's help can eliminate this sort
of problem.
THE PROBLEM:
To some people, compression programs aren't a practical matter of
concern-- they are a religious issue. There is an awful lot of
"emotional liability" involved with some compression programs.
Some people refuse to use ARC (again, don't forget the
"registered trademark" symbol) because of the court case between
SEA and PKware. Some people refuse to use PKZIP for the same
reason. Both kinds of people probably don't have enough depth to
understand what the court case was really about, and waste the
time of the rest of us with their nonsense.
If recent comments in Fidonews are to be believed, some people
object to the use of LHARC because it is was written by a
Japanese person. Wow-- futile nationalism comes to software!
I'm sure there are others who have strong objections to using
programs like ZOO, and whatever other compression programs I
haven't mentioned.
FidoNews 7-34 Page 5 20 Aug 1990
Others may have more valid (non-religious) reasons for objecting
to certain compression programs. Some programs may not be ported
to their machine. Some programs might go outside the bounds of
what a particular machine can do (such as amount of memory
needed, or disk I/O limitations).
THE SOLUTION:
What is needed is a _true_ Fidonet compression standard. This
standard should be 100% public domain, and be written in as
portable a manner as possible to promote it to be ported to as
many machines as possible.
ARC, PKZIP, LHARC, ZOO, and whatever others are out there fail in
various respects. The source code for ARC isn't portable without
tedious work, and it certainly isn't public domain. PKZIP offers
no source code. LHARC offers source code, but it isn't as
portable as some would lead you to believe. And ZOO-- well, ZOO
is about the best candidate of the bunch, but I'm sure someone,
somewhere out there has some objection to it-- valid or not.
This new Fidonet compression standard would be used for the
weekly Fidonews and "nodediff." It would also replace ARC as the
_base_ standard for echomail compression. Note that this doesn't
prevent two consenting adults from using any echomail compression
program they want on the privacy of their own system.
Note that the purpose of this compression standard wouldn't be to
compete with other compression programs. The authors who write
those programs have interests other than Fidonet in mind. This
new compression standard would be both BY Fidonet members, and
FOR Fidonet members.
MAKING THE SOLUTION A REALITY:
Software doesn't appear out of thin air, and while my mythical
compression standard doesn't yet exist, nothing is preventing a
few programmers who are interested in such a project from getting
together and making it a reality.
Such a group would include programmers who were familiar with
portability issues; who could work both independently and
together with others; and who could port the compression standard
to as many machines as possible.
Every single machine that now can participate in Fidonet would
NEED this compression standard ported to it, or it would be
useless as a standard.
FidoNews 7-34 Page 6 20 Aug 1990
To start this project, I offer an echo conference to anyone who
would like to participate in it. The conference will be
unmoderated, and available initially from Fidonet 1:260/228. If
you are interested, please send mail to me at 1:260/228, and I'll
set you up so you can poll for it.
CLOSING WORDS:
Virtually every technical specification needed to participate in
Fidonet is available-- from either the Fidonet Technical
Standards Committee documents which are available, or from the
wealth of source code that many authors have contributed.
The only technical specification that isn't similarly documented
is a compression standard. This is a glaring oversight that
needs to be corrected as soon as possible.
Fidonet has grown far beyond anyone's imagination, and continues
to grow. The lack of a technical specification for a compression
standard is something that must be addressed. With your help, we
can create such a standard, and promote the spread of Fidonet.
-----------------------------------------------------------------
FidoNews 7-34 Page 7 20 Aug 1990
LHARC, The Snooze, IFNA, and Iraq
---------------------------------
By Kwityer Bychin
Well folks, here I am once again to agitate and irritate the
masses. Being that the masses are so easily agitated and
irritated.
We'll start this week's column with a little talk about the
most recent Earth-shaking, life threatening, disaster to
strike Fidonet; Vince & Harry's switch to LHArc FOR THE
SNOOZE!! (Dun Dun DUNNNN!)....
Oh boy this REALLY IS A BIG DEAL now, ain't it folks?! I
mean, the entire membership of Fidonet literally SCRAMBLES to
read the Snooze every week now don't we? I mean, it plays such
a major part in our lives, that any attempt to change it is
sacreligious!
Now, let's take a look at this thing like the mature
well-adjusted adults that we are shall we? <whew!>
Here we have Vince Perriello, a NICE GUY. He is, really.
I've met him. He spent 4 days at Conclave '90 doing this 'n
that, but not ONCE did he engage in ANY sort of devil-worship
whatsoever. Nope. No horns, no tail, just a couple bottles of
BINK BEER and a copy of Fight-O-News, cruising through the
conference.
Meanwhile, back at the ranch, all kinds of people are
foaming at the mouth because Commandant Perriello had the
audacity to change COMPRESSION METHODS for the Snooze. And to
our absolute HORROR, he didn't even ask PERMISSION. Woooo. Bad
dude, that Perriello.
Vince whips out his copy of LHarc, compresses the Snooze,
ships it off, and all kinds of PEOPLE start whining WAAAAAAH!
WAAAAAH! YOU BROKE MY BATCH FILE!! WAAAAAH!! As if NOTHING
ever went awry with their systems.
You say can't decompress the LHarc archive? Well guess what
Virigina? The source code is available! MAKE IT WORK ON YOUR
SYSTEM. What? You say you don't WANT to port the code over?
Y9ou don't know HOW? You want someone to make a version FOR
YOU? OHHHH!! Right Away!
Hey, this is a HOBBY, this ain't LIFE & DEATH here. If your
batch file's broke, FIX IT.
OH WAIT!! There's a GIF PICTURE in Snooze #733! Oh my GOD
this is terrible! We can hear the bawling already! WAAAAAHH!!
The archive is too big now!! WAAAAAH!! TWO FILES in the
archive broke my new batch file that I just fixed!! WAAAAAH!!
I WANT AN RLE PICTURE!!! WAAAAH!! I CAN'T VIEW IT ON MY
TIMEX/SINCLAIR!!
FidoNews 7-34 Page 8 20 Aug 1990
And as far as IRAQ is concerned, we could end that conflict
over there by giving Hussein a node number and sending him and
his buddies the SYSOP echo. And maybe a copy of the NEW
IMPROVED FIDONEWS! Then they could spend all their time
FLAMING AND KILLING EACH OTHER, just like WE DO!
Wow. Chemical weapons in the SYSOP conference....
Now I'm supposed to talk about IFNA. Remember IFNA? NO???
Where have you BEEN for the last week or so? Well, for those
of you that know what IFNA was, IT'S DEAD. Yep. The membership
and the BoD voted it into oblivion on August 4, 1990. TRASHED
it. And You know what? Since the thing kicked the bucket,
traffic in the IFNA echo skyrocketed! Pretty good huh?
Speaking of the IFNA echo, you GOTTA check this one out.
Read the stuff in there by this guy named FRED. He wants to
BAN BETA TESTING OF MAILERS. He wants to make an FTSC with a
minimum AGE requirement of 25. He wants to do all kinds of
INTERESTING STUFF.
If you're too young to remember Joe McCarthy, HERE IS YOUR
BIG CHANCE.
Hey kids! You're old enough to drive, old enough to vote,
old enough to DIE FOR AMERICA IN SAUDI ARABIA, but FRED SAYS
you AIN'T OLD ENOUGH to evaulate BINKLEYTERM!
Hey, let's hear it for Fred huh! <clap clap clap> A big
hand, come on!
Oh and before I go, how about that BOB MORAVSIK eh?? <clap
clap clap> Let's give him a big hand! How can I possibly end
such a violent column without taking a couple shots at
MAHATMA-RAVSIK??!! Didja read last week's SNOOZE ?? (Oh,
that's right I forgot. You can't decompress it). Well anyway,
an article in last week's Snooze says MAHATMA-RAVSIK was named
IC! PRETTY FUNNY STUFF EH? I'll bet that if that really
happened, he'd file a complaint against himself, and be
EGGS-COMMUNICATED. Oooooh. BAD EGG that Moravsik.
Well folks, that's enough drivel for this issue. Now WHIP
OUT those word processors while your blood pressure is still
200 over 150 and SEND IN THAT HATE MAIL! Let's see just how
good a job LHarc REALLY DOES!
K.B.
-----------------------------------------------------------------
FidoNews 7-34 Page 9 20 Aug 1990
Jan Ceuleers
2:295/53
TechCon-I, the Report (part 1)
OK, so here it is folks: the first part of the TechCon-I
report. "What is a TechCon?", I hear you ask?
TechCon-I was the first 2-day conference which was entirely
devoted to FidoNet Technology. It was held at the same time and
in the same hotel as EuroCon-IV: on July 14th and 15th in
Antwerp, Belgium.
Anyway, if this is the first you hear of TechCon, you haven't
been reading FidoNews regularly, because it was announced well
in advance, and already commented upon by FidoNews' editor,
Vince Perriello.
Vince wasn't at TechCon simply as the FidoNews Editor (in fact,
that's not why he was there at all). He'd also brought Bob
Hartman and the new BinkleyTerm with him. Moreover, Rick Moore
had appointed him as the official FTSC representative at
TechCon.
Obviously, there were a lot of other interesting people among
the attendants (me, for one ;-). I'm not going to name any,
because I'd have to list all of the attendants in order not to
forget anyone interesting.
Anyway, here we go...
BinkleyTerm 2.40 Release - Bob Hartman and Vince Perriello
----------------------------------------------------------
It had been quite a while since the Trio released BinkleyTerm
2.30 (September 5th, 1989), so something was to be expected.
We were nevertheless semi-surprised and delighted that Bob
and Vince came to Europe to give their first public
presentation on BinkleyTerm 2.40 at TechCon.
The features:
- Most of the messages BinkleyTerm displays and puts in its
log are now configurable, in order to accomodate non-English-
speaking users. This will probably break every log analyser
in existence, but what the heck :-). The messages are
contained in a separate file (BINKLEY.LNG) which can be
generated by a language file compiler. The structure of this
file is published (by means of the Binkley source code), so
log file analysers should make use of this structure, and
compare the messages they find in the log to the ones they
find in the .LNG-file.
- Janus, the long-awaited full duplex file transfer protocol,
has finally been added on an experimental basis. It is
important for users to understand that it might break. (As it
FidoNews 7-34 Page 10 20 Aug 1990
happens: evidence that there was indeed a problem had been
popping up earlier that day. During the rest of their stay,
Bob and Vince worked with their local beta team to start
solving this and other problems, JC). Janus is rather
counterproductive on HST connections, because of the long
line turn-around times. It does work very well in V32
situations though.
- A state engine has been implemented, providing a relatively
simple way to implement new protocols should the need arise.
This has also helped in assuring compatibility with FTS-0007
and FTS-0008, much to the delight of SEAdog users.
- BinkleyTerm now supports 5D-addressing, that is: zone, net,
node, point and domain. This includes support of FSC-0045 and
FSC-0049. The nodelists for each of the domains are separate:
they no longer have to be compiled into a set of huge files.
A drawback is that no packer easily supports this new feature
as yet. It can be done with some intricate batch file
programming though.
- The first pop-up windows have been added to Bink: Alt-G
(interactively generates a file request), Alt-S (a file
attach) and Alt-K (removes all mail for the named node from
the outbound). This required another extension of the Colors-
statement in the config file.
- BinkleyTerm can now exit with a configurable exit code upon
receipt of one or more files with a certain extension (say,
.TIC). Comes in handy for SDS nodes.
- Support for yet another multitasker was added: PC-MOS.
Also, if no multitasker is detected nor declared, Binkley
will call the DOS idle interrupt (0x28) whenever it would
have called the multitasker's time slice release routine, had
a multitasker been installed. This tremendously speeds up
background tasks under DOS, such as the $25 Network.
- Another long-awaited feature is MaxBytes: a limitation of
the number of bytes a certain class of nodes is allowed to
request during one session. Insufficient time was left before
TechCon started for Vince to implement a limitation based on
time (or baud rate, if you like) as well. This will be
incorporated in a future release.
- In order to avoid the dead-time between the CONNECT message
from the modem and the start of the session, an MNP and V42
Modem Protocol Negotiation Filter has been implemented. The
3-second delay was required for the classic case where a non-
MNP modem was called by an MNP modem. The MNP handshake had
to be skipped, since it could contain an ESC, which would
obviously cause Binkley to drop to the BBS. It is now
filtered instead.
- A Terminal-mode initstring was added.
- Curmudgeon mode will no longer throw out new nodes who use
the net/-1 or net/9999 convention, so as to allow NCs who
like Curmudgeon mode to take calls from nodes in spe.
- In order to support multi tasking even better, semaphore
files are being placed in the outbound areas during sessions.
Other tasks can look for these files (.BSY extension) and not
do anything that might interfere with the ongoing session.
Binkley will refuse to send files to a node if it detects
that that same node is engaged in a session with a Binkley in
FidoNews 7-34 Page 11 20 Aug 1990
another task (or on another workstation of the LAN).
- The screen can now be unblanked during a session. The
unblanking functionality can now also be selected: should the
screen unblank when a key is pressed, or whenever something
happens?
- BinkleyTerm is definitely dolphin-safe. No Bink has ever
killed a dolphin. (This is an undocumented feature, JC).
Question time.
(The following questions and answers reflect my
interpretation of the discussion, JC).
Q: Could you please implement a file request limit based on
time as well?
A: Yes, we're working on it. It could have been in this
release, but we ran out of time.
Q: Why does an .RSP-file need to be a file. Couldn't you send
a packet like D'Bridge ?
A: You can't always send a packet and expect the other side
to know that you've sent mail. Not all protocols support
sending more than 1 packet per session in each direction.
Q: Can a BinkleyTerm user put a file on hold for a point that
is not his own without knowing the point's private net?
A: No. The reason why BinkleyTerm isn't fully 4D is that this
poses a problem with Opus 1.03. Wynn defined a 4D structure
in the hello-packet, but subsequently didn't use it himself.
Therefore, if we were to implement this (Bink hasn't changed
in this respect since 2.00), a point using BinkleyTerm would
pick up the mail destined for his boss. This was not
acceptable, because of the large number of nodes (a few
thousand) that were using barefoot Opera, and the release of
Opus 1.10 was far from imminent. Now that this problem has
been addressed in Opus 1.10, the importance of this argument
has obviously diminished, but we still don't think that the
number of nodes that would have to change over overnight is
sufficiently small yet. But we will address this problem in
the near future ("It'll probably be in the next release").
Q: What do you think about EMSI?
A: The way we see it, EMSI should address 3 problems: we'd
like to see a novel way to update the nodelist, it would be
nice if two nodes could exchange all the mail for their
respective AKAs during a single session, and we'd like to be
able to talk to mainframes, that have front-end processors
requiring CRs between input records, as well as 7-bit data.
The first two are indeed addressed by EMSI as of now, but we
feel that the third-one is much more important, in view of
the fact that large companies have offered us (FidoNet) their
excess capacity for free. We're sure Chris and JoHo will work
with us towards a solution to this problem.
Henk is a professional crypto-analyst. He talked about the
MD4 method of message authentication, which was devised by an
American corporation with the cooperation of M.I.T.
The algorythm creates a 128-bit (16-byte) fingerprint which
would take 2^128 computations to fake. Due to its simplicity,
MD4 is very fast. Henk provided sample source code in Pascal
and C (the files MD4PAS.ARC and MD4C.ARC are available from
2:295/27). He urges everyone to take a look at this, and to
propose a way to utilise it in FidoNet.
Before this, or any other method of authentication, can be
used, we need to define exactly what the 'message text' is.
Kludge lines are certainly not a part of the message text in
this respect: they should be skipped when calculating the
message digest, because they can change as the message
progresses through the network. The problem is that there
isn't really a definition of what a kludge line really is.
Henk has been talking to Randy Bush about this, specifically
about the definition of a 'physical line'. This must be
solved first.
Edifact -- Henk Wevers
----------------------
The type 2 packet, as it is currently in use, has proven to
be problematic, in that many of its uses are too loosely
defined, and that too little flexibility is allowed for. We
therefore need a solid standard on message structure, for
which there are two well-known contenders: X.400 and Edifact.
The X.400 standard is very difficult to implement, so let's
concentrate on Edifact.
Edifact is an entirely text-based (not necessarily ASCII)
message standard, which is very simple to implement. (As a
matter of fact, the commercial version of Dutchie already
supports Edifact.) The standard comprises specifications on
the message format and on the bundling of those messages.
The bundling part of the standard is very straightforward:
messages are simply concatenated in a file to form a bundle.
As for the message format: a group of people planning to
exchange Edifact messages is free to define its own message
building blocks, in addition to those that are predefined in
the standard. The FTSC could be the body that maintains a
list of building blocks for use in FidoNet: a database of
centrally allocated building block definitions.
FidoNews 7-34 Page 13 20 Aug 1990
The character set in use in most Edifact implementations to
date is 7-bit ASCII, because of the wide range of platforms
the messages need to be processed on. The standard is already
in common use in the transportation, the medical and the
banking sectors.
Edifact allows for the easy implementation of forms: a
company could send its customers an Edifact message
containing a form for them to fill out, to order certain
goods, for example. Likewise, an NC could send such a message
to an applicant for a node number. Form fields can be
mandatory or optional, conditional, repetitive, etc. This
implies that a message editor for Edifact looks more like a
form processor than like a 'conventional' message editor.
This standard is not difficult to implement, and it'll gain
us a lot of credibility in the world at large.
For more info on Edifact, please ask Henk Wevers in netmail
how to order a copy of the standard.
A brain storming among a few attendants during the coffee
break caused Vince to bring a subject up that had previously
been discussed by a subcommittee of the FTSC: a way to
distribute conferences without having to insert PATH and
SEEN-BY information (or its equivalent).
Vince's version of this concept was based on the idea that
each node has a maximum of one uplink for a certain area, and
that a bit in the message header (like the file request bit,
which isn't used in echomail anyway) would specify whether a
message is on its way up in the topology, or on its way down.
After a number of questions from the audience, this mechanism
was proven not to be immune against dupes, and it was agreed
that any type of conference distribution system without PATH
or SEEN-BY information should be.
Bob pointed out that GroupMail actually does all the things
we want, and that it's a mystery why the GroupMail standard
hasn't been used more widely. The standard is published, and
there is no reason why groupmail processors could not be
written that support different compression programs than Arc.
OK, so that's the first part. The rest of it will appear in the
next issue, or so I hope...
FidoNews 7-34 Page 14 20 Aug 1990
Jan Ceuleers (2:295/53)
-----------------------------------------------------------------
FidoNews 7-34 Page 15 20 Aug 1990
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
-----------------------------------------------------------------
FidoNews 7-34 Page 18 20 Aug 1990
Christopher Baker
MetroFire, 1:135/14, Miami_FL_USA
This Time it's More than a Phone Number!
MetroFire is changing numbers AND locations this time. As
of Nodelist.229 on 17 Aug 90, MetroFire will cease to be
1:135/14 and will become 1:374/14 in Titusville_FL_USA.
135/14 will continue to be listed in Net 135 for a couple
weeks while I make the transition to my new locale and get
the requisite dedicated line. It will appear as a Hold Node
in both Nets 135 and 374 during the changeover.
Those of you who have active links to MetroFire are advised
to note this change and to change any passwords or links to
1:374/14 from 1:135/14 after you've compiled Nodelist.229.
Those linked to Echos that I originate [FHCOOK and
MENSANS_ONLY] will continue to get those Echos sent to you
directly. You will not be able to poll the new listing for
a couple weeks, at least.
This move is sudden and a direct result of a Workmans
Compensation case I've been embroiled in for some time. I
have received a judgement in my favor but it still has not
been paid and I can no longer afford to live in Miami while
my former employer attempts to reverse it on appeal.
I apologize to anyone who is being inconvenienced by this
change. I am not leaving FidoNet or BBSing but I must move
to Titusville [and was going to anyway when the case was
settled] where my family resides before the sheriff throws
me out [I haven't been paid since 29 Mar 90]. [grin]
Mail sent to either Node number will eventually make it to
me but I suggest you start using 1:374/14 as soon as you
compile Nodelist.229.
My thanks to Net 135 for their generosity and cooperation
and Hello to Net 374! Here comes trouble. [snicker]
5 Oct 1990
21st Anniversary of "Monty Python's Flying Circus"
6 Nov 1990
First anniversary of Van Diepen Automatiseert, 2:500/28
14 Nov 1990
Marco Maccaferri's 21rd Birthday. Send greetings to him at
2:332/16.0
1 Jan 1991
Implementation of 7% Goods and Services Tax in Canada. Contact
Joe Lindstrom at 1:134/55 for a more colorful description.
16 Feb 1991
Fifth anniversary of the introduction of Echomail, by Jeff Rush.
7 Oct 1991
Area code 415 fragments. Alameda and Contra Costa Counties
will begin using area code 510. This includes Oakland,
Concord, Berkeley and Hayward. San Francisco, San Mateo,
Marin, parts of Santa Clara County, and the San Francisco Bay
Islands will retain area code 415.
1 Feb 1992
Area code 213 fragments. Western, coastal, southern and
eastern portions of Los Angeles County will begin using area
code 310. This includes Los Angeles International Airport,
West Los Angeles, San Pedro and Whittier. Downtown Los
Angeles and surrounding communities (such as Hollywood and
Montebello) will retain area code 213.
1 Dec 1993
Tenth anniversary of Fido Version 1 release.
5 Jun 1997
David Dodell's 40th Birthday
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
