[aprssig] APRS Msg Acks and Trailing Spaces

[Lynn W. Deffenbaugh (Mr)]

Greetings APRS experts,

I've got an interesting (to me at least) question that came up after 
observing some APRS message traffic this morning around station SP9UX.  
I saw two apparently duplicate APRS messages that I didn't see as 
duplicates, but aprs.fi did (in the raw log).  Closer investigation 
revealed that one of the transmissions had a trailing space and the 
other did not (thank you Hessu for the hex raw log!).  One pair of such 
packets is included below.

We know that some TNCs add or remove trailing spaces and that some 
digipeaters run those TNCs.  This means that originally trailing spaces 
might be gone and/or additional trailing spaces might be added as 
packets traverse these various paths.  Which brings me to my question 
about APRS Message acks.

Should a trailing space be considered significant or be ignored when 
acking or validating an ack in an APRS message interchange?

If I send a message (which will never have a trailing space after the 
{ack request) and it arrives at the intended recipient, he may see 
"{ack" or "{ack<space".  He is going to (I assume, is there a UI-View 
person that can confirm or deny this) send back EVERYTHING after the { 
that he sees.

Even if he didn't see the space in my message to him, a space may be 
added on the ack's return path, so I might see "ackack", 
"ackack<space>", or even "ackack<space><space>" (ok, I should have used 
characters other than "ack" for my message sequence identifier).  Should 
my aprs program interpret all of these as a valid ack for the 
outstanding message?  Or should it consider the trailing space versions 
to be an ack of a different message and continue retrying the current 
message?

Even better, if I receive a message with a trailing space after {, 
should I include the space in my ack to that station?  Or should I send 
out multiple acks while steadily removing spaces?

Even worse, if the originating station fully-populates the ack field, or 
uses the new Reply-Acks (http://www.aprs.org/aprs11/replyacks.txt), what 
happens if the addition of one or more trailing spaces makes the { 
appear too early in the message?  {#####<space><space> or 
{MM}AA<space><space> makes the ack request too long and appears to be 
part of the message.

I'm trying to implement a new APRS client that will stand the test of 
time as well as UI-View has, but I need it to be correct for all current 
network behaviors, so I'm asking for your guidance.  My personal opinion 
is to strip trailing blanks off of APRS messages in general, both before 
checking for my received acks and before generating a return ack.  That 
way the { will appear to be in the proper place regardless of what got 
added to the packet along the way.  If there's any client out there that 
is actually putting significant trailing spaces in the {ack field, they 
just won't believe my ackack response.

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


2010-09-02 11:23:36 UTC SP9UX: 63 bytes [Duplicate message ID]
0x00 S P 9 U X > A P U 2 5 N , S R 9 N D X * , W I D E 2 - 1 , q A R
     53503955583e41505532354e2c5352394e44582a2c57494445322d312c714152
0x20 , S R 9 N O Z : : O K 2 U L Q - 1   : s a t   a o 4 0 { 5 4  
     2c5352394e4f5a3a3a4f4b32554c512d31203a73617420616f34307b353420

2010-09-02 11:24:15 UTC SP9UX: 62 bytes [Duplicate message ID]
0x00 S P 9 U X > A P U 2 5 N , S R 9 N D X * , W I D E 2 - 1 , q A R
     53503955583e41505532354e2c5352394e44582a2c57494445322d312c714152
0x20 , S Q 9 L B C : : O K 2 U L Q - 1   : s a t   a o 4 0 { 5 4
     2c5351394c42433a3a4f4b32554c512d31203a73617420616f34307b3534