TIP: Click on subject to list as thread! ANSI
echo: public_domain
to: Rowan Crowe
from: Bob Lawrence
date: 1995-02-04 08:19:14
subject: sot/eot

RC> Oh, BTW, I also think SOT/EOT is irrelevant. Just look for the
 RC> last occurrence of "SEEN-BY", "^aPATH", "
! Origin: ", "---" in
 RC> that order, to find the end of text.

  You have made my day, Ro, but you can look forward to a loony
attack by a killer Paul.

 RC> Good to see some "new blood" writing fidonet software.

  I came to programming late, and to my amazement I find that it is
fun! Writing a qwk2pkt converter and back again is just a way to learn
a few programming tricks the hard way.

 RC> Have you linked into NET_DEV yet? That would be a much better
 RC> place to hold your conversations.

  It's more fun stirring Paul, who is kinky for ISO-C. My goal is to
get him to write something in Visual Basic - the stirrer's Mount
Everest. 

 RC> Most tossers would first check for an AREA: line before any
 RC> netmail kludges. It's not unknown for braindead software to put
 RC> ^aINTL or other netmail kludge lines into echomail, either.

  Aha! I'd better go back and make sure I can handle that, then.

 BL> Oddly, two bytes are allocated for attribute, but only one is
 BL> used. Perhaps the second one could be used for zones: 16 of
 BL> each.

 RC> One? Incorrect. The attribute is a 16 bit word, 2 bytes.

  Yair - Paul sorted me out on that one. My knowledge of binary
arithmetic is only slightly better than a Grasshoopper's knowledge of
quantum mechanics :-)

 BL> IMO, the main problem with PKT format is the message header. It
 BL> is lacking:

 BL> 1. A conference name or number

 RC> A number would certainly not work with PKTs

  Yair... I keep forgetting  that QWK has control.dat.

 BL> 2. A way to show that the message is netmail

 RC> All fidonet traffic originally *was* netmail only. Echomail was
 RC> an afterthought.

  Oh, well... something to show that it's *not* netmail!  :-)

 BL> 3. Zone address
 RC> So were zones

 BL> 4. Point address
 RC> So were points

  Aaarrrgh! This explains why they are missing.

 BL> It should be possible to add an 0x0d at byte 66 (say) in the
 BL> Subject field, and use the last 6 bytes for the extra data,
 BL> without having to invade the message field. This would make
 BL> more sense than adding SOT, and the other kludges.

 RC> What if the data in those 6 bytes contained a null?

  whoops!

 RC> See?

  There's no need to rub it in... :-)

 RC> Limiting an areatag to 8 bytes is ridiculous. Some of the
 RC> internet gated newsgroups have areatags of more than 40
 RC> characters. How would you suggest that I could squash
 RC> "PHSC_POINT_SYSOP" into 8 characters and still make it
 RC> meaningful? Or "COMP.LANG.BASIC.VISUAL.ANNOUNCE"?

  The internet is not real to me. I have enough trouble with 1000
areas, let alone a million! I concede your point, though.

 RC> When FTS-1 was first defined, everything was sent uncompressed,
 RC> so packet size was an issue. These days it's irrelevant when
 RC> everything is compressed, so a fixed size header would be a
 RC> good idea, and practical to boot.

  Yes. Thank goodness. One point to me, at last.

 BL> Do you know if mailers check the length of the 72-byte Subject
 BL> field? Maybe we can bung it all in there...

 RC> They (correctly) check for a null, and will assume everything
 RC> after that is the user text. The next null terminates the
 RC> message. What if your extra 6 bytes of data has two or more
 RC> nulls? Bang.

  I told you not to keep rubbing it in! :-) If they don't check for
length, we could sneak hundreds of extra bytes and just use ascii
without nulls. The ^a kludge lines are ascii anyway.

 RC> Rather than extending type 2, just create a new type 3.
 RC> Everyone else is doing it.

  (grin) I went through the change from TV to colour and FM to stereo,
and the way to get a new standard accepted is to make it backwardly
compatible, with added features (like colour or stereo). The only
thing we could offer fido is full graphics in the message... or perhaps
make it easily internet compatible? If we could extend the subject 
header to make the overall header a fixed size, and put everything in 
the header, we could do this without breaking the existing mailers...

  But I was just playing a mind game with Paul.

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

---
* Origin: Precision Nonsense, Sydney (3:711/934.12)
SEEN-BY: 690/718 711/809 934
@PATH: 711/934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.