Subj : Max subject length: 71 or 72 chars?
To   : Rob Swindell
From : Andrew Leary
Date : Mon Aug 19 2019 02:16 am

Hello Rob!

18 Aug 19 17:37, you wrote to all:

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> However, in reviewing FTS-1 (http://ftsc.org/docs/fts-0001.016) my/our
RS> interpretatoin may be wrong.

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>               |                    subject                    |
RS>               ~                  max 72 bytes                 ~
RS>               |                null terminated                |

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.

Regards,

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)