<div dir="ltr"><div>So no one on the list really touched on question 1, which I kind of thought was the least open ended, and thus hopefully the most productive. I do have people off-list telling me that there was agreement in the ~2000 time frame to deprecate AEA format completely and the third-party format strictly follows this with no origin routing path:</div><div><span style="font-size:12.8px">}[SRCCALL]>[TNCID],[NETWORKID]</span><wbr style="font-size:12.8px"><span style="font-size:12.8px">,[IGATECALL]*:[PACKET PAYLOAD]</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I'll observe that I'm hazy on how I was supposed to know that. I <i>had</i> checked APRS1.1 and APRS1.2 and saw nothing about third party headers.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">No one proffered any Network Identifiers other than TCPIP, but presumably others are allowed to crop up, which is why the I-gate guidelines with respect to not I-gating third party packets with TCPIP in it are so carefully worded. I know as an I-gate author I certainly hadn't appreciated the importance in properly handling third-party packets from other networks than APRS-IS.</span></div><div><br></div>On Tue, Nov 29, 2016 at 5:48 AM, Jim Alles <span dir="ltr"><<a href="mailto:kb3tbx@gmail.com" target="_blank">kb3tbx@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:georgia,serif">There is this thread:</div><div style="font-family:georgia,serif"><br></div><div style="font-family:georgia,serif"><a href="http://www.tapr.org/pipermail/aprssig/2012-November/040731.html" target="_blank">http://www.tapr.org/pipermail/<wbr>aprssig/2012-November/040731.<wbr>html</a><br></div><div><br></div></div></blockquote><div class="gmail_extra">On Tue, Nov 29, 2016 at 4:03 AM, Jim Alles <span dir="ltr"><<a href="mailto:kb3tbx@gmail.com" target="_blank">kb3tbx@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px"><br></span></div><div style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px">#3, and 5: see <a href="http://www.tapr.org/pipermail/aprssig/2008-November/027554.html" target="_blank">http://www.tapr.org/<wbr>pipermail/aprssig/2008-<wbr>November/027554.html</a></span></div><div><br></div></div></blockquote><div><br></div><div>D7: 45 characters</div><div>D700: 64 characters</div><div>VX8R: maybe 80 characters</div><div><br></div><div>None of those are 67. It makes an argument that we aren't that beholden to 67 anyways, but I won't die on that hill.</div><div> </div><div>On Tue, Nov 29, 2016 at 5:44 AM, Robert Bruninga <span dir="ltr"><<a href="mailto:bruninga@usna.edu" target="_blank">bruninga@usna.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_2575845735045681227WordSection1"><span class="gmail-"><div><span style="font-size:9.5pt">7. Where did this 67 character limit on messages come from?</span><br></div><div><p class="MsoNormal"><span style="font-family:georgia,serif"></span></p></div></span><div><p class="MsoNormal"><span style="font-family:georgia,serif;color:rgb(31,73,125)"> </span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">What’s left on an 80 character line (PC AT) after displaying date/time and callsign.</span></p></div></div></div></blockquote></div><div><br></div><div>That is a really satisfying answer. Thank you.</div><div><br></div><div>On Tue, Nov 29, 2016 at 5:55 AM, Robert Bruninga <span dir="ltr"><<a href="mailto:bruninga@usna.edu" target="_blank">bruninga@usna.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Because the probability of delivery success for a 214 long packet is only<br>30% of the shorter 67 byte packet.  Unacceptable.<br><br>APRS was designed for short packets to keep the channel more reliable for<br>everyone.</blockquote><div><br></div><div>67 is in fact 30% of 214, but that's ignoring all the over-heads on top of APRS which move this size difference to more like 40%. Regardless, this argument implicitly uses a Poisson error model which a lot of people didn't seem to much appreciate in my thesis. I do get your point though.</div></div><div><br></div><div>In any case, <i>absolutely</i> APRS is best enjoyed with short packets; everyone should always prefer shorter packets to longer packets. My concern is that when you bake in restrictions like 23 bytes for the project title of a tracker, some software authors disregard those prohibitive limits while others depend on them. Just because you loosen the MTU doesn't mean people will make their packets bigger. Then again, it seems like some people are running their packets longer regardless of the limits... I'm clearly coming 20 years late to this party, so I just need to come to terms with that.</div><div><br></div><div>On Tue, Nov 29, 2016 at 6:41 AM, Lynn W. Deffenbaugh (Mr) <span dir="ltr"><<a href="mailto:ldeffenb@homeside.to" target="_blank">ldeffenb@homeside.to</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is why APRSISCE/32 allows the entry of longer messages to send, but internally word-wraps them to fit within the max message limit.  They are then queued to send back-to-back, but only as acks are recevied providing a throttle of sorts.  You might have to be quick to read the entire multi-line message as it is received on an APRS radio's small screen, but it works.<br><br></blockquote><div>I think this is really the right type of answer! I guess in some ways I'm more annoyed by the sub-par user experience of where the text box just stops working on many software packages than the actual 67 byte L4 MTU.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As for multi-byte characters, I'm not at all sure any more if I handle splitting those properly/safely or if I just split bytes. I'll confess that I don't even know enough about them to even formulate and execute a test.</blockquote></div><div><br></div><div>So let's speculate on the best way to split multi-packet text messages here:</div><div>Breaking on 0x20 space characters is safe, so start at byte 68 and scan left for some distance looking for 0x20.</div><div>If that fails and you need to break in the middle of a word, you start at the 68th byte and scan left for the first byte with the most significant bit not set (0xxxxxxx - normal ASCII), or the first byte with both the 7th and 6th bit set (11xxxxxx - Start of a UTF-8 encoding.)</div><div><br></div><div>UTF-8 is pretty slick how it's self-synchronizing. The first byte of every extended code point starts with 11xxxxxx, and every follow-on byte starts with 10xxxxxx.</div><div><br></div><div>There's also the consideration of adding SMS / Twitter rant style 1/3, 2/3, 3/3 at the end of each sub-divided packet.</div><div><br></div><div>And trust me, the irony that I'm speculating here on how to improve your software's messaging behavior when Aprx still has an open ticket for not having <i>any</i> messaging capability is not lost on me.</div><div><br></div><div>On Tue, Nov 29, 2016 at 10:00 AM, SARTrack Admin <span dir="ltr"><<a href="mailto:info@sartrack.co.nz" target="_blank">info@sartrack.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Some years ago, when I changed my old compiler for a new one which uses Unicode strings...</blockquote><div><br></div><div>Seriously, just go back and read Bart's email again; all good points. That's really unfortunate that AGWTracker doesn't use UTF-8; the rest of us seem to be standardizing on that.</div></div><div><br></div><div>We do seem to have many applications which are limiting to 67 *characters* instead of 67 bytes, so which one is it? Because you need 268 bytes to be able to guarantee storing 67 characters... </div><div><br></div><div>Hint: I think the right answer is 67 <b>bytes</b> per message, and I think it would be good for applications to handle that cut-off better than to just stop responding to key presses, be it via line breaks or Twitter-esque feedback on length limits.</div><div><br></div><div><br></div><div>I am also getting reports of devices known to go catatonic when they receive long packets. That is pretty silly, so I'd like to get on my soap box and encourage my fellow developers (in all of our free time) to spend some time either actively testing or at least pondering their software's behavior when it receives unusual or illegal packets:</div><div> * Messages with extended character sets. Send a message to "UTF-8" and see what comes back!</div><div> * Messages with fields grossly exceeding their length limits. A good place to look for inspiration here is the aprsc test suite: <a href="https://github.com/hessu/aprsc/tree/master/tests/t">https://github.com/hessu/aprsc/tree/master/tests/t</a></div><div>Regardless of who's in the right, if you're using a 70 byte fixed width field to save CPU cycles in 2016, you need to gracefully recover from when you get a 73 byte payload off the wire.</div><div><br></div><div>As always, thanks for all the thoughts and input folks.</div><div><br></div><div><div class="gmail_signature">--<br>Kenneth Finnegan, W6KWF<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a></div></div>
<div class="gmail_quote"><br></div></div></div>