[aprssig] Making APRS text messages longer

[Robert Bruninga]

The problem is the 50,000 Kenwoods and Yaesu APRS radios that
could not display these messages.

APRS messaging was designed for single line AND paragraph messaging.
Just sent multiple lines that are NUMBERED and the APRS client on receipt
is supposed to store them in sequence.  This is certainly supposed to work
for Builletins and Announcements.  BLN1, BLN2, BLN3 etgc...
 Not sure if it works for messages with line numbers
bob wb4apr
On Wed, Nov 24, 2021 at 3:43 PM Heikki Hannikainen <hessu at hes.iki.fi> wrote:
>
> 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
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org