RS> Synchronet and SBBSecho has always treated the to, from, and subject RS> fields in FidoNet "Stored Messages" (*.msg files) and "Packed RS> Messages" (those contained in type 2 packets) as null-terminated RS> strings with a maximum *usable* length of 35 characters for the "to" RS> and "from" and a maximum *usable* length of 71 characters for the RS> "subject".
RS> FTS-1 is ambiguous about whether or not the last character of these RS> fields may be used or not. In other words, if a "to" or "from" name is RS> exactly 36 characters, is it legal to use all 36 characters and *not* RS> include a null terminator in a stored message? It is a fixed-length RS> field after-all, so a terminator should not be needed if all 36 RS> characters are used. Similarly, would it be possible to use all 72 RS> characters for a message subject? This would be consistent with how RS> the "password" field in a packet header is stored (no null terminator RS> included for full-length passwords).
RS> "Packed Messages" use variable length header fields, so even RS> full-length header fields (e.g. a 36-character to or from name) would RS> still require a null terminator. But the spec is not clear:
RS> It's not clear if that "null" is *included* in the max 72 bytes, or RS> not. :-(
You raise a valid point there, Rob. The FTSC will have to look into that.
RS> How does *your* implementation handle these fields? What would happen RS> if you received a Stored Message where byte 71 (the 72nd byte) of the RS> "subject" was non-null? Or if you received a packet that included a RS> 72-character subject followed by a null? Both of these conditions do RS> not appear to violate FTS-1, but I'm not sure how other programmers RS> have interpetted these specs over the years.
I will look into how the software I maintain (MBSE primarily, although MakeNL does generate Stored Messages as well) would react in those scenarios.
RS> It seems wasteful to have critical bytes in a packet header that are RS> *always* zero, so if we could agree that byte 71 (couting from 0) of a RS> subject and byte 35 (again, counting from 0) of to/from names are RS> *usable*, that would make these message/packet formats a little more RS> sane.
RS> But in any case, the spec (FTS-1) needs clarification: I can easily RS> justify either interpration, which could lead to wildly-incompatible RS> implementations of FTN message/packet generating and parsing software.
I will forward this to the FTSC for discussion. IIRC, there are copyright issues involved with updating FTS-0001, so we may end up having to rewrite it entirely.