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