Answering msg from Bob Lawrence to Paul Edwards,
on Wednesday January 25 1995 at 09:23

    Whew, this 19k+ message will certainly break some tossers.

    Good to see some "new blood" writing fidonet software. Have
you linked into NET_DEV yet? That would be a much better place to hold your
conversations.

[ lots about SOT/EOT deleted ]

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

 PE>> What you do is write a message in the NETMAIL area of a BBS,
 PE>> e.g. 3:711/934, and send the netmail to "You Stupid Sysops" at
 PE>> address 3:711/809. You make the first line of the message "AREA
 PE>> ZONE3_SYSOP". The mailprocessor at 3:711/934 will export this
 PE>> netmail message and send it to 3:711/809. 3:711/934 considers
 PE>> this to be a normal netmail message, after all, it was posted
 PE>> in the special area called "NETMAIL".

 BL>   There is no cure for brain dead software. I don't believe this!

 BL>   How does this message get past netmail? Your mailer has presumably
 BL> just finished reading the message header for the TOPT, FMPT address,
 BL> and *then* it decides to throw the whole thing to another area if it
 BL> finds an "AREA:" in the message body after that? Are you kidding?

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

 BL>   BTBTW... in the PKT message header, are the cost bytes used for
 BL> anything? One of those could be used to do the zones, which itself
 BL> could be used to define Netmail independently.

    I don't see what relevance the cost of a message on one system has to
another. AFAIK it's unused.

 BL>   The other thing that confuses me is the two attribute bytes in
 BL> position 11 and 12 of the message header. In all your packets the
 BL> first is set to 0x01 for netmail, and 0x00 in everything else, but
 BL> this contradicts what is defined in FTS0001, where bit 0 is Private
 BL> and Bit 1 is crash. It makes more sense to define Netmail separately,
 BL> in the header, the way QWK does it.

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

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

bit       meaning
---       --------------------
  0  +    Private
  1  + s  Crash
  2       Recd
  3       Sent
  4  +    FileAttached
  5       InTransit
  6       Orphan
  7       KillSent
  8       Local
  9    s  HoldForPickup
 10  +    unused
 11    s  FileRequest
 12  + s  ReturnReceiptRequest
 13  + s  IsReturnReceipt
 14  + s  AuditRequest
 15    s  FileUpdateReq

       s - need not be recognized, but it's ok
       + - not zeroed before packeting


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

 BL> 1.  A conference name or number

    A number would certainly not work with PKTs

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

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

 BL> 3.  Zone address

    So were zones

 BL> 4.  Point address

    So were points

 BL> 5.  Seenby and Path space

    See above re: echomail

 BL>   In the existing header, the only available space to add extra
 BL> information is byte#2 [message type]; byte#12 [attribute high order];
 BL> bytes #13, #14 [cost], and the end of the Subject field.

    You can't use the message type field, that is a defined 2 byte word
field. Same with the attribute.

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

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

 BL>         +-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-+
 BL>         |  FromUserName, max 36 bytes Null terminated |
 BL>         +-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-+
 BL>         |  Subject, max 66 bytes, CR terminated       |
 BL>         |                                             |
 BL>         +-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-+
 BL>         |  OriginPoint  0-256  |  DestPoint 0-256     |
                             ^                   ^
 BL>         +-+--+--+--+--+--+--+--+-+--+--+--+--+--+--+--+
 BL>         |  OriginZone   0-256  |  DestZone  0-256     |
                             ^                   ^
 BL>         +-+--+--+--+--+--+--+--+-+--+--+--+--+--+--+--+
 BL>         |  Netmail Flag  FF?   |  Null Terminate 00   |
 BL>         +-+--+--+--+--+--+--+--+-+--+--+--+--+--+--+--+
 BL>         |     Text unbounded, null terminated         |
 BL>         |                                             |
 BL>         +-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-+

    See?

 BL>   The subject could be further chopped to 58, giving another 8 bytes
 BL> in the header to add a CR delimited conference name. It might even be
 BL> possible to add to the 72 bytes already allocated for
"Subject", and
 BL> include seenby and path in there as well.

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

 BL>   A better idea would be to use a fixed-length header padded with
 BL> spaces, so that both the packet header and the message header are
 BL> defined separately from the null termination, and could be made
 BL> failsafe.

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

 BL>   What d'yer reckon? Can you see a catch? Do you know if mailers
 BL> check the length of the 72-byte Subject field? Maybe we can bung it
 BL> all in there...

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

 BL>   The idea of an expanded header appeals to me much more than adding
 BL> kludges with SOT and EOT, and still not having complete freedom within
 BL> the message field. You still have to protect the 0x01 ascii control
 BL> character that we need to send graphics.

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

Best wishes, Ro.

---