[aprssig] APRS Message Callsign SPEC- Ambiguity (ACKS still work)

[spam8mybrain]

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.
Andrew, KA2DDO 

-------- Original message --------
From: Robert Bruninga via aprssig <aprssig at tapr.org> 
Date: 04/26/2016  5:35 PM  (GMT-05:00) 
To: TAPR APRS Mailing List <aprssig at tapr.org> 
Subject: Re: [aprssig] APRS Message Callsign SPEC- Ambiguity (ACKS still	work) 

Hummh….. 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. Or am I missing something?Bob, WB4aPR From: aprssig [mailto:aprssig-bounces at tapr.org] On Behalf Of spam8mybrain via aprssig
Sent: Tuesday, April 26, 2016 2:36 PM
To: Lynn W. Deffenbaugh (Mr); TAPR APRS Mailing List
Subject: Re: [aprssig] APRS Message Callsign SPEC- Ambiguity 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. The issue here is whether any given ground client can send to a mixed-case addressee. Andrew, KA2DDO author of YAAC 

-------- Original message --------
From: "Lynn W. Deffenbaugh (Mr) via aprssig" <aprssig at tapr.org> 
Date: 04/25/2016 9:56 PM (GMT-05:00) 
To: TAPR APRS Mailing List <aprssig at tapr.org> 
Subject: Re: [aprssig] APRS Message Callsign SPEC- Ambiguity 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.

APRSISCE/32 upcases APRS message targets.  At least I think it does but I didn't check the source code just now.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 4/25/2016 5:07 PM, Robert Bruninga via aprssig wrote:There is an unintended ambiguity in the APRS SPEC regarding the addressee in the APRS MESSAGE format. 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. STATION names, OBJECT names, ITEM names were intended to be a general 9 character mixed case field in APRS padded to 9 with spaces. We just noticed that some radios do not allow sending an APRS message to a mixed case address. 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. I wont make this mistake in any future satellite, but we are stuck with it.   SO, we might ought-to-identify all APRS radios and APRS clients that have this uppercase-only restriction on MESSAGE Callsigns. I can say the Kenwoods have it.  Others? See http://aprs.org/aprs11.html and specifically, see:See http://aprs.org/aprs11/aprs-names-and-spaces.txt Bob, WB4APR


_______________________________________________aprssig mailing listaprssig at tapr.orghttp://www.tapr.org/mailman/listinfo/aprssig 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20160426/b736afdb/attachment.html>