[aprssig] Making APRS text messages longer

[Heikki Hannikainen]

On Sun, 21 Nov 2021, Kenneth Finnegan wrote:

> 3. Sharing the same TX delay for multi-line messages or bulletins 
> because the message length limit is so ungodly short because of the IBM 
> PC screen width limits

This is actually something I'd like to improve a bit. The limit indeed is 
way too short, and we should figure a way to increase it for modern 
software without breaking a lot of things. I bump into the limit every 
time I do messaging and it is slightly annoying.

Something like: APRS devices/software supporting a Long Messages feature 
shall accept message packets of up to 255 bytes. The total length of the 
recipient field, message id, reply-ack id, and the delimiters and packet 
format identifier characeter, must not exceed 255 bytes.

27 bytes (with a message-id, and a reply-ack id):

:N0CALL-14:Hello{msgid}rack

28 bytes (after UTF-8 encoding, "ö" is 2 bytes):

:N0CALL-14:Hellö{msgid}rack

The maximum message payload length, in characters, depends on language and 
the length of the message-IDs. When a user enters a message, the sending 
application shall try encoding the message, taking into account the 
maximum length of the message-ID which may be used, and limit the message 
length accordingly.

If a very long message is split into multiple APRS messages, care must be 
taken to perform the splitting on a character boundary, or a word 
boundary. If splitting would be done at an arbitrary byte offset, a 
multibyte Unicode character could be broken into multiple messages, 
preventing UTF-8 decoding.

Then we can add a field in the APRS device identification database [1] to 
mark devices supporting Long Messages, and other software using the 
database will know that the recipient will accept them.  It won't have 
backwards compatibility for older versions of such devices which do not 
yet support Long Messages, when a newer version does, but I suppose we can 
live with that. Just upgrade the thing.

Alternatively, we'd have to somehow do in-band signaling of support for 
this feature, perhaps by abusing the message-id contents somehow, and it'd 
only enable long messages after the first message. And still there would 
be some risk that it'd get enabled accidentally for a recipient which 
doesn't accept them.

[1]: https://github.com/hessu/aprs-deviceid

   - Hessu