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.
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.
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".
Hello Rob!
18 Aug 19 17:37, you wrote to all:
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".
After discussion in the FTSC echo, it is the FTSC's position that this is the correct interpretation of FTS-0001.016. These fields must be null-terminated, and the length specified includes the required NUL (0x00) byte.
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".
After discussion in the FTSC echo, it is the FTSC's position that this is
the correct interpretation of FTS-0001.016. These fields must be
null-terminated, and the length specified includes the required NUL (0x00)
byte.
Cool. Let's document that position. :-)
After discussion in the FTSC echo, it is the FTSC's position that
this is the correct interpretation of FTS-0001.016. These fields
must be null-terminated, and the length specified includes the
required NUL (0x00) byte.
Cool. Let's document that position. :-)Please be aware that this "discussion" is nothing more than a single message by a single person...
... with nobody been able to disprove that :-)
After discussion in the FTSC echo, it is the FTSC's position that
this is the correct interpretation of FTS-0001.016. These fields
must be null-terminated, and the length specified includes the
required NUL (0x00) byte.
Cool. Let's document that position. :-)
Please be aware that this "discussion" is nothing more than a single
message by a single person...
... with nobody been able to disprove that :-)
discussion... with nobody been able to disprove that :-)
Your explanation of the issue was clear and concise. No further
was needed.
agreed... the problem, as it were, stems from a non-coder having
written the documentation in question... for its day, it made a lot of sense and there were no ambiguities... these days, however, is another story...
Please be aware that this "discussion" is nothing more than a single
message by a single person...
... with nobody been able to disprove that :-)
Alexey,
Please be aware that this "discussion" is nothing more than a single
message by a single person...
... with nobody been able to disprove that :-)
Nothing needed to be disproven as the spec is pretty straightforward.
It's just that native english speakers needed to be made aware.
that it is (so far) a single message by one individual? why wouldI checked the note, and agreed to .016 without any comment.
anyone want to disprove that? ;)
)\/(arkBye/2 Torsten
I disagree. I think it's ambiguous and incomplete, if not misleading.
But again, it should be made clear that the "72 bytes" here includes the required null terminator, so a message subject is in fact limited to a maxmimum length of 71 characters.
Hi Rob,
But again, it should be made clear that the "72 bytes" here includes the required null terminator, so a message subject is in fact limited to a maxmimum length of 71 characters.
From my point of view you were cherry-picking, probably involuntary, from sections B1 and C1.
They're 2 different kinds of beast.
And do you also know where the "71" comes from ?
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.
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.
I checked the fmail source: it reads a maximum of 72 bytes (untill and including a NULL) from the pkt file for the subject. It doesn't care if byte 71 isn't a NULL (when the maximum of 72 bytes are read), but it forces it to NULL before further processing. So effectively limiting the subject to 71 characters. If the byte after 72 subject characters would be NULL, it regards that as the 1st byte of the next field. So that would mean a message body of 0 characters.
I'm pointing out the issues with the "subject" definition. Did you want
me to quote the entire spec?
And do you also know where the "71" comes from ?
Well, I took 72 and subtracted 1 (for the required null byte). I assume
the 72 came from 36 (the total length of the to and from fields)
multiplied by 2. Is there some other significance of 71 that I'm not
aware of?
It's not certain but my bet is the 71 comes from there, someone's knowledge/experience embedded in punchcard technology.
As for the null terminator that is a hangover from strings being terminated with nulls. I am unsure where that idea originates
but I suspect pre-F77 FORTRAN.
Hi Rob,
I'm pointing out the issues with the "subject" definition. Did you want me to quote the entire spec?
Oh dear ...
Something was clear for all the developers since 1990, there were a lot of them, and now suddenly it's an issue?
And do you also know where the "71" comes from ?
Well, I took 72 and subtracted 1 (for the required null byte). I assume the 72 came from 36 (the total length of the to and from fields) multiplied by 2. Is there some other significance of 71 that I'm not aware of?
My IT experience starts somewhere in the very late 1960, punchcard heaven.
A punch card had 80 columns, 1-71 were used for coding statements, 72 was th continuation column if something didn't fit in 71 positions, then it continu on the next card, 73-80 contained the sequence number of that card in the wh deck of punch cards.
It's not certain but my bet is the 71 comes from there, someone's knowledge/experience embedded in punchcard technology.
Just like the old length of the system name limited to 51 or 52 or something It also finds its origin in programming techniques from days gone by ... I think.
\%/@rd
| Sysop: | Zazz |
|---|---|
| Location: | Mesquite, Tx |
| Users: | 7 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 20:15:51 |
| Calls: | 157 |
| Files: | 2,095 |
| Messages: | 145,179 |