[aprssig] Reply-Ack Spec vs }AA

Sun Nov 6 09:28:11 EST 2011

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

---- Original message ----
>Date: Sun, 06 Nov 2011 08:50:30 -0500
>From: aprssig-bounces at tapr.org (on behalf of "Lynn W. Deffenbaugh (Mr)" <ldeffenb at homeside.to>)
>Subject: [aprssig] Reply-Ack Spec vs }AA  
>To: TAPR APRS Mailing List <aprssig at tapr.org>
>
>   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> 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
>________________
>_______________________________________________
>aprssig mailing list
>aprssig at tapr.org
>https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig