Does anyone know where the PinPoint APRS author can be reached?  I suspect that package doesn't properly support Reply-Acks in APRS messages.

http://www.aprs.org/aprs11/replyacks.txt

Consider the following message interchange that I just had between APRSIS32 and PinPoint APRS via RobustPacket on 30m:

2021-01-20 16:22:38 EST: WB8SKP-13>APIN20,WIDE1-1,qAR,VE4KLM::KJ4ERJ   :Hello test.{1
2021-01-20 16:22:38 EST: KJ4ERJ>APWW11,TCPIP*,qAC,NINTH::WB8SKP-13:ack1

2021-01-20 16:23:08 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Greetings{HR}
2021-01-20 16:23:08 EST: WB8SKP-13>APIN20,TCPIP*,qAC,T2CAWEST::KJ4ERJ   :ack
2021-01-20 16:23:40 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Greetings{HR}
2021-01-20 16:24:13 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Greetings{HR}
2021-01-20 16:25:17 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Greetings{HR}

2021-01-20 16:25:59 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Pinpoint acks are broken{HS}
2021-01-20 16:25:59 EST: WB8SKP-13>APIN20,TCPIP*,qAC,T2CAWEST::KJ4ERJ   :ack [Duplicate message content]
2021-01-20 16:26:31 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Pinpoint acks are broken{HS}
2021-01-20 16:27:03 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Pinpoint acks are broken{HS}


2021-01-20 16:27:07 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:They don't support Reply-Acks{HT}
2021-01-20 16:27:07 EST: WB8SKP-13>APIN20,TCPIP*,qAC,T2CAWEST::KJ4ERJ   :ack [Duplicate message content]
2021-01-20 16:27:40 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:They don't support Reply-Acks{HT}
2021-01-20 16:28:12 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:They don't support Reply-Acks{HT}

2021-01-20 16:28:40 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:which are non-numeric{HU}
2021-01-20 16:29:14 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:which are non-numeric{HU}
2021-01-20 16:29:47 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:which are non-numeric{HU}
2021-01-20 16:30:52 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:which are non-numeric{HU}

PinPoint is apparently only acking the first reception of a message where the base APRS spec says that ALL receptions should be ack'd.  The reason for this is, even though the destination received the message and issued the ack, the ack may not get back to the source which will then retry the original message resulting in a duplicate message at the destination.  This duplicate MUST be acked in the hopes that eventually the ack gets through to the source which will then quit retrying the message.  In my case, I manually aborted the retries on each message once I was certain it was received on the destination.

Also, notice that PinPoint's acks are missing the sequence "number".  Well, it was called a "number" in the original spec, but was not constrained to be "numeric".  The subsequent Reply-Ack extension took advantage of that by using alpha-numeric and } in the (up to) 5 characters of the ack "sequence".  Because the ack wasn't complete, my station continued to retry the message which, as mentioned above SHOULD have triggered additional acks, even though they would have been incorrect.

WB8SKP-13 then switched to YAAC which gave the following, correct, trace.

2021-01-20 16:32:29 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:which are non-numeric{HU}
2021-01-20 16:32:37 EST: WB8SKP-13>APJYC1,qAR,KB1EJH::KJ4ERJ   :ackHU}

2021-01-20 16:34:21 EST: WB8SKP-13>APJYC1,TEMP1-1,qAR,WA7GMX-1::KJ4ERJ   :OK. Now using YAAC.{M0001
2021-01-20 16:34:21 EST: KJ4ERJ>APWW11,TCPIP*,qAC,NINTH::WB8SKP-13:ackM0001

2021-01-20 16:35:00 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:This should work better.{HV}
2021-01-20 16:35:08 EST: WB8SKP-13>APJYC1,qAR,KB1EJH::KJ4ERJ   :ackHV}

2021-01-20 16:35:17 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Yep, I got a valid ack for that one!{HW}

2021-01-20 16:35:19 EST: WB8SKP-13>APJYC1,TEMP1-1,qAR,WA7GMX-1::KJ4ERJ   :OK. Now using YAAC.{M0001
2021-01-20 16:35:19 EST: KJ4ERJ>APWW11,TCPIP*,qAC,NINTH::WB8SKP-13:ackM0001

2021-01-20 16:35:52 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Yep, I got a valid ack for that one!{HW}
2021-01-20 16:36:00 EST: WB8SKP-13>APJYC1,qAR,WA7GMX-1::KJ4ERJ   :ackHW}

2021-01-20 16:37:13 EST: WB8SKP-13>APJYC1,TEMP1-1,qAR,KJ4ERJ::KJ4ERJ   :TNX for the help.{M0002
2021-01-20 16:37:13 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:ackM0002

2021-01-20 16:37:17 EST: WB8SKP-13>APJYC1,TEMP1-1,qAR,KB1EJH::KJ4ERJ   :OK. Now using YAAC.{M0001
2021-01-20 16:37:17 EST: KJ4ERJ>APWW11,TCPIP*,qAC,NINTH::WB8SKP-13:ackM0001

2021-01-20 16:37:28 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:I'm writing up the PinPoint issue for aprssig{HX}
2021-01-20 16:38:03 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:I'm writing up the PinPoint issue for aprssig{HX}
2021-01-20 16:38:12 EST: WB8SKP-13>APJYC1,qAR,VE4KLM::KJ4ERJ   :ackHX}

You'll notice that the acks from YAAC correctly include the alphanumeric and } sequence from the message resulting in a much faster exchange without retries.   And YAAC's traditional, although also alphanumeric, sequences (like M0001 and M0002) were properly issued in the return acks.  And even though some messages were duplicated in a retry, acks were correctly issued for the duplicate receptions.

So, if the PinPoint author is not on any of the three addressed groups, please pass this message along to their support channel so that hopefully it's messaging can be fixed.  Reply-Acks don't need to be fully implemented, but whatever "sequence" follows the { in an incoming message, should be copied into the subsequent ack... without modification and such acks should be issued for ALL message receptions, not just the first copy.