Subj : Max subject length: 71 or 72 chars?

Subj : Max subject length: 71 or 72 chars?
To : All
From : Rob Swindell
Date : Sun Aug 18 2019 05:37 pm

Synchronet and SBBSecho has always treated the to, from, and subject fields in FidoNet "Stored Messages" (*.msg files) and "Packed Messages" (those contained in type 2 packets) as null-terminated strings with a maximum *usable* length of 35 characters for the "to" and "from" and a maximum *usable* length of 71 characters for the "subject".

However, in reviewing FTS-1 (http://ftsc.org/docs/fts-0001.016) my/our interpretatoin may be wrong.

FTS-1 is ambiguous about whether or not the last character of these fields may be used or not. In other words, if a "to" or "from" name is exactly 36 characters, is it legal to use all 36 characters and *not* include a null terminator in a stored message? It is a fixed-length field after-all, so a terminator should not be needed if all 36 characters are used. Similarly, would it be possible to use all 72 characters for a message subject? This would be consistent with how the "password" field in a packet header is stored (no null terminator included for full-length passwords).

"Packed Messages" use variable length header fields, so even full-length header fields (e.g. a 36-character to or from name) would still require a null terminator. But the spec is not clear:

| subject |
~ max 72 bytes ~
| null terminated |

It's not clear if that "null" is *included* in the max 72 bytes, or not. :-(

How does *your* implementation handle these fields? What would happen if you received a Stored Message where byte 71 (the 72nd byte) of the "subject" was non-null? Or if you received a packet that included a 72-character subject followed by a null? Both of these conditions do not appear to violate FTS-1, but I'm not sure how other programmers have interpetted these specs over the years.

It seems wasteful to have critical bytes in a packet header that are *always* zero, so if we could agree that byte 71 (couting from 0) of a subject and byte 35 (again, counting from 0) of to/from names are *usable*, that would make these message/packet formats a little more sane.

But in any case, the spec (FTS-1) needs clarification: I can easily justify either interpration, which could lead to wildly-incompatible implementations of FTN message/packet generating and parsing software.