| |
ZL3AI > APRDIG 13.06.04 07:31l 680 Lines 28333 Bytes #999 (0) @ WW
BID : 3449-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 07, 5/7
Path: DB0FHN<DB0RGB<DB0MRW<OK0PPL<DB0RES<ON0AR<LU6DTS<ZL2TZE<ZL3VML
Sent: 040613/0512Z @:ZL3VML.#80.NZL.OC #:25750 [Chch-NZ] FBB7.00i $:3449-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: APRS Protocol - A Modest Proposal
From: "Curt, WE7U" <archer@eskimo.com>
Date: Mon, 7 Jun 2004 13:48:53 -0700 (PDT)
X-Message-Number: 92
On Mon, 7 Jun 2004, David Rush wrote:
>I have a modest proposal for a minor change to the APRS protocol.
>Require that APRS clients pay attention to the PID. If it's not F0,
>then the APRS client is allowed to either discard the packet or process
>the packet in a way appropriate for that kind of packet.
>
>It seems a bit odd that, as I have heard on this sig, the protocol
>requires the transmitter to use the proper PID but not the receiver.
>Why not take advantage of the situation?
>Anyone on the WG interested in chapioning this idea? Anyone? Anyone?
>
>I may be naive about why this hasn't been done already, but it just
>seems to be A GOOD THING to do.
>
>David, ky7dr
It's totally common sense David, you're not naive about this at all.
Without this minor tweak to the spec, we're wide open to problems caused by
other protocols that also use AX.25, but with other PID's. I personally am
shocked that it wasn't written into the spec from the beginning. It's a
major oversight in my book.
--
Curt, WE7U http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: RE: Introducing "OPENAPRS"
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 16:58:14 -0400
X-Message-Number: 93
>>>Danny <danny@messano.net> 6/7/04 3:05:21 PM >>>
>APRS is not going to change. The key players refuse
>to allow any changes, because it would hurt the users
>(even if they are the ones looking for change).
Id like to see how you get to your last sentence above... Remember, no one
on APRS is seriously impacted except the Kenwoods, Mic-E's, Trackers, HAM
Huds and other trackers.. so its only they who really care...
Of the 3000 Kenwood users, I have only seen one that said he would abandon
his D700 for the benefit of programmers....
>If we want different/better, the wheel needs to be
>reinvented somewhere else, and the users can choose
>and migrate somewhere else.
Agreed.
>APRS 1.0 is the first and last version of APRS.
Plus the data on the aprs/errata page...
Thus it is a very stable design and thus a good investment for somone that
wants to make hardware rather than vaporware...
Bob
----------------------------------------------------------------------
Subject: Re: APRS user beware part 2
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 17:00:24 -0400
X-Message-Number: 94
Ah thanks.
I'm only talking about USA here. APRS in Europe quite honestly has very
different sense of application than in the USA where emergency response,
and public service play the dominant role objective...
>>>"DG2JW" <dg2jw@privateasylum.com> 6/7/04 3:25:17 PM >>>
>My recollection is that of the 20,000 APRS stations on the air
>that something like 3,000 of them were kenwoods. That
>is 16% not the 0.001 you just claimed.... and as far as the
>ratio of packets, since a Mobile kenwood in motion is usually
>operating at ten times the rate of a fixed station, I would say
>that fully HALF of all packets on the air are probbly
>kenwoods.
Are we counting Europe and Asia as well, or just the United States and
or North South America?
best regards
Julian
OH8GEJ
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: Steve Dimse <k4hg@tapr.org>
Date: Mon, 7 Jun 2004 17:11:07 -0400
X-Message-Number: 95
On 6/7/04 at 2:09 PM David Rush <david@davidarush.com> sent:
>I have a modest proposal for a minor change to the APRS protocol.
>Require that APRS clients pay attention to the PID. If it's not F0,
>then the APRS client is allowed to either discard the packet or process
>the packet in a way appropriate for that kind of packet.
The problem is that there is no way to tell what the PID is if the program
uses converse mode. AFAIK, all APRS programs support converse, not all
support KISS mode. You would be requiring those program to support KISS,
and all users currently using converse mode to change, some of which may
require new hardware.
Worse, the APRS IS could no longer be part of APRS. The APRS IS is based
upon the textual representation of packets used in converse mode, and like
converse mode, it has no way to tell a PID number. You would have to
completely trash the APRS IS and start from scratch. Every client with
internet connectivity would have to be changed.
Doesn't sound like a modest proposal or a minor change to me...
Steve K4HG
----------------------------------------------------------------------
Subject: Re: New worldwide maps available for FindU
From: "Brian Riley (maillist)" <n1bq_list@wulfden.org>
Date: Mon, 07 Jun 2004 17:12:15 -0400
X-Message-Number: 96
If this is all Ok I will add reference to these maps at Findu.com location
to my APRS Query and Tracking pages as well
Cheers ... 73 de brian, n1bq
On 6/7/04 9:28 AM, "Steve Dimse" <k4hg@tapr.org> wrote:
>On 6/7/04 at 1:00 PM Tim Makins, EI8IC <contesting@eircom.net> sent:
>
>>I have made available a set of 6 continental and 27 sub-continental outline
>>maps, covering most inhabited areas, for use with findu requests. See:
>>
>Very nice!
>
>Only problem is qsl.net is slow...I put copies on my server, can I publicize
>this?
>
>http://www.findu.com/cgi-bin/plot.cgi?call=*&geo=ei8ic/caribbean_east.geo
>
>Also, the Oceanias don't work, I fear this is my problem, I'm guessing my geo
>code doesn't work on maps that span 180/-180...I'll look in detail when I get
>a chance.
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 7 Jun 2004 14:20:58 -0700
X-Message-Number: 97
Steve,
I didn't see at first that this wasn't intended for the SIG. My apologies.
I just hope this is a sign that your mind is more on work today than APRS.
Keep your attention where it belongs... one forgotten sponge or pair of
hemostats and folks get all upset these days. =]
Scott
N1VG
----- Original Message -----
From: "Steve Dimse" <k4hg@tapr.org>
Waste of time Bob.
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Doug Bade <dbade@clecom.com>
Date: Mon, 07 Jun 2004 17:23:42 -0400
X-Message-Number: 98
Unless I am missing something the stats just issued seem to indicate the
following...
Kenwoods = ;
~15% of all packets logged.
~25% all mobile packets including of those of unknown origin ( which may
not be mobile at all ).
~50 % all Identified mobile/portable packets...
No sales numbers here.. Just packets... no mirrors, no smoke....
I bet you still feel we should outdate them????
Unsubstantiated claims??? I think not... Reality check time...
You really do not want to dis-include any fixed stations as your case will
get a lot worse than better.... Being APRS is a RADIO mode, I think RADIOS
which ARE using the mode should be fully included in any "NEW" idea's...
without promoting their obsolescence.
But I guess that kind of logic has little to do with this
discussion...
I wonder why any of you think Kenwood or any other major
manufacturer would EVER release another APRS radio, considering the crap
they are getting for what they did DO??? I bet the sales of them are down
at this point, and with diminishing sales and so many who despise the
"profit mongers"," who did such a horrible implementation job" that they
would even consider doing it again?? I think in time you will get your
wish, they will go out of production, and turn from a useful tool into a
piece of obsoleted hardware due to the "innovators" of our time....and will
quietly slip into history... As will a large number of active users of
APRS...But I guess none of that is academic to a new innovation....Lord
knows these house "clients" need better ways to tell each other, VIA RADIO,
where they are, as they are moving so quick....and we definitely need
better SW to do this ....well worth the trade off.....
If I were making such decisions at Kenwood, I doubt I would have
stuck around this long.
As a quite happy D700 owner, it is truly sad to see the hatred of
us out there... I never knew I was in league with the evil empire.
Doug
KB8GVQ
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 17:18:56 -0400
X-Message-Number: 99
Good idea. Ill add it to the APRS errata page.
thanks.
Bob
----------------------------------------------------------------------
Subject: Re: APRS user beware part 2
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 17:17:18 -0400
X-Message-Number: 100
>>>Jeff King <jeff@aerodata.net> 6/7/04 3:58:20 PM >>>
>At a beach front hotel. I spent most of my time
>explaining the VAN's really were not driving on
>the beach when they in fact where waiting by the
>lobby to pick everyone up.
>Sounds to me like you didnt check your map datums first.
>I dont know of any place where 60 feet (the default
>precision of APRS) would give that error.
That just shows the vulnerability when people just assume that a number
from a GPS when plotted on any-old map will give them the RIGHt position
because there are so many points aftre the decimal point. A position with
10 decimal points of precision is no better than one with 3, if the map is
no better than 2...
I am sure it was a good lesson for you.
Bob
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 7 Jun 2004 14:26:25 -0700
X-Message-Number: 101
>I personally am shocked that it wasn't written into the spec from
>the beginning. It's a major oversight in my book.
The way I read the spec, it WAS. But apparently that's open to
interpretation. It's certainly in the category of good engineering
practice. Even if OpenTRAC ceased to exist today, I'd still advocate the
PID filtering settings as the default for all APRS converse-mode stations.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Mon, 07 Jun 2004 23:45:16 +0200
X-Message-Number: 102
At 20:53 6-6-2004 -0400, Robert Bruninga wrote:
>Notice that of all those PIDS you list, ONLY ONE OF
>THEM is the UNPROTO PID, and that is F0, and that
So what is your problem then? OpenTrack transmits AX.25 packets with UI
primitve and Protocol ID 0x77. In your vocabulary these are not UNPROTO
packets, so it is not possible that any APRS complient client will make the
mistake to treat it as one, Good!
>is what is in the APRS spec and that is what is on the
>APRS channel.... End of discussion. Bob
Good, so occasional nightly updates to update a digipeater using TCP/IP
will not do any harm then and also the few packets from a hand full of
programmers experimenting with OpenTrack can be sustained easily in the big
ocean of APRS packets.
Took a long time, but I'm glad we got that out of the way. Lets get to work
then and see were our mutual effort takes us.
Maybe you should add use of 0x77 to the APRS SPEC with a reference to the
OpenTrack specification so that client designers can build clien---------------------------------------------------------------
Subject: Re: APRS user beware part 2
From: Jeff King <jeff@aerodata.net>
Date: Mon, 07 Jun 2004 17:13:01 -0500 (CDT)
X-Message-Number: 104
Factual check here...
Quoting Robert Bruninga <bruninga@usna.edu>:
>I'm only talking about USA here. APRS in Europe
>quite honestly has very different sense of application
>than in the USA where emergency response, and public
>service play the dominant role objective...
Both the amateur services in the U.S. and Europe are governed by the ITU,
and emergency comms is not the basis or purpose of amateur radio according
to the ITU. In the U.S. the FCC did in fact add ecom's to the basis and
purpose of amateur radio, but was prohibited by ITU rules to remove
advancing the state of the art as a basis and purpose.
Hence, someones interest in advancing the state of the art, is just as
valid in the U.S. as it is in Europe, and would be spelled out in each
countries rules.
See 97.1:
http://www.arrl.org/FandES/field/regulations/news/part97/a.html#1
and ITU 1.56
http://life.itu.int/radioclub/rr/art01.htm
----------------------------------------------------------------------
Subject: RE: Introducing "OPENAPRS"
From: Jeff King <jeff@aerodata.net>
Date: Mon, 07 Jun 2004 17:21:45 -0500 (CDT)
X-Message-Number: 105
-Serious- logic flaw correction here
Quoting Robert Bruninga <bruninga@usna.edu>:
>Remember, no one on APRS is seriously impacted except
>the Kenwoods, Mic-E's, Trackers, HAM Huds and
>other trackers.. so its only they who really care...
ONE SINGLE HAM HUD was effected by the direct over the air protocol, sent
over a ~400,000 sq mile area!! That is all we know of after hundereds of
messages on the SIG. ONE! No-one else!
By implication, in putting HAMHUD in the same sentence with the other
devices, your trying to imply something that didn't happen, happened.
This is patently false, and at best (I'll give you the benefit of the
doubt), is a serious logic flaw on your part.
My 10th grade debate teacher would have failed you for trying to slip that
one by.
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 07 Jun 2004 17:40:22 -0500
X-Message-Number: 106
>The problem is that there is no way to tell what the PID is if the program
uses
>converse mode. AFAIK, all APRS programs support converse, not all support KISS
>mode. You would be requiring those program to support KISS, and all users
>currently using converse mode to change, some of which may require new
hardware.
It has been researched that only a TNC configuration change is required to
hide OpenTrac packets from all APRS users. This same change might help
eliminate garbage that appears on the air in various areas too.
Part-97 does allow anyone to use 144.390mhz for Amateur radio transmissions
that do not intentionally interfere with others. And since we are talking
about AX.25 packets, there is no interference with the transmitted data. The
users equipment might be configured to misread or misuse the received
information, but interference is not present. And, I know this is a real
sticking point here. But, everyone involved in the opentrac side of this
discussion doesn't seem to be telling everyone using APRS on 144.390mhz that
tomorrow opentrac will take over. This particular event illustrates an issue
that some APRS configurations might have. It can be remedied without software
or hardware changes in many cases it seems. So, why not close the gap?
>Worse, the APRS IS could no longer be part of APRS. The APRS IS is based upon
>the textual representation of packets used in converse mode, and like converse
>mode, it has no way to tell a PID number. You would have to completely trash
the
>APRS IS and start from scratch. Every client with internet connectivity would
>have to be changed.
I think that an easy way to solve this would be to use a separate port for a
new, slightly different structured stream of data that included the PID. I
would think that the existing code could be easily used when the PID was F0,
and when its not F0, you could do something specific to that protocol, archive
it, or event drop it.
>Doesn't sound like a modest proposal or a minor change to me...
Initially, I think there is only a small amount of work to keep AX.25 packets
that are not APRS from interfering with APRS users. The APRS-IS has a lot of
facilities that are valuable to a lot of people. From a software engineering
standpoint, it would take quite a bit of effort to create a protocol
neutralization layer in front of the APRS-IS tools, and then
rearchitect/rewrite them to recognize the output format of the neutralized
data.
Many people over the years have asked to help you with maintaining and running
the APRS-IS. I know that you have a lot of time invested, and probably have
personal and emotional attachments. You certainly have monetary investments
too. It might be worth while to start thinking about how the tool set might
be placed onto sourceforge or some other central repository site where the
workload for development can be shared, but whee ultimately, you can still
just make the changes that you think are in the best interest of the
community. Since it is still your baby, I think its okay to give you
dictatorial control over deployed tools. But, I think you could take
advantage of others work in some cases too.
I've enjoyed seeing the interplay between you and James to make use of his
data over at aprsworld. That's one way that the community was able to give
something back to you I think.
If there are people willing to help, perhaps we can find a way to let everyone
have a part that can help.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: APRS OBJECT Caching (Rev 1)
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 18:45:35 -0400
X-Message-Number: 107
Revised APRS OBJECT-Caching SPEC:
OBJECTIVE: A format to signal to a digipeater or other specialized APRS
station to cache, or take over reporting responsibility for a given
object. This technique improves channel efficiency by more than a factor
of two because it eliminates the uplink contention to the digi on all
subsequent repetitions, and because the DIGI has better CSMA performance,
it assures better reliability on delivery.
OBJECT FORMAT: Identical to existing OBJECT format Fully backwards
compatible in all respects. No chnages to any existing APRS formats nor
client software are required.
TARGET DIGI: The digi or station to cache the OBJECT is specified as the
FIRST digi in the path. The DIGI call must be an explicit match, must
be first, and that digi must have heard the packet DIRECT.
TOCALL: To signal a cache request to the DIGI to take over
responsibility, the object packet will use the special APRS TOCALL of
AP0Cxy (that's a zero).
Where: x = expiration time in hours from now
y = final periodiciy in minutes
DIGIPEATER OR STATION RESPONSE: On receipt of a Cache Request, that meets
the criteria above, the designated digipeater will add the OBJECT format
to its OBJECT cache but will change the TOCALL from AP0Cxy to AP0Oxy for
subsequent transmission.
CACHED OBJECT ACKNOWLEDGEMENT: On receipt of the Cache request, the
DIGI/station taking over responsibility will acknowledge that fact by
simply sending out the first copy of the cached object. ALL existing
APRS spec compliant code will already see that response and will
relinquish any uplink responsibility.
CACHED OBJECT TIMING: Since such a request is usually the result of a NEW
object or a changed position of an object, the Caching digi should
implement the usual decayed rate algorithm before settling in to the
requested ultimate refresh rate to make sure that all stations on the net
had a higher than normal probabilly of receipt of this new data. A
suggested implementation algorithm is to send the second Cached OBJECT
one minute later, then 2, then 4, then 8, then 16 minutes later and do on
until the final requested rate is reached. This is the original APRSdos
algorithm for new data. Authors are allowed flexibility in the details of
this routine as long as an effort is made to have at least a few copies
transmitted within the first few minutes.
CACHED OBJECT PATH: The Cached OBject path can ONLY be direct. The intent
of this process is to OPTIMALLY serve only the local area with the
multifold improvement in reliability. PLEASE NOTE: If this rule is
violated and the OBJECT is sent out for further digipeating, then the
fundamental objectives of the whole idea is lost, since now the packet is
no different with respect to collisions and doubling of channel capacity.
The one exception to this rule is under DIGIPEATER SYSOP control who may
specify an alternate REQUIRED path for all such cached objects. A good
example here is a special event which requires 3 main digis to serve the
entire venue. This is known in advance and so the SYSOP for these 3
digis establishes a specified explicit path that includes the other two
digis.
The other objective of this DIRECT-ONLY rule is to prevent remote SPAMING
of distant areas.
BACKGROUND AND DETAILS: This caching idea has been in APRSdos since about
1995 or so and is compatible with the existing spec. The only difference
here is that in APRSdos, the process was called OBJECT-NET-CONTROL where
APRSdos, IF- enabled by the SYSOP for a one-time event, would automatically
take over reporting responsibility for ALL objects at the event.
Then in 2004, Scott Miller suggested that the originator of an object
should be able to request such action remotely. This spec is the result of
these two ideas.
NOTES on HOW OBJECTS ARE HANDLED BY APRS1.0. None of this is impacted in
any way:
1) Taking over responsiblity for objects has always been fundamental to
APRS. This means that ANY station that is SENDING an object, will, on
seeing the SAME object name (case dependent) from a different station, will
CEASE its own uplinking and will accept as a replacement the new OBJECT
data from the new station.
2) Clients are required to always retain the identify of the SENDING
station so that end users can easily tell who has responsibility at any
instant.
3) Due to the promiscuous nature of Object ownership all client programs
SHOULD display the data AT ALL TIMES and on the MAP as well whether the
object is owned by THIS station or another station. Example: APRSdos
always displays OWN-STATION active objects as YELLOW, and other station
objects as Purple. Notice these color can toggle at any time and on a
packet-by-packet basis... and so these provisions assure the operators are
fully aware of the changing ownership. Without these ON-THE-MAP
distinctions, it is very dangerous, because you can never be sure if the
object you placed at location X is still there, or actually has been moved
across the street without your knowledge!
ANything I missed?
Thanks.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: APRS user beware part 2
From: "DG2JW" <dg2jw@privateasylum.com>
Date: Tue, 8 Jun 2004 01:53:28 +0300
X-Message-Number: 108
Hi Bob
Europeans use APRS in many of the same ways as Americans do. However, in
regards to APRS, we (at least in Scandinavian countries) tend to put more
emphasis on experimentation and technology, using APRS as a vehicle to
enhance and record those activities. Higher specs are important when
tighter tolerances are required. In Finland, I can say we have one of the
most innovative group of Hams in Europe. Engineering, designing,
experimenting and closing the gap between professional and academic
experimentation/research and our hobby.
(to everyone)
We have also fought this fight in Finland where the established ham radio
community could not understand the new hot blooded innovative hackers new
to the hobby. We were told to sit down and practise CW if we wanted to do
something useful, or maybe learn how to build a tuna tin for 40meters. What
we actually wanted was to ask the question "Why?", to push the technology
envelope, and to learn something new. While our counterparts built KW amps
for contacts 400km away, we were studying RF propagation in Microwave
bands. While our counterparts contested, we hacked cellular phones for 2m
and 70cm 1.GHz so that other youthful minded fresh free thinking people
could get involved with the hobby with trash bin economy. I myself
contributed by showing youths that it is possible to build more efficient
antennas for VHF, UHF and SHF rather than the old no brainer more power
approach and effectively working portable communications from remote sites
with low power and small but efficient antenna. I can remember each some
Kilowatter laughed at me trying to adjust azimuth and elevation right in
the field with only the equipment I could carry on my motorbike, just to
get people interested in something innovative.
Ok enough with the analogies. Here is the point. APRS is a global project
now. We all need to do what we can do to stay on top of technology and
innovation. If we don't produce something useful, and drive technology
forward, commercial interests will take more of our bands away. We can
accomplish much more together than split apart. Most of you know Im an
American living in Europe. I can honestly say, in regards to ham radio,
North America could learn a thing or two about working together for there
good of the hobby. It doesn't matter if its APRS or Opentrac, we need
talented minds to work together to share ideas and open those doors
traditionally closed for whatever reasons.
Lets work together or fail. Its that simple. If we don't wake up and kick
ourselves in the arse, we wont have a hobby to come back to. I have a 40
meter tower sitting in my yard here in Oulu, with enough VHF and SHF
equipment on it to light up Lapland. My wife says "why do you keep that
tower up?". I tell her because of that first time I listen to BBC world
service 30 years ago with an old GE receiver and a wire in a tree. Many of
today's hams require more. More of what can be defined by each individual.
If we don't come up with more, we loose it all.
Best regards
Julian
OH8GEJ
----- Original Message -----
From: "Robert Bruninga" <bruninga@usna.edu>
Subject: [aprssig] Re: APRS user beware part 2
>Ah thanks.
>I'm only talking about USA here. APRS in Europe
>quite honestly has very different sense of application
>than in the USA where emergency response, and public
>service play the dominant role objective...
>Are we counting Europe and Asia as well, or just the United States and
>or North South America?
>
>best regards
>Julian
>OH8GEJ
----------------------------------------------------------------------
Subject: Re: APRS OBJECT Caching (Rev 1)
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 18:56:55 -0400
X-Message-Number: 109
>Revised APRS OBJECT-Caching SPEC:
>
>If the Email version was garbled, the actual SPEC is
>http://www.ew.usna.edu/~bruninga/aprs/cached.txt
I tried to incorporate all the feedback we got in the consensus of the
lengthy email exchanges over the last few days.
I'm outta here today. Too much APRS...
Bob
----------------------------------------------------------------------
Subject: Re: APRS OBJECT Caching (Rev 1)
From: Jeff King <jeff@aerodata.net>
Date: Mon, 07 Jun 2004 18:04:33 -0500 (CDT)
X-Message-Number: 110
Insight...
Quoting Robert Bruninga <bruninga@usna.edu>:
>Revised APRS OBJECT-Caching SPEC:
....
Not to be a smart alec in the past, but quite a few people, including
myself, have asked about the status of the APRS-WG and if the
charter/protocol submission process is being followed. All of them have
been summarily ignored (my lawyer calls this stonewalling). Yet, you seem
to be able to post new things here, and call it a "SPEC"....
I'm soley pointing out this apparent double standard might explain for some
of the conflict and bad feelings here. Clearly too late to fix that now,
but might be some insight for those wondering what the big deal is about.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
