<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2/15/2024 4:15 PM, Jose Alberto
Nieto Ros wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DB9PR10MB578633CA521A8E6658050DCAD84D2@DB9PR10MB5786.EURPRD10.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">I
understand your concern but I don't share your opinion at all.
If VARA is the source then i can use APVARA, but if the source
is PinPoint connected to VARA, then i have to use APPIN20. OK,
then, must i to build an APRS client embedded in VARA Modem
(Like JS8CALL) to send a Position Report as "APVARA" having
specific applications (like Pinpoint) for it ? Has no sense</span></blockquote>
<p><br>
</p>
<p>The applicant for APVARA indicated that the VARA HF modem is
dropping the client's ToCall when transmitting packets over RF and
then substituting APVARA at the receiving end. The connected
client at the receiving end then gates this incorrectly
substituted packet to the APRS-IS resulting in the issue.</p>
<p><br>
</p>
<p>The destination callsign, aka ToCall, is designed to represent
the SOURCE of the packet, not the MODEM over which a packet may
have been transmitted. If you actually implement a full APRS
client, then yes, by all means you can use APVARA as the ToCall.
But if VARA HF is actually just a modem, and not the originator of
a packet, then the entire packet, including an unmodified
destination callsign/ToCall is expected to be transmitted and
received intact by all receiving stations.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:DB9PR10MB578633CA521A8E6658050DCAD84D2@DB9PR10MB5786.EURPRD10.PROD.OUTLOOK.COM">
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><i> If
the destination callsign is considered "unnecessary", then
who is to say that comment strings, altitudes,
speed/direction, or other various APRS packet components
won't be dropped in the future to "save RF time" by some
particular protocol.</i></span></div>
<div><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">Do
you really consider destination callsign to be equally
important as comment strings, altitudes, speed/direction.... ?</span></div>
</blockquote>
<p>Yes, I consider all specified portions of an APRS packet to be
equally important. None of them should be modified according to
the specifications, beyond the provision that an IGate is supposed
to insert a q-Construct at the end of the path. If a packet is
formatted at the source, then that same unmodified packet should
be received at the destination. The over-the-air format is up to
the modem and the RF protocol, but the APRS packet format should
not be modified from end to the other.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:DB9PR10MB578633CA521A8E6658050DCAD84D2@DB9PR10MB5786.EURPRD10.PROD.OUTLOOK.COM">
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">and
do you consider someone are going to drop in his protocol
comment strings, altitudes, speed/direction, or other various
APRS packet components, when is the user who decides what he
want to include or not in their frames?</span></div>
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">We
are mixing pears with apples</span></div>
</blockquote>
<p><br>
</p>
<p>Nope, all components of the APRS packet are equal. You are
correct that the user decides what to include in the frame. And
the user of specific APRS client software, by that choice of
software, is choosing what ToCall the packets should contain. It
is not up to other software to replace any component of that APRS
packet, or that other software is not "APRS" any longer.</p>
<p><br>
</p>
<p>Lynn (D) - KJ4ERJ - APRS Foundation - Ensuring the Future of APRS<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:DB9PR10MB578633CA521A8E6658050DCAD84D2@DB9PR10MB5786.EURPRD10.PROD.OUTLOOK.COM">
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">sincerely</span></div>
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">Jose</span></div>
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">EA5HVK</span></div>
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 18.6667px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br>
</span></div>
<div class="elementToProof"><span
style="font-family: Calibri, Helvetica, sans-serif; font-size: 18.6667px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br>
</span></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>De:</b> Lynn W.
Deffenbaugh (Mr) <a class="moz-txt-link-rfc2396E" href="mailto:KJ4ERJ@homeside.to"><KJ4ERJ@homeside.to></a><br>
<b>Enviado:</b> jueves, 15 de febrero de 2024 20:40<br>
<b>Para:</b> <a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:aprssig@lists.tapr.org"><aprssig@lists.tapr.org></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:mike.ph4@gmail.com">mike.ph4@gmail.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:mike.ph4@gmail.com"><mike.ph4@gmail.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:nietoros@hotmail.com">nietoros@hotmail.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:nietoros@hotmail.com"><nietoros@hotmail.com></a><br>
<b>Asunto:</b> Re: [aprssig] VARA modem replacing APRS tocall</font>
<div> </div>
</div>
<div>
<div class="x_moz-cite-prefix">First, I hope both Michael Phelps
NA7Q (the person raising the issue) and Jose Alberto Nieto Ros
EA5HVK (apparently the VARA HF author) are members here on the
aprssig. This is the definitive venue to discuss APRS and
APRS-IS implementation issues and questions.<br>
</div>
<div class="x_moz-cite-prefix"><br>
</div>
<div class="x_moz-cite-prefix">I concur that this is very bad
practice and 100% non-APRS-IS-spec compliant. To quote the
specification from
<a class="x_moz-txt-link-freetext moz-txt-link-freetext"
href="https://aprs-is.net/IGating.aspx"
moz-do-not-send="true">https://aprs-is.net/IGating.aspx</a><br>
</div>
<div class="x_moz-cite-prefix"><br>
</div>
<div class="x_moz-cite-prefix">
<blockquote type="cite"><span
style="color:rgb(101,109,118); font-size:14px; font-style:normal; font-variant-ligatures:normal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; orphans:2; text-align:start; text-indent:0px; text-transform:none; widows:2; word-spacing:0px; white-space:normal; background-color:rgb(255,255,255); text-decoration-style:initial; text-decoration-color:initial; display:inline!important; float:none"><b>No
modification of the TNC2 format line should be made</b>
except to add ,qAR,IGATECALL to the end of the path (and
the third-party exception noted above). IGATECALL is the
callsign-SSID of the IGate and denotes the point of entry
for the packet.</span></blockquote>
Specifications exist to ensure compatibility across
independent implementations. The so-called "ToCall" (actually
the AX.25 destination address) is defined in the APRS101.pdf
specification to contain (page 13) one of the following:<br>
<br>
The AX.25 Destination Address field can contain 6 different
types of APRS information:<br>
• A generic APRS address.<br>
• A generic APRS address with a symbol.<br>
• An APRS software version number.<br>
• Mic-E encoded data.<br>
• A Maidenhead Grid Locator (obsolete).<br>
• An Alternate Net (ALTNET) address.<br>
<br>
Each of these is further detailed in the following sections of
chapter 4. While it may not be explicitly stated, the ToCall
is assigned by the originator of the packet. So, if VARA HF is
SOURCING the packets, then using >APVARA would fit within
the specifications. However, in this case the VARA HF modem
is choosing to not transmit the ToCall to save a few bytes
over RF. However, this constitutes a loss important data from
the original packet and a non-compliant modification of the
original client APRS packet.</div>
<div class="x_moz-cite-prefix"><br>
</div>
<div class="x_moz-cite-prefix">There are many tools that use the
packet destination address (ToCall) to identify the type of
station that originated the packet. This is used to identify
client station capabilities (messaging-capable, for instance)
as well as to identify client hard/firm/software that may be
generating non-compliant packets. This is the reason behind
the IGate specifications. IGates are responsible for relaying
the actual received packets, without modifications, to the
APRS-IS. To do otherwise is to invite chaos into the system.<br>
<br>
IMHO, the loss of the originating client identity (or worse, a
conflicting indication of the client identity if the original
packet is delivered to the APRS-IS outside of VARA HF) is not
worth the savings of a short bit of RF time. If the
destination callsign is considered "unnecessary", then who is
to say that comment strings, altitudes, speed/direction, or
other various APRS packet components won't be dropped in the
future to "save RF time" by some particular protocol.<br>
</div>
<div class="x_moz-cite-prefix"><br>
</div>
<div class="x_moz-cite-prefix">Lynn (D) - APRS Foundation -
Ensuring the Future of APRS</div>
<div class="x_moz-cite-prefix"><br>
</div>
<div class="x_moz-cite-prefix">PS. Most of the above text was
originally posted by me in the quoted github issue, but is
copied here to keep a single discussion thread here.<br>
</div>
<div class="x_moz-cite-prefix"><br>
</div>
<div class="x_moz-cite-prefix">On 2/15/2024 2:50 PM, Heikki
Hannikainen wrote:<br>
</div>
<blockquote type="cite"><br>
Hi, <br>
<br>
I've just learned that the VARA HF modem is replacing the APRS
destination callsign with "APVARA".
<br>
<br>
For example, if you use APRSIS32 with a VARA HF modem,
APRSIS32 sets a tocall of APWW11 and sends the packet to VARA
modem software, which replaces APWW11 with APVARA. This is
apparently done to save a few bytes on the slow HF link.
<br>
<br>
If APRSIS32 is configured to also send the packet to the
APRS-IS, there will be two different copies of the packet,
both will be received by other APRS stations, and the original
APRS software model cannot be detected any more.
<br>
<br>
<a class="x_moz-txt-link-freetext moz-txt-link-freetext"
href="https://github.com/aprsorg/aprs-deviceid/issues/123"
moz-do-not-send="true">https://github.com/aprsorg/aprs-deviceid/issues/123</a>
<br>
<br>
Just thought this should be brought up for other APRS software
developers to discuss, and for awareness of the side effects.
I'm not particularly delighted by this implementation choice.
Don't shoot the messenger.
<br>
<br>
- Hessu <br>
<br>
<br>
_______________________________________________ <br>
aprssig mailing list <br>
<a
class="x_moz-txt-link-abbreviated x_moz-txt-link-freetext moz-txt-link-freetext"
href="mailto:aprssig@lists.tapr.org" moz-do-not-send="true">aprssig@lists.tapr.org</a>
<br>
<a class="x_moz-txt-link-freetext moz-txt-link-freetext"
href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org"
moz-do-not-send="true">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a>
<br>
</blockquote>
<p><br>
</p>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>