[aprssig] Making APRS text messages longer

[Robert Bruninga]

The spec says that BLNx and ANNx are supposed to be captured and displayed
in sdequence of the "x" character..  Also that new incoming BLNx should
overwrite previous BLNx lines.  This allows BLNs and ANNs to be displayed
in paragraph form.

Almost NO client implemented it that way.
aBob

On Thu, Nov 25, 2021 at 11:23 AM Kenneth Finnegan
<kennethfinnegan2007 at gmail.com> wrote:
>
> On Thu, Nov 25, 2021 at 7:52 AM Robert Bruninga <bruninga at usna.edu> wrote:
>>
>> 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.
>
>
> What? Where does the APRS spec ever say that clients are supposed to store messages in a particular sequence?
>
> Do you mean for messages with message identifiers, or just messages with numbers at the beginning of each line?
>
> --
> Kenneth Finnegan
> http://blog.thelifeofkenneth.com/
>
>
> On Thu, Nov 25, 2021 at 7:52 AM Robert Bruninga <bruninga at usna.edu> wrote:
>>
>> 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
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org