<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>No, Pete was correct and I was in error. Because the ack would be coming from your callsign, it would not match the addressee the original client sent to, so the ack would not complete the message transmission and retries would still occur to the client's retry limit.<div><br></div><div>Andrew, KA2DDO </div><br><br>-------- Original message --------<br>From: Robert Bruninga via aprssig <aprssig@tapr.org> <br>Date: 04/26/2016 5:35 PM (GMT-05:00) <br>To: TAPR APRS Mailing List <aprssig@tapr.org> <br>Subject: Re: [aprssig] APRS Message Callsign SPEC- Ambiguity (ACKS still work) <br><br><div class="WordSection1"><p class="MsoNormal"><span style="color:#1f497d">Hummh…..</span></p><p class="MsoNormal"><span style="color:#1f497d"> </span></p><p class="MsoNormal"><span style="color:#1f497d">This is true. If somehow my client thinks its name is “WB4APRlid” and it sees an APRS message to “WB4APRlid” (from anyone), then it will send an ACK from whatever my TNC callsign happens to be to whatever the sender’s TNC call happened to be. And the format of the ACK does not involve the “WB4APRlid” at all. The ACK still works.</span></p><p class="MsoNormal"><span style="color:#1f497d"> </span></p><p class="MsoNormal"><span style="color:#1f497d">Or am I missing something?</span></p><p class="MsoNormal"><span style="color:#1f497d">Bob, WB4aPR</span></p><p class="MsoNormal"><span style="color:#1f497d"> </span></p><div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> aprssig [mailto:<a href="mailto:aprssig-bounces@tapr.org">aprssig-bounces@tapr.org</a>] <b>On Behalf Of </b>spam8mybrain via aprssig<br><b>Sent:</b> Tuesday, April 26, 2016 2:36 PM<br><b>To:</b> Lynn W. Deffenbaugh (Mr); TAPR APRS Mailing List<br><b>Subject:</b> Re: [aprssig] APRS Message Callsign SPEC- Ambiguity</span></p></div></div><p class="MsoNormal"> </p><p class="MsoNormal">One interesting point here is that RF stations wouldn't have to ack messages from this mixed-case service; the mixed-case service will have to ack messages from the RF ground station. So that's not an issue.</p><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">The issue here is whether any given ground client can send to a mixed-case addressee.</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Andrew, KA2DDO </p></div><div><p class="MsoNormal">author of YAAC </p></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br><br>-------- Original message --------<br>From: "Lynn W. Deffenbaugh (Mr) via aprssig" <<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>> <br>Date: 04/25/2016 9:56 PM (GMT-05:00) <br>To: TAPR APRS Mailing List <<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>> <br>Subject: Re: [aprssig] APRS Message Callsign SPEC- Ambiguity </p><div><p class="MsoNormal">Yaesu APRS radios will not ack a message if it comes from an -SSID that is not -0 (suppressed) through -15 even though the APRS protocol for messages is always in the payload portion for 3rd party packets gated from the APRS-IS to RF with the ack coming back.<br><br>APRSISCE/32 upcases APRS message targets. At least I think it does but I didn't check the source code just now.<br><br>Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br><br>On 4/25/2016 5:07 PM, Robert Bruninga via aprssig wrote:</p></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><p class="MsoNormal">There is an unintended ambiguity in the APRS SPEC regarding the addressee in the APRS MESSAGE format.</p><p class="MsoNormal"> </p><p class="MsoNormal">It was intended that the TOCALL of any transmitted message could be sent to ANY 9 character callsign field and this included mixed-case. Although TNC’s have historically forced callsigns to UPEPRCASE only, this is only a limitation of TNC’s and was not intended to be a limitation of APRS.</p><p class="MsoNormal"> </p><p class="MsoNormal">STATION names, OBJECT names, ITEM names were intended to be a general 9 character mixed case field in APRS padded to 9 with spaces.</p><p class="MsoNormal"> </p><p class="MsoNormal">We just noticed that some radios do not allow sending an APRS message to a mixed case address.</p><p class="MsoNormal"> </p><p class="MsoNormal">Unfortunately, the QIKCOM-2 satellite which does DTMF-to-Voice and APRS-to-voice has a special message address of “QIKCOMsay” for all messages it is expected to speak. So some people will not be able to exercise this text-to-voice messaging capability.</p><p class="MsoNormal"> </p><p class="MsoNormal">I wont make this mistake in any future satellite, but we are stuck with it. </p><p class="MsoNormal"> </p><p class="MsoNormal">SO, we might ought-to-identify all APRS radios and APRS clients that have this uppercase-only restriction on MESSAGE Callsigns.</p><p class="MsoNormal"> </p><p class="MsoNormal">I can say the Kenwoods have it. Others?</p><p class="MsoNormal"> </p><p class="MsoNormal">See <a href="http://aprs.org/aprs11.html">http://aprs.org/aprs11.html</a> and specifically, see:</p><p class="MsoNormal">See <a href="http://aprs.org/aprs11/aprs-names-and-spaces.txt">http://aprs.org/aprs11/aprs-names-and-spaces.txt</a></p><p class="MsoNormal"> </p><p class="MsoNormal">Bob, WB4APR</p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><br><br><br></span></p><pre>_______________________________________________</pre><pre>aprssig mailing list</pre><pre><a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a></pre><pre><a href="http://www.tapr.org/mailman/listinfo/aprssig">http://www.tapr.org/mailman/listinfo/aprssig</a></pre></blockquote><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span></p></div></body></html>