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)