[aprssig] Reply-Ack Spec vs }AA

Sun Nov 6 08:50:30 EST 2011

No, I believe this IS that important.  Can you guide me through your 
interpretation of the Reply-Ack specification from 
http://www.aprs.org/aprs11/replyacks.txt and tell me where you believe 
that it says that a trailing }06 on your AA: example should be 
interpreted as a ReplyAck?  As I read that spec, {MM}AA is a reply ack, 
{MM} is an ack that implies that the ack-issuer is Reply-Ack capable, 
but }AA is just another bit of message text and part of the AA: that 
should display "AA:I'm not here }06" to the recipient.

The } is only a Reply-Ack delimiter when contained within a {seq as far 
as I can see in the spec.

What did I miss here?

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

PS. Sections of the spec that I find particularly relevant:

(Nothing about }AA being anything in particular)
> Original APRS ACK:  {#####<== There were no restrictions on #####
> New 1999 REPLY ACK: {MM}AA<== This embedds ACK in next outgoing msg

(Nothing about standalone }AA, just "embedded")
> COMPATIBILITY:  100% backwards compatible with all code.  The REPLY ACKS
> are embedded in the 5 digit line number.  Old code doesn't care.

(Nothing about "if no ack is needed back, then }AA is used")
> The format for the line number for outgoing message numbers is
> "{MM}AA" where MM is the outgoing message number and AA is the "free ACK"
> if needed.  If no ACK is pending, then the message # is "{MM}".

(Only append AA, not }AA)
> 1) ... But AA is only appended at the INSTANT of transmission.

(Only look for AA in the ack/seq, not }AA in every message)
> 2) RECEIVE messages and look for AA.  IF AA matches the MM of one of your
>     outgoing messages, then consider that message ACKED.

(Buffer with {MM}, not just buffer with } if no ack is needed, the AA 
gets added before transmission, but ONLY if you're buffering an {MM} and 
requesting a corresponding ack)
> 6) Note, that in #1, above, that when the user prepares each message line,
>     that it is buffered up with only the {MM} line number on the end.
>     The AA (if pending) is not attached until the instant that packet is
>     transmitted.

So, where did I miss the spec that would have said something like:
(THIS IS NOT IN THE SPEC!)
Queue non-ack-requesting messages with a trailing } and append any 
pending AA at the instant that packet is transmitted.
(THIS IS NOT IN THE SPEC!)

Oh, and it would probably have also described:
(THIS IS NOT IN THE SPEC!)
A message with just a trailing } indicates that the message sender is 
not requesting an ack for this message, but is indicating that it is 
Reply-Ack capable.
(THIS IS NOT IN THE SPEC!)

Nope, I'm just not seeing either of the above nor anything that 
describes }AA.

On 11/5/2011 9:49 AM, Brent Hildebrand wrote:
> Line numbers are of the form {xx.  Reply/Acks }yy.  A Reply/Ack is not 
> a linenumber and should not be interpreted as such.  Thus, an exchange 
> with one user having AA turned on might look like this:
>
> WB1XYZ>APRS::KK2ABC   :Hello there! {06
> KK2ABC>APRS::WB1XYZ   :ack06
> KK2ABC>APRS::WB1XYZ   :AA:I'm not here }06
>
> There is no line number in the AA message, only a Reply/Ack. If KK2ABC 
> returns to their keyboard and send a reply, the exchange might like 
> like this:
>
> KK2ABC>APRS::WB1XYZ   :I'm back! {02}06
> WB1XYZ>APRS::KK2ABC   :ack02}06
> WB1XYZ>APRS::KK2ABC   :Good to hear from you {07}02
> KK2ABC>APRS::WB1XYZ   :ack07}02
> WB1XYZ>APRS::KK2ABC   :Where have you been? {08}02
> //  KK2ABC leaves again and turns on the AA message...
> KK2ABC>APRS::WB1XYZ   :AA:I'm not here }08
>
> The point is, that a reply/ack can be added to a AA message and it 
> should not be interpreted as a message number because it is not of the 
> form of a message number.
>
> Old client programs, the message number was of the form {xxxxx.  When 
> reply/acks were added to newer programs, they did not break anything.  
> Generating the real "ack" as :ack02}06 is only ack'ing message number 
> 2.  On programs that understand reply/acks, ;ack02 would have been 
> sufficient.  For backward compatibility, the ack included the 
> reply/ack. Putting the reply/ack in the AA does not cause backward 
> compatibility issues because the reply/ack is not in message number 
> format and should not generate a return ack.
>
> OK - I'll disappear again.  This is probably not that important.  BH KH2Z
>
>
> On Sat, Nov 5, 2011 at 5:00 AM, <aprssig-request at tapr.org 
> <mailto:aprssig-request at tapr.org>> wrote:
>
>     Bob's 2) precludes that.  The "ack" request }nn is the same thing
>     as a "Line number" which Bob says that AA's should NOT have.
>
>     Unless you're referring to an APRS client implementation that
>     actually issues such ack requests on it's AA (without the colon)
>     packets?  You didn't give us much context here.
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20111106/800b0138/attachment.html>