<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div><div>To answer some of your questions about APRS Bulletins:<br><br></div>1) The original spec limited the total Public Bulletin board to 40 lines (one full screen at a time on the original PC). That limit was arbitrary and does not need to be implemented. But if bulletins get so many and so big, it defeats the purpose of public information...<br><br></div>2) If there are 30 lines of bulletins that have all decayed to the once every 30 minute default rate (so late comers will get a copy) then that is one packet per minute and a very small load on the network while keeping everyone informed.<br><br></div>3) I wonder about your statement: "Or,
are BLN messages not passed beyond an "n" hop range (i.e. not
injected into APRS-IS for possible retransmission elsewhere)?" Bulletins or all APRS traffic in a given local area should only use an N hop suitable to the local area. In most cases that is a hop of ONE. Our local EOC's are by city and county and usually one hop from any EOC can cover its area of interest. Further, APRS was not designed or intended to be re-injected back to RF from the APRS-IS. Though of course it can be done if needed.<br></div><br></div><div>4) I wouild think that reporting of open/closed gas stations and food storew would best be handled with objects rather than text in a bulletin.<br><br></div><div>5) What goes into a bulletin is a judgment call, weighing urgency with latency, and with network load.<br><br></div><div>6) APRS was designed from the gt-go to allow anyone to take over reporting responsibility for any positions and objects. But unfortuately it does not provide for one station taking over another stations bulletins. But that is one advantage of the overall 40 line limit. If an EOC or net op goes off line and his bulletins begin to age, then they can be forced off the bulletim board by another net op uploading enough new info to push the abandoned bulletin off the page. Or the new net control operator can momentarily use the originators call and send overwriting BLNx line numbers to earase the originals. THen take over as net operator with his own new bulletins.<br><br></div><div>7) There are lots of features of the original APRSdos that were left out by many follow-on clients. They are enumerated on this page:<br><a href="http://aprs.org/APRS-tactical.html">http://aprs.org/APRS-tactical.html</a> but please take that page with a grain of salt. It was written in 2008 at the depths of my frustration of APRS only being viewed as a tracking system. And not being used for rapid real-time community on-air information resource.<br><br></div><div>Hope that helps.<br></div><div>Bob<br><br></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 1, 2020 at 12:37 AM Greg D <<a href="mailto:ko6th.greg@gmail.com">ko6th.greg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
Hi Bob,<br>
<br>
Thanks for taking the time to weigh in. Much appreciated.<br>
<br>
So, trying to understand first, before reacting...<br>
<br>
BLN messages can be multi-line, which is great, but I presume it's a
client implementation topic for how many lines, and how long they
might be. I don't know what the limits are of the applications I
use, and need to check this out. Thanks for bringing it up. <br>
<br>
But if I understand their use, an example might be assigning BLN1 to
be the status of gas station outages, BLN2 the availability of ice
(to save refrigerator contents), BLN3 power status by area, BLN4 for
grocery stores open/close, etc. So if there are a half dozen gas
stations being reported on, would that mean a half dozen lines of
BLN1 information that would be repeated every, say 10-30 minutes?
Multiply that by, say, a half dozen bulletin types, with repeats,
and I'm thinking this could get unwieldy rather quickly. Do I have
this right? <br>
<br>
I've been assuming that we'd be using a local simplex channel for
this, in order to not QRM the entire region with our troubles.
Going without a Digi, however, could be problematic depending on
where the NC stations are located, as the terrain here is very
hilly, and there are a lot of shadowed areas. We do not have the
luxury of putting a digi at our club repeater site, at least not at
the current time, so we may be forced to use the 144.390 channel
(which does have a high level Digi support). That means whatever we
come up with must be compatible with that broader scope, including
the Internet IS backbone. How do BLN messages that collide with
other events doing the same thing in other areas get handled? Or,
are BLN messages not passed beyond an "n" hop range (i.e. not
injected into APRS-IS for possible retransmission elsewhere)? I'm
trying to understand how this kept local, yet scale at the same
time.<br>
<br>
As I noted originally, the need is for a shared, but geographically
distributed, Net Control function, and the ability to hand NC duties
off from one operator or operators to another over time. Last year
we had power outages that lasted for several days and covered a wide
area. With it went much of our internet and cell phone service. So
this needs to be able to operate in an RF-only environment, but
where operator equipment isn't available 24x7 (to conserve battery
power). The ability for a new NC to quickly get brought up to speed
when their shift starts is important. That means distributed
storage, and the ability to get it sync'd from the current NC staff,
without waiting for the network update time to get refreshed by the
usual methods, and without a centralized repository. <br>
<br>
I think that all of the normal APRS message types, including perhaps
bulletins, can apply. They're well understood and cover pretty much
all the bases. It's just that we need a way to hold and pass on the
situation map and chronological log from one set of NCSs to the
next, in the absence of the usual infrastructure. Andrew's idea of
using News might provide that foundation, instead of reinventing the
whole thing. Are there any other utilities that provide a similar,
light weight, multi-node data storage and sync function?<br>
<br>
Greg KO6TH<br>
<br>
<br>
<div>Robert Bruninga wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Actually existing APRS can
provide a lot of your
suggested Public Bulletin
functionality as-is depending
on whether Clients properly
implemented the original APRS
spec Bulletin protocol. Here
is how bulletins were SUPPOSED
to work (as in the original
APRSdos). so that everyone got
a maintained copy of any
multi-line bulletin from any
source.<br>
</div>
<br>
</div>
1) Bulletins are numbered BLNx
where X is numeric or alphabetic
to establish a -sequence- to the
lines in the bulletin.<br>
</div>
2) The local EOC (or anyone) could
maintain a multi-line bulletin that
is captured by EVERY APRS station in
real time, or for late comers too.<br>
</div>
3) BLNx lines are repeated ad nausium
but at a decaying rate.<br>
</div>
4) Thus every station gets every line
and they are always displayed as sorted
by line number<br>
</div>
5) The EOC can edit or change a line
(number of beds, number of ambulances,
etc) and it will REPLACE the previous
same-numbered line.<br>
</div>
6) Thus everyone in APRSdom always has the
latest full copy of the multi line bulletin
(worst case every 10 minutes or 30 minutes
depending on the overall timeout plan for
the given situation...<br>
<br>
</div>
The PROBLEMS with some implementations after
APRSdos that undermines the beauty of the
design I think are some of these:<br>
<br>
</div>
a) Many clients did not implement the decaying
algorithm. They transmit at fixed intervals and
then quit. This prevents all lines from being
continuously updated even after a few hours for
new commers on the frequency. The original was
transmitted once, then 15 sec later, then 30 sec
later, then one minute later, then 2 minutes
later, then 5 minutes later and then ten minutes
later and then every 30 minutes forever (though
a 12 hour or 24 hour time out wouild be nice).
Also, a decay to 10 minute or 30 minute cycle
could be set depending on the urgency and
dynamics of the situation.<br>
<br>
</div>
b) Many clients just logged each BLNx line as
received instead of always sorthing the ones from
the same sender always in sequence. This makes
multiline contiguous bulletins worthless.<br>
<br>
</div>
c) Same as b) in that replacement of a new BLNy
should overwrite an old BLNy was not implemented.
Thus to update a bulletin, the entire thing would
have to be sent again. Thus exploding the needed
bandwidth in a dynamic situation. Insatead of the
single refreshed line protocol.<br>
<br>
</div>
Can we at least identify any clients that fully
implemented the original Bulleting protocol?<br>
<br>
</div>
- Kenwood - NOT. TX's 1 per minute for 5 minutes and
stops. Does not sort on receipt. Does not replace
identical line numbers.<br>
</div>
- WinAPRS - Not. Same as above<br>
</div>
- YAAC - ?<br>
</div>
- APRSIS32 - ?<br>
</div>
<div>- XASTIR - ?<br>
</div>
<div><br>
</div>
Curious... Bob<br>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
<br>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On
Tue, Mar 31, 2020 at
5:37 PM Greg D <<a href="mailto:ko6th.greg@gmail.com" target="_blank">ko6th.greg@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
Hi Andrew,<br>
<br>
This is an intriguing
idea. Basically, use
the old News service
as the back-end
database / viewer, and
packet radio as the
transport. The
difference between
this and the PBBS
model is that the
database is
distributed and sync'd
among all the nodes
(net control
stations), vs having a
single instance that
everyone "dials" into
(figuratively or
literally). I like
the concept.<br>
<br>
How would the packet
radio part work?
Would you create a
plug-in to YAAC to
make the connections,
or would we need a
different client to
run in a more
traditional
connected-mode (vs UI)
framework? Ideally,
updates would be real
time among the active
net control stations,
with a sync function
when a new station
begins their shift.
Is the News service
able to run
near-realtime without
forcing a global sync
with every entry? I
don't recall this
being part of its
normal operation
(thinking it was more
batch oriented), but
it's been a few years
(!) since I've used
it.<br>
<br>
Rambling usage
thoughts and
questions... (TL;DR -
see "Ding", below)<br>
<br>
Thinking about how it
would be used; there's
certainly a lot of
flexibility... In the
application I
originally posted
about (wide area
service outage support
net), how would this
work? I was thinking
(and have rejected -
see below) to have one
thread for status
check-ins (power out /
on and where), each
resource (gas/fuel,
stores open or closed,
ice in stock or out,
equipment /
generators, random
needs, etc.),
miscellaneous notes,
...? I'm kind of
missing the APRS
mapping opportunity,
even though we didn't
have it with our paper
logs. Perhaps the
plug-in could somehow
create map objects
with the information
presented? After all,
a live map is one of
the primary views into
the APRS universe,
with the text-based
information being the
weak link. APRS
messaging has the
text, but not the
historical information
retrieval. Scattered
objects have the
information, but no
way to search through
it. <br>
<br>
So, I'm starting to
talk in circles...
YAAC already has the
ability to create
messages and objects,
so why have a separate
user interface (and
one without a map)...?<br>
<br>
*Ding!* An idea...
Perhaps the News
"database" (or
probably one message
thread therein) would
simply be an archive
of the APRS traffic
(messages and objects)
involved in the
overall incident, with
the unique ability to
replay / sync it
(LOCALLY!!, not over
RF) when a new Net
Control station does a
sync to begin their
shift? This removes
the need for Internet
access (and presumes
operation on a local
simplex frequency),
and provides that sync
ability that's missing
/ awkward with
APRS-IS. The
remaining (existing)
News functionality
could be used for
conversation traffic
archiving among the
Net Control
operators. Primary
user interface is the
standard APRS
messaging and object
generation that YAAC
already provides; the
plug-in would add the
real-time archiving of
the traffic, and sync
/ local replay
functions, using the
News service as the
database mechanism.
Information display
would be the existing
Station/Object list.
The real-time sync of
messages and objects
between active Net
Control stations is
just the normal APRS
operation via RF.<br>
<br>
The one thing that's
missing is a simple
time-ordered Net
Control running log.
My preference would be
to have it be
auto-generated
(station checked in,
object created, object
updated, etc.) and
added to the sync'd
News file. Or, is
this already provided
in the base YAAC
application? I'm not
seeing it...<br>
<br>
Making all this work
on an operational
basis will require a
number of site /
incident-specific
usage conventions,
e.g. what to name
objects (gas-1,
gas-2...) and how to
make status messages
useful (power is out
here - where?). There
might be another
plug-in or two to make
data entry easier for
a one-person Net
Control station to
handle, but let's get
the core right first.<br>
<br>
I'm trying to keep
this simple, otherwise
it'd just be better to
get one of the
enterprise-level SAR
support products,
which is where I don't
want to end up.
Remember, we're trying
to replace pencil
& paper, and need
to assume battery
operations - HT and
laptop or Raspberry Pi
- and a candle.<br>
<br>
Thanks!<br>
<br>
Greg KO6TH<br>
<br>
<br>
<div>Andrew Pavlin via
aprssig wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">Hi, Steve.</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">Re-reading
your email on this
as I got restarted
on my own effort
in this area
reminded me of
some other ancient
technology that we
might want to
resuscitate for
this problem.</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">Does anybody
remember Usenet
(otherwise known
as the
InterNetNews)? It
was a powerful
means of
implementing a
distributed
world-wide
collection of
thousands of
bulletin boards of
discussion
threads, back
before the World
Wide Web, hosting
service providers,
and (nearly)
ubiquitous
broadband replaced
Usenet with
world-accessible
single-server web
forums and blogs.
Like email in
those days, Usenet
only carried
plain-text; like
email, it could
carry anything
that could be
bundled into a
plain-text email
message, such as
binary files
encoded by the
useful uuencode
and uudecode
programs. It would
automatically
synchronize all
the distributed
copies of any
given discussion
group. And it
could work over
(by today's
standards)
ridiculously
low-bandwidth
links. In 1991, I
was running a
corporate Usenet
news gateway over
a leased-line
Internet
connection at a
screaming 19.2
kilobaud. Yes,
_that_ slow. Yes,
we had dialup
modems that went
faster than that
before broadband.<br>
</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">These days,
the Usenet news
server software is
still available in
most Linux distros
(I just checked,
and both Fedora
Core and Raspian
Buster still have
it as an optional
distro package).
Many email clients
still support NNTP
(Network News
Transport
Protocol) as well
as SMTP (Simple
Mail Transport
Protocol). And
NNTP can transfer
over any TCP/IP
link (including
TCPIP-over-AX.25
and HSMM, as well
as the global
Internet), and
over batched
low-level links
(it used to use an
old package called
UUCP [Unix-to-Unix
CoPy] to transfer
updates over
dialup links) at
barely more
infrastructure
than the KISS
protocol.</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">So, we could
set up NNTP
servers on
Raspberry Pi
computers (or
anything else) and
use any sorts of
links to connect
them together:
Internet, HamWAN,
AREDN, TARPN, heck
maybe even fldigi
file transfers
(not much
different than
what UUCP did).
Because NNTP uses
a flood-fill
algorithm to
distribute
messages over
multiple paths, if
one link goes
down, the target
at the other end
of the failed link
will eventually
get it via several
relays on other
links as long as
every news server
has links to more
than one other
news server, and
the topology
doesn't have any
Single Points Of
Failure. No
particular network
topology is
required; just
like amateur
radio, Usenet
doesn't need a
central control
office (unlike
cellphones). We
can certainly get
sufficient TCP/IP
speeds over AX.25
packet with the
9600-baud TNCs
(hardware and
software) that are
readily available
now for a
TARPN-style VHF
network for areas
where we can't do
HamWAN/AREDN, but
NNTP will still
work over those
networks as well.
And, if we keep
our Usenet
separate from
what's left of the
old Internet
Usenet, we don't
have to worry (as
much) about
illegal content
putting
transmitting
stations at risk
or excessive
traffic volume.
After all, most
public service
events that use
APRS put their
event traffic on a
different
frequency than the
national APRS
frequency to avoid
congestion.<br>
</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">So, if what is
needed to solve
the problem is a
distributed
bulletin board,
Usenet solved it
for us decades
ago.<br>
</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">Just my $.03
(inflation, ya
know).</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">Andrew, KA2DDO</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">author of YAAC
("Yet Another APRS
Client")</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
</div>
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px">
<div><br>
</div>
</div>
<div id="gmail-m_1907792826313682331gmail-m_-8041449493147476804ydpb9f94d4byahoo_quoted_6237914876">
<div>
<div> On
Wednesday,
December 4,
2019, 12:11:44
AM EST,
Stephen H.
Smith via
aprssig <a href="mailto:aprssig@lists.tapr.org" target="_blank"><aprssig@lists.tapr.org></a>
wrote: </div>
<div><br>
</div>
<div><br>
</div>
<div>
<div id="gmail-m_1907792826313682331gmail-m_-8041449493147476804ydpb9f94d4byiv6627603611">
<div>
<div id="gmail-m_1907792826313682331gmail-m_-8041449493147476804ydpb9f94d4byiv6627603611yqtfd56917">
<div>On
12/3/2019 6:26
PM, <a shape="rect" href="mailto:chiefsfan2@cox.net" rel="nofollow" target="_blank">chiefsfan2@cox.net</a> wrote:<br clear="none">
</div>
<blockquote type="cite"> </blockquote>
</div>
</div>
<div>
<div id="gmail-m_1907792826313682331gmail-m_-8041449493147476804ydpb9f94d4byiv6627603611yqtfd00049">
<div>Since you
had a analog
landline phone
still working
that would be
a reason to
bring back
some phone
patches like
we used to
have. And now
you can run a
BBS on a rasp
pi computer
which makes
for great
portability
and low power
consumption</div>
</div>
<p>Funny you
should bring
this up at
this
particular
time. Just
last week, I
was
experimenting
connecting an
old Heathkit
HD-1515 phone
patch I found
in my junk box
to the 6-pin
mini-DIN data
port of a
Yaesu FT-857D.
It worked
perfectly both
on FM for 2
meters and on
SSB for HF.
I'm now going
to add a 6-pin
mini-DIN jack
to the back
panel of the
patch, in
parallel with
the existing
RCA RX and TX
audio jacks.
I can then use
a standard
off-the-shelf
6-pin DIN to
6-pin DIN
cable to
connect the
patch to any
radio with a
standard 6-pin
data port.
Finally, I
will add a
double-throw
center-off
locking-one-way
/
momentary-the-other-way
toggle switch
to the front
panel to key
the radio
transmitter.
<br clear="none">
</p>
<p>I'm now
thinking about
getting one of
those
Bluetooth
gizmos that
links to a
cellphone and
and produces a
couple of
classic RJ-11
analog phone
jacks. I could
plug the patch
into one and a
classic desk
phone set into
the other.
This would
allow phone
patches either
via a "real"
phone line, or
via a
cellphone
connection if
needed.</p>
<p>Another
variation on
this theme:
With a sound
card interface
setup normally
as you would
use for
digimodes on a
PC, start up
Skype instead
of a soundcard
digi-mode app.
You can then
run "phone
patches" from
radio users to
users on Skype
instead of a
POTS line. <br clear="none">
</p>
<p><br clear="none">
</p>
<hr size="2" width="100%">
<p>Stephen H.
Smith
wa8lmf (at) <a href="http://aol.com" target="_blank">aol.com</a>
<br clear="none">
Skype:
WA8LMF<br clear="none">
EchoLink:
Node # 14400
[Think bottom
of the 2-meter
band]<br clear="none">
Home
Page:
<a shape="rect" href="http://wa8lmf.net" rel="nofollow" target="_blank">http://wa8lmf.net</a><br clear="none">
<br clear="none">
-----
NEW!
60-Meter
APRS! HF
NVIS APRS
Igate Now
Operating
------<br clear="none">
<a shape="rect" href="http://wa8lmf.ddns.net:14447/" rel="nofollow" target="_blank"><http://wa8lmf.ddns.net:14447/></a><br clear="none">
<br clear="none">
Live
Off-The-Air
APRS Activity
Maps<br clear="none">
<a shape="rect" href="http://wa8lmf.net/map" rel="nofollow" target="_blank"><http://wa8lmf.net/map></a><br clear="none">
<br clear="none">
Long-Range
APRS on 30
Meters HF <br clear="none">
<a shape="rect" href="http://wa8lmf.net/aprs/HF_APRS_Notes.htm" rel="nofollow" target="_blank"><http://wa8lmf.net/aprs/HF_APRS_Notes.htm></a></p>
<div id="gmail-m_1907792826313682331gmail-m_-8041449493147476804ydpb9f94d4byiv6627603611yqtfd18518">
<p><br clear="none">
</p>
<p><br clear="none">
</p>
</div>
</div>
</div>
<div id="gmail-m_1907792826313682331gmail-m_-8041449493147476804ydpb9f94d4byqtfd79887">_______________________________________________<br clear="none">
aprssig
mailing list<br clear="none">
<a shape="rect" href="mailto:aprssig@lists.tapr.org" rel="nofollow" target="_blank">aprssig@lists.tapr.org</a><br clear="none">
<a shape="rect" href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="nofollow" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br clear="none">
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
aprssig mailing list
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
aprssig mailing list
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div></div></div></div>