[aprssig] APRS Message Callsign SPEC- Ambiguity (ACKS still work)

[Robert Bruninga]

Hummh…..



This is true.  If somehow my client thinks its name is “WB4APRlid” and it
sees an APRS message to “WB4APRlid” (from anyone), then it will send an ACK
from whatever my TNC callsign happens to be to whatever the sender’s TNC
call happened to be.  And the format of the ACK does not involve the
“WB4APRlid”  at all.  The ACK still works.



Or am I missing something?

Bob, WB4aPR



*From:* aprssig [mailto:aprssig-bounces at tapr.org] *On Behalf Of *spam8mybrain
via aprssig
*Sent:* Tuesday, April 26, 2016 2:36 PM
*To:* Lynn W. Deffenbaugh (Mr); TAPR APRS Mailing List
*Subject:* Re: [aprssig] APRS Message Callsign SPEC- Ambiguity



One interesting point here is that RF stations wouldn't have to ack
messages from this mixed-case service; the mixed-case service will have to
ack messages from the RF ground station. So that's not an issue.



The issue here is whether any given ground client can send to a mixed-case
addressee.



Andrew, KA2DDO

author of YAAC



-------- Original message --------
From: "Lynn W. Deffenbaugh (Mr) via aprssig" <aprssig at tapr.org>
Date: 04/25/2016 9:56 PM (GMT-05:00)
To: TAPR APRS Mailing List <aprssig at tapr.org>
Subject: Re: [aprssig] APRS Message Callsign SPEC- Ambiguity

Yaesu APRS radios will not ack a message if it comes from an -SSID that is
not -0 (suppressed) through -15 even though the APRS protocol for messages
is always in the payload portion for 3rd party packets gated from the
APRS-IS to RF with the ack coming back.

APRSISCE/32 upcases APRS message targets.  At least I think it does but I
didn't check the source code just now.

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

On 4/25/2016 5:07 PM, Robert Bruninga via aprssig wrote:

There is an unintended ambiguity in the APRS SPEC regarding the addressee
in the APRS MESSAGE format.



It was intended that the TOCALL of any transmitted message could be sent to
ANY 9 character callsign field and this included mixed-case.  Although
TNC’s have historically forced callsigns to UPEPRCASE only, this is only a
limitation of TNC’s and was not intended to be a limitation of APRS.



STATION names, OBJECT names, ITEM names were intended to be a general 9
character mixed case field in APRS padded to 9 with spaces.



We just noticed that some radios do not allow sending an APRS message to a
mixed case address.



Unfortunately, the QIKCOM-2 satellite which does DTMF-to-Voice and
APRS-to-voice has a special message address of “QIKCOMsay” for all messages
it is expected to speak.  So some people will not be able to exercise this
text-to-voice messaging capability.



I wont make this mistake in any future satellite, but we are stuck with
it.



SO, we might ought-to-identify all APRS radios and APRS clients that have
this uppercase-only restriction on MESSAGE Callsigns.



I can say the Kenwoods have it.  Others?



See http://aprs.org/aprs11.html and specifically, see:

See http://aprs.org/aprs11/aprs-names-and-spaces.txt



Bob, WB4APR




_______________________________________________

aprssig mailing list

aprssig at tapr.org

http://www.tapr.org/mailman/listinfo/aprssig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20160426/7ba5cf6c/attachment.html>