PE> Presumably you are aware of the standard whereby 3:3/0
 PE> represents the Zone 3 gate, 3:711/0 represents the node
 PE> coordinator of net 711? I'm not sure if 3:0/0 is the Zone
 PE> Coordinator at all.

  I'm not at all surprised. The Fido standards are pathetic. Who is
0:0/0.0 - God?

 PE> Better give me an FTS or Policy4 reference that says that 0:0/0
 PE> is never a valid address while you're at it.

  I can't even give you a reference that says all 64,000 numbers are
meant to be used! One says yes, another says no. FTS-0001 has to be
the most ramshackle and ambiguous document I have ever seen. I
especially like the way they keep adding to it, without revising the
original... so you end up with many standards all subtly contradictory
so no one knows what is required, and ends up relying on common
practice.

  I especially like the QWK format standards where the 128-byte header
has 129 bytes in one reference and the other has 126. ROFL!! 

  Policy4 looks like it was written by someone with an attitude. It 
lays down the Law without defining the terms, and is paradoxical as a 
consequence.  

  I'm used to professional standards agreed internationally under IEC,
ISO, IEEE and things like that. This is just crap thought up by silly
kids.

 BL> The way I see it, obviously faulty mail should be kept local,
 BL> to save money. From what you've been saying, it just goes out
 BL> to random addresses, presumably passed from one BBS to the next
 BL> all over the world, looking for a home. From a user's point of
 BL> view, an important message just vanishes, and privacy is zilch.

 PE> It passes from one BBS to another waiting for someone who
 PE> doesn't know where to pass it. That person so far has been
 PE> Prophet for mail that has left this system.

  Yair... someone sets up their board properly, eventually. I'm not
criticising you in particular; just the stupid system!

 BL> Does Squish repack and rename packets, or do they just go
 BL> complete?

 PE> repack and rename. Any message from you may need to be sent to
 PE> multiple places, in the case of echomail, or routed to a
 PE> particular address in the case of netmail.

  That was what I assumed - in which case it would be possible for
Squish to do error checking if it reads the headers. This must finally
happen when it gets to Prophet.

 BL> I hate to agree with Rod

 PE> It often means you end up backing the whacky alternative,
 PE> doubly so if it involves anything to do with fidonet. 

 You should worry a little, Paul, when the two most experienced
engineers on the BBS sound like they are whacky, to you. It may be
that Rod and I are half-right.

 PE> You have to rely on it, since you cannot possibly second-guess
 PE> the net address yourself.

  You could always look up a nodelist to see if it exists... but we
are talking about *missing* addresses, and silly ones. Anything with
Z64000 has to be wrong - yes? If anything above Z100 is wrong, and you
check it, you've just improved your odds 640-times. That's a good 
safety net. With 64,000 possibilities in zn, net, node, it allows
260,000-billion address, enopugh for each person on the planet to 
have 50,000 addresses each. It seems a little excessive to me. We 
only want one or two reserved addressed to do error checking...

 PE> If it's buggy, it should be fixed, or not used. Using
 PE> non-conforming software on the net can land you with a policy
 PE> complaint. 

  The biggest bug in any system is typing at the keyboard. When I
started my programming education, I actually believed that bugs were
faults in the system - like asking the processor ot do something it
couldn't. I have since discovered that what you guys call bugs are
just faults. I agree that faulty programs should be fixed, and I 
expect that all programs are fault-free as the first step. The *next* 
step is to make them foolproof and failsafe, so that even a fuckwit 
can use them.

 PE> Using non-conforming software on the net can land you with a
 PE> policy complaint. 

  And so it should. I am discussing the system itself, and its awful
inadequacies. All error-checking should be done at the local level;
preferably in PQWK on *my* computer before it even gets sent, but a
proper system would back that up with a safety net at each following
node. Your attitude is that everything must be perfect. That's a bad
attitude. It creates an unnecessary  shambles. 

 PE> Trouble is, every address is valid, according to the standard.

  It's clear that the standard has flaws.

 PE> It's none of my business where a node chooses to send netmail
 PE> to. With a couple of exceptions, I just have to give it to
 PE> Dave.

  Your argument falls apart at Prophet, though, doesn't it? If no one
checks faulty addresses, every message ever sent would keep rotating.

  This is another non-self-checking problem that does not really
concern me. Each node should check what it is sending, and where, to 
prevent loops. It would be fairly simple to check that you do not 
send and receive the same conference, except in a straight line. 

 PE> It is extraordinary that you would seek to limit a value of
 PE> 0x2020, or 8224. It's things like that that CAUSE problems. 

  Not *limit* it, Paul... make 0000 and 2020 *exceptions* to use as
defaults easily recognised as errors. You are stuck with a system that
accepts *anything*. That's just mad.

  But even if we limited the addresses to 128 zones, 4096 nets and 
16,384 nodes, it would still give us 8-billion addresses. How many 
do we need? My guess is that 8-billion is plenty - one each.
 
 BL> I know 222 does that (which is why I'm using it). I wondered
 BL> what Rod's 202 did.

 PE> I will most likely to continue to fix bugs in the latest
 PE> version, but not put in any enhancements, but that's it. The
 PE> code is like vomit. BFN. Paul.

  I can't make head nor tail out of it. I have trouble reading C code
anyway, but qwk2pkt is impossible for me. I preferred to work it out
for myself, from scratch.

  BTW, I'm looking at pkt2qwk - and it creates numbers at the end of
the qwk message header, where the qwk packets from BlueWave and the
SPCUG have spaces. BlueWave seems happy enough to them ignore anyway,
but these numbers are not supposed to be there. 

  BTBTW... I've found a nuisance with your "EOT:" proposal in PKT.

  I'm making my VB version of pkt2qwk, and when you read the message
to convert to QWK, the "SOT:" goes in seamlessly. I read the message
looking for the 0x00 terminators, and then the "AREA:" at the head of
the message, and then "SOT:". If I don't find it, I use the previous
reference as the actual message-start. No worries. Foolproof, and
nicely compatible.

  At the other end, it's not so nice. If you look for "EOT:" first,
and it is missing, you will pick up the next one in the next message 
and break the packet. You have to look for the 0x00 message terminator 
first, and then come back to find "EOT:". This is the messy part.

  A much nicer method would be to have the "EOT:" at a *fixed*
distance from the 0x00 message-terminator, or even a maximum distance
that you could use to check one against the other, and be sure you
are in the same message. You could do the same thing with the "SOT:"
header. As well as closing off the message, it would give you a way to 
do double-checking, and still be backwards compatible if the SOT and EOT 
were missing.

  Since all this takes place in the actual message, it would not break
the FTS-0001 standard. All you would have to do is pad after "EOT:" with 
spaces to keep the spacing from the null terminator at 128 bytes or 
whatever you think is enough to add the origin, path and seenby.

  What do you think?

Regards,
Bob
    
___ Blue Wave/QWK v2.12
@EOT:

---