[aprssig] Making APRS text messages longer

[Weston Bustraan]

But BLNx and ANNx are intended for multiple recipients. I don’t see
anything in the spec about multi-line messages addressed to a single
station. It would seem like an abuse of the system to attempt to carry on a
conversation with someone using bulletins or announcements.

- Wes W8WJB


On Thu, Nov 25, 2021 at 14:55 Robert Bruninga <bruninga at usna.edu> wrote:

> 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
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20211125/b38d10ba/attachment.html>