<div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">- Wes W8WJB </div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 25, 2021 at 14:55 Robert Bruninga <<a href="mailto:bruninga@usna.edu">bruninga@usna.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The spec says that BLNx and ANNx are supposed to be captured and displayed<br>
in sdequence of the "x" character.. Also that new incoming BLNx should<br>
overwrite previous BLNx lines. This allows BLNs and ANNs to be displayed<br>
in paragraph form.<br>
<br>
Almost NO client implemented it that way.<br>
aBob<br>
<br>
On Thu, Nov 25, 2021 at 11:23 AM Kenneth Finnegan<br>
<<a href="mailto:kennethfinnegan2007@gmail.com" target="_blank">kennethfinnegan2007@gmail.com</a>> wrote:<br>
><br>
> On Thu, Nov 25, 2021 at 7:52 AM Robert Bruninga <<a href="mailto:bruninga@usna.edu" target="_blank">bruninga@usna.edu</a>> wrote:<br>
>><br>
>> APRS messaging was designed for single line AND paragraph messaging.<br>
>> Just sent multiple lines that are NUMBERED and the APRS client on receipt<br>
>> is supposed to store them in sequence.<br>
><br>
><br>
> What? Where does the APRS spec ever say that clients are supposed to store messages in a particular sequence?<br>
><br>
> Do you mean for messages with message identifiers, or just messages with numbers at the beginning of each line?<br>
><br>
> --<br>
> Kenneth Finnegan<br>
> <a href="http://blog.thelifeofkenneth.com/" rel="noreferrer" target="_blank">http://blog.thelifeofkenneth.com/</a><br>
><br>
><br>
> On Thu, Nov 25, 2021 at 7:52 AM Robert Bruninga <<a href="mailto:bruninga@usna.edu" target="_blank">bruninga@usna.edu</a>> wrote:<br>
>><br>
>> The problem is the 50,000 Kenwoods and Yaesu APRS radios that<br>
>> could not display these messages.<br>
>><br>
>> APRS messaging was designed for single line AND paragraph messaging.<br>
>> Just sent multiple lines that are NUMBERED and the APRS client on receipt<br>
>> is supposed to store them in sequence. This is certainly supposed to work<br>
>> for Builletins and Announcements. BLN1, BLN2, BLN3 etgc...<br>
>> Not sure if it works for messages with line numbers<br>
>> bob wb4apr<br>
>> On Wed, Nov 24, 2021 at 3:43 PM Heikki Hannikainen <<a href="mailto:hessu@hes.iki.fi" target="_blank">hessu@hes.iki.fi</a>> wrote:<br>
>> ><br>
>> > On Sun, 21 Nov 2021, Kenneth Finnegan wrote:<br>
>> ><br>
>> > > 3. Sharing the same TX delay for multi-line messages or bulletins<br>
>> > > because the message length limit is so ungodly short because of the IBM<br>
>> > > PC screen width limits<br>
>> ><br>
>> > This is actually something I'd like to improve a bit. The limit indeed is<br>
>> > way too short, and we should figure a way to increase it for modern<br>
>> > software without breaking a lot of things. I bump into the limit every<br>
>> > time I do messaging and it is slightly annoying.<br>
>> ><br>
>> > Something like: APRS devices/software supporting a Long Messages feature<br>
>> > shall accept message packets of up to 255 bytes. The total length of the<br>
>> > recipient field, message id, reply-ack id, and the delimiters and packet<br>
>> > format identifier characeter, must not exceed 255 bytes.<br>
>> ><br>
>> > 27 bytes (with a message-id, and a reply-ack id):<br>
>> ><br>
>> > :N0CALL-14:Hello{msgid}rack<br>
>> ><br>
>> > 28 bytes (after UTF-8 encoding, "ö" is 2 bytes):<br>
>> ><br>
>> > :N0CALL-14:Hellö{msgid}rack<br>
>> ><br>
>> > The maximum message payload length, in characters, depends on language and<br>
>> > the length of the message-IDs. When a user enters a message, the sending<br>
>> > application shall try encoding the message, taking into account the<br>
>> > maximum length of the message-ID which may be used, and limit the message<br>
>> > length accordingly.<br>
>> ><br>
>> > If a very long message is split into multiple APRS messages, care must be<br>
>> > taken to perform the splitting on a character boundary, or a word<br>
>> > boundary. If splitting would be done at an arbitrary byte offset, a<br>
>> > multibyte Unicode character could be broken into multiple messages,<br>
>> > preventing UTF-8 decoding.<br>
>> ><br>
>> > Then we can add a field in the APRS device identification database [1] to<br>
>> > mark devices supporting Long Messages, and other software using the<br>
>> > database will know that the recipient will accept them. It won't have<br>
>> > backwards compatibility for older versions of such devices which do not<br>
>> > yet support Long Messages, when a newer version does, but I suppose we can<br>
>> > live with that. Just upgrade the thing.<br>
>> ><br>
>> > Alternatively, we'd have to somehow do in-band signaling of support for<br>
>> > this feature, perhaps by abusing the message-id contents somehow, and it'd<br>
>> > only enable long messages after the first message. And still there would<br>
>> > be some risk that it'd get enabled accidentally for a recipient which<br>
>> > doesn't accept them.<br>
>> ><br>
>> > [1]: <a href="https://github.com/hessu/aprs-deviceid" rel="noreferrer" target="_blank">https://github.com/hessu/aprs-deviceid</a><br>
>> ><br>
>> > - Hessu<br>
>> > _______________________________________________<br>
>> > aprssig mailing list<br>
>> > <a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
>> > <a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
>><br>
>> _______________________________________________<br>
>> aprssig mailing list<br>
>> <a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
>> <a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
<br>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote></div></div>