[aprssig] Reply-Ack Spec vs }AA

[Bob Bruninga]

> and I know I'll be coding APRSISCE/32 to ONLY consider 
> it an }AA if it appears SPECIFICALLY as the 2nd
> from last character 

Yes, that is a valid approach. 

> You may not like them, and they may be hard to 
> arrive at, but documented specs and requirements 
> are necessary if you expect APRS to survive new 
> implementations.

I wish that didn't sound so much like an attack or a complaint.  I try very *very* hard to document EVERY aspect and nuance of APRS whenever something comes up that was not clear, or was omitted from the original spec.  These last few things you have complained about were both attempts on my part to document these nuances.  It seems unfair to complain about undocumented nuances and then complain when we attempt to fix the documentation to accomodate it. 

Further, APRS is not dead like some client programs.  I also make every attempt to evolve the spec to accomodate new ideas.  It is good to have a new author rising to the challenge, but this does require some growing pains.

Bob, Wb4APR

>On 11/6/2011 9:28 AM, Bob Bruninga wrote:
>> Lynn, You are correct, but...
>>
>> But there is nothing in the spec that prevents one from extending it to also look for the reply-ack {06 independent of the line number.
>>
>> To be clear I'd like to see no AA: answer messages in the first place, because only 1 in 100 is of any value and all the rest are just QRM.  But if they are there, this extension at least gives them some value at little expense.
>>
>> But it was a clever idea of Brent's to remark that the AA: could contain a reply ack and not break anything nor impact any existing system.
>>
>> I would be in favor of adding it to the AA: spec.  In other words there is no harm in adding it, and the result is improved forward message performance when an AA: reply results.  The benefit of assisting the ACK process outweighs the added 3 byte load on the nework.
>>
>> Bob, WB4APR