World of Ham Radio 1994 January/AMSOFT_1994.iso/packet/docs/pd199108.doc

Internet Message Format | 1993-12-31 | 555.4 KB

Date: Thu,  1 Aug 91 04:30:05 PDT From: Packet-Radio Mailing
List and Newsgroup </dev/[e-mail]> Errors-To:
[e-mail] Reply-To: [e-mail]
Precedence: Bulk Subject: Packet-Radio Digest V91 #193 To:
packet-radio

Packet-Radio Digest         Thu,  1 Aug 91       Volume 91 :
Issue 193

Today's Topics:        'NA' country domain appears to be
non-unique (7 msgs)                       .NA addressing in
PACKET                     DRSI PC*Packet Adapter Code
           IP numbers for PMP sites.
Local questions:                    Need help on PK232 for
tcp-ip             Packet-Internet Gateways (was NA in headers)
                 Packet<->Internet Gateway Notes
       Problems with $ bulls.                     So what's
wrong with .NA ???                   Update info on the WB3FFV
BBS...

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 30 Jul 91 10:22:39 GMT From:
mcsun!ukc!axion!kitkat![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

------------------------------

Date: 30 Jul 91 19:54:12 GMT From: [e-mail]
Subject: 'NA' country domain appears to be non-unique To:
[e-mail]

------------------------------

Date: 31 Jul 91 02:33:12 GMT From:
munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!elece
ng![e-mail] Subject: 'NA' country domain appears to
be non-unique To: [e-mail]

I guess a problem like this had to crop up eventually, but I
think it exposes a larger underlying problem with the Packet
Radio BBS Network. I have been a BBS SysOp for a couple of years
now and have also been involved in writing a BBS Program
(RTTYGate RTTY><Packet Gateway). In that time I dont recall
seeing any documents that set down the standards for the
operation of the BBS system.

I have seen several discussion documents (and would love to see
the one explaining the 4 letter continent designators) on mainly
the Hierarchial addressing but nothing on how BBS forwarding is
supposed to be conducted, how headers should be formulated and
only small amounts on White Pages and BID/MID's. All of these
seemed to be worded like DISSCUSSION doccuments, or passed on
because the majority of the existing software does whatever
function a particular way, and not really as standards.

Thinking about these things and also the current problem of the
NA ** LOCATION ** code on the BBS Network and *.na top level
Internet Domain, I started to wonder whether the Software
writers and Packet Operators should put together a set of Packet
BBS "RFC like" documents, called for example PBS's (Packet BBS
Standards)? (if they dont already exist, or if they do, make
them much more widely known and formalised).

If such a set of standards existed, it would be a good starting
place for those wishing to write BBS software, and a good
starting point to modify existing code to produce a uniform
network. Aspects that could be formalised may include,

BBS Forwarding - Definition of Forwarding Dialogue BBS
Forwarding - BBS Header Standards BBS Forwarding - Definition of
Standard Compression Algorithm BBS Addressing - Hierarchial
Address Definition and Location Codes BBS Addressing -
Hierarchial Address - Parsing Procedure BBS Addressing -
Bulletin BID Definition, Message MID Definition BBS Operation  -
Gatewaying BBS Operation  - White Pages

just to name a few!

It is pretty obvious that this will be a monster task, but then
can we afford not to do it? As the BBS net becomes more and more
connected to other networks, problems like the NA Address will
no doubt become more prevelent. Getting all BBS Software to
conform will take time as new versions will need to be written
and the Thousands of BBS's world wide upgrade to the new
software but I think it is a step that should be taken.

I would like to hear others thoughts on this. I am not
volenteering to write them, that should be a co-operative
activity amongst ALL BBS software writers but I do believe that
if we dont move in a similar direction to this that the Packet
Network will run into more and more problems in the future.

Cheers de Grant VK5ZWI--

Grant Willis (VK5ZWI), Electronic Engineering Student. |
Adelaide University AARNet/Internet1:
[e-mail]        | South AUSTRALIA
AARNet/Internet2: [e-mail] | My
views are my own, AmPRNET: VK5ZWI@VK5TTY.#SA.AUS.OC
[44.136.171.11]     | not the Uni's!

------------------------------

Date: 31 Jul 91 07:50:37 GMT From:
mcsun!ukc!axion!kitkat![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

------------------------------

Date: 31 Jul 91 14:21:07 GMT From:
atha!aupair.cs.athabascau.ca![e-mail] Subject: 'NA'
country domain appears to be non-unique To: [e-mail]

[e-mail] (Grant Willis VK5ZWI) writes:

>I have seen several discussion documents (and would love to see
>the one explaining the 4 letter continent designators) on mainly

It was in a paper presented at the 9th (?) ARRL packet
conference (London, ON).

>All of these seemed >to be worded like DISSCUSSION doccuments,
or passed on because >the majority of the existing software does
whatever function a particular >way, and not really as standards.

Sounds very much like an Internet RFC (Request For Comments).

>Thinking about these things and also the current problem of the
>NA ** LOCATION ** code on the BBS Network and *.na top level
Internet >Domain, I started to wonder whether the Software
writers and Packet >Operators should put together a set of
Packet BBS "RFC like" documents, >called for example PBS's
(Packet BBS Standards)? (if they dont already >exist, or if they
do, make them much more widely known and formalised).

yes Yes YES!!! Please!

>If such a set of standards existed, it would be a good starting
place >for those wishing to write BBS software, and a good
starting point to >modify existing code to produce a uniform
network. Aspects that could be >formalised may include,

>BBS Forwarding - Definition of Forwarding Dialogue >BBS
Forwarding - BBS Header Standards >BBS Forwarding - Definition
of Standard Compression Algorithm >BBS Addressing - Hierarchial
Address Definition and Location Codes >BBS Addressing -
Hierarchial Address - Parsing Procedure >BBS Addressing -
Bulletin BID Definition, Message MID Definition >BBS Operation
- Gatewaying >BBS Operation  - White Pages

>just to name a few!

It seems to me that all of this has already been done to a great
extent. See RFC 821, RFC 1036, RFC 976, X.500.

>It is pretty obvious that this will be a monster task, but then
can >we afford not to do it?

Why? IT HAS ALREADY BEEN DONE! The only problem is that now that
we have established MSYS type BBS' as the *standard*, we'll
never be able to get rid of the fucking things! (Sorry Mark, you
can't gateway this one.) But people are too "scared" of TCP/IP
to use it. And this seems to me to be the ultimate irony - in
this age of "hi tech" appliance operators who only live to buy
rigs with more bells and whistles than the next guy, they
absolutely *refuse* to run a protocol with more bells and
whistles than the next one :-)  Go figure ...

--            atha!cs.athabascau.ca!lyndon ||
[e-mail]                    Packet:
[e-mail]        As a math atheist, I should be
excused from this.   --Calvin

------------------------------

Date: 31 Jul 91 22:28:37 GMT From:
lll-winken!sun-barr!ccut!wnoc-tyo-news!sranha!sramhb!futoshi@uune
t.uu.net Subject: 'NA' country domain appears to be non-unique
To: [e-mail]

In article <[e-mail]>
[e-mail] (Kenji Rikitake) writes:

 |BTW - PRUG do not forward any W0RLI/MSYS messages outside the
prug.or.jp |domain.

But, many people in PRUG domain want to read W0RLI/MSYS messages
with TERAKOYA or [BC]news system. So, I feed that messages to
someone want to read. (my system also join to AMPRnet-JA.)--

futoshi

------------------------------

Date: 31 Jul 91 22:21:33 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

Well well ... the issue of addresses comes up yet again!

To the folks who say "fix the software"  ... Let us hear your
suggestions.  Fix it how?  What should it do?

To the folks who say "fix the users" ... Please send that
article with the educational material to all the packet BBS
authors, we will be GLAD to send it out along with our code.

To the folks who say "the system is not compatible with
internet" ... Yup, it's not.  Should it be?  Why? What should be
done to make it compatible?

To the folks who write gateway code and/or run gateways ... Why
does this problem exist?

Let's take a look at a packet BBS network address:

W7QRM@K7QSY.#DRAIN.OR.USA.NA ^     ^     ^      ^  ^   ^ |     |
    |      |  |   | |     |     |      |  |   +-- Continent
designator |     |     |      |  +------ Country designator |
 |     |      +--------- State, etc. |     |
+---------------- Region within state |
+---------------------- Server ID +----------------------------
User Id

The user ID is unique, as it is a callsign. The server ID is
unique, same reason.

The first identifier is all that is actually required to address
any packet user.  However, using it would require that every
server either know all user ID's and how to route to them, or
have access to a server which knew that information.

The second identifier helps to group users into groups that can
be addressed with less information (the server ID).

The other designators (#DRAIN.OR.USA.NA) do  *NOT*  form a
network address in the traditional sense.  They are routing
hints. They look a lot like an internet address since they are
dot delimited fields.  They look a lot like a location since
they are constructed from geographic designators.  They are
neither, but simply routing hints.

The packet BBS network is quite different from the internet.
User ID's are gauranteed to be unique.  Server ID's are
gauranteed to be unique, with some exceptions we won't discuss
here.  Routings are fluid (at the hourly level), not fixed.
Users and servers come and go, move from one sub-domain to
another, change callsigns, etc.

The continent, country, state, and regional designators are
drawn from lists provided by the appropriate standard -
typically the ISO standards for naming regions.

Now what happens when one of these addresses passes from one
domain (the packet BBS network) to another network (say
FIDONET)? The address must be translated from one domain to the
other.

What has been happening?  People have used the packet BBS
network addresses as if they were internet addresses.  They are
not. It is certainly no surprise that strange things happen when
you do this!  It is a lot like attempting to call someone on the
telephone using their street address: it does not work.

Please reply via e-mail ... particularly those of you who
volunteer to write the user documentation we so badly need !

Hank Oredson @ Mentor Graphics Net   : [e-mail] Packet:
W0RLI @ W0RLI.OR.USA.NA Phone : [phone]

--

Hank Oredson @ Mentor Graphics Net   : [e-mail] Packet:
W0RLI @ W0RLI.OR.USA.NA

------------------------------

Date: 30 Jul 91 19:56:51 GMT From: timbuk![e-mail]
Subject: .NA addressing in PACKET To: [e-mail]

In article <[e-mail]>, [e-mail]
(WHITSITT, MARK STEVEN) writes: > Hey, maybe I am naive or
something about internet and packet (which is a real  >
possibility), but as I understand it, any gateway between
amateur radio packet  > networks and internet would have to be
watched very carefully at the gateway  > site by the CONTROL
OPERATOR.  This would be absolutely necessary at the  > internet
to packet side in order to avoid any possible problems like the
900  > bulletin problem (we all know abt that by now, nuff sed).
Allowing such gateways  > would in turn allow non-hams to get on
the ham packet network, amounting to  > third party traffic,
which would require the transmission of the info by a  >
licensed ham who is the CONTROL OPERATOR.   > [...]

Who says someone has to review messages going from packet to the
internet (the problem in this case..) ?

-andyw.    (W0/G1XRL)

[e-mail]    Andy Warner, Cray Research, Inc.    (612)
683-5835

------------------------------

Date: 31 Jul 91 14:54:00 GMT From: [e-mail]
Subject: DRSI PC*Packet Adapter Code To: [e-mail]

I'm posting the following for N9JR, please send any replies to
me (WV9Z).

{ I need the C source code for the DRSI PC*Packet Adapter to
query TNCTSR-S or TNCTSR-L in host mode.  My application is
simple.  I want to run PA0GRI/Bilow code for NOS with some of my
hacks, so I can run NOS and shell out and still control the
FT757GXII using some control program I have written, but I would
like to be able to add support for the DRSI so I can still have
HF packet and access to the local DX Packet Cluster on 220 MHz.
This would be a simple application to write if I had the C code
to "talk to" the WA8DED host mode under the DRSI tnctsr-s(-l).
The DRSI folks have never responded to my letter asking for the
code which has been advertised as available under their
manuals.-- Joe N9JR  }

Dan Larner  WV9Z Allen-Bradley Co., 1201 S. Second St.,
Milwaukee, WI 53204 ; [phone] Home: 2604 Aberdeen Ct.,
Waukesha, WI 53188 ; [phone]
[e-mail] (internet)
[e-mail] (AX.25)

------------------------------

Date: 30 Jul 91 18:03:40 GMT From:
news.hawaii.edu!uhccux!song![e-mail] Subject: IP numbers
for PMP sites. To: [e-mail]

In article <[e-mail]> [e-mail]
(Richard Jules) writes: >Hi, >   Could some one post the IP
numbers for helios.tn.cornell.edu and > csseq.cs.tamu.edu . I
received a site not know error. Thanks. >

song% host helios.tn.cornell.edu helios.tn.cornell.edu has
address 128.84.241.2 helios.tn.cornell.edu mail is handled by
HELIOS.TN.CORNELL.EDU song% host csseq.cs.tamu.edu
csseq.cs.tamu.edu has address 128.194.2.20 csseq.cs.tamu.edu
mail is handled by csseq.cs.tamu.edu

------------------------------

Date: 31 Jul 91 22:13:42 GMT From: [e-mail]
Subject: Local questions: To: [e-mail]

------------------------------

Date: 30 Jul 91 16:59:12 GMT From:
usc!cs.utexas.edu!oakhill!val![e-mail] Subject: Need help on
PK232 for tcp-ip To: [e-mail]

[e-mail] (Tom Varga) writes:

>I spend most of the weekend trying to set up tcp-ip on my
toshiba >laptop and the pk232.  I am having a terrible time at
it. I am using >the 6/91 version of net.exe (NOS).  So far I can
sometimes do a ping >successfully, but mostly I seem to get
checksum errors. (visible by >trace)

>Does anybody out there use the pk232 for tcp-ip?  What do I
need to do >to get to kiss mode if I use PC-pakratt for normal
packet?

>I would really appreciate some help or advice.  The documention
out >there is either very confusing or is out of date.  Took me
half a day >to figure out the hosts.net is no longer used!!

Tom,   It's possible that the baud rate between the computer and
the TNC is set too high for NOS to accept characters.  This is
due to various factors including interrupt latency, lack of
hardware buffer, etc.  If you haven't already done so, I
recommend replacing your UART chip with an NS16550AFN chip.
This has a hardware buffer (FIFO) which will improve things
dramatically.

   Another possibility is that you are running short on memory.
Use the memory status command to check this.

>Thanks, >Tom

--  Ben Thornton             packet:  [e-mail]
Video Associates       Internet:  [e-mail] Austin, TX
        uucp:  ...!cs.utexas.edu!val!ben

------------------------------

Date: 31 Jul 91 01:04:59 GMT From:
pacbell.com!mips!samsung!munnari.oz.au!manuel!ccadfa!rodos2!wkt@u
csd.edu Subject: Packet-Internet Gateways (was NA in headers)
To: [e-mail]

[ I include some email between me and Mark
[e-mail] because  it may be of some use. Deepest
apologies to Mark for breaking email  confidentiality - Warren ]

In email, Mark [e-mail] writes: > .. non-hams have
the same access to the information that we have, and there >
will always be hackers. Seeing who sent a message would be
simple enough from > the headers ...

Nope, believe me, it's fairly easy to forge mail and news, so we
cannot use these to authenticate messages.

However, if the gateways don't handle mail or news, then you
have to find a way of subverting the ip packet routing.  This is
the difficult part (on both sides of the brick wall) because ip
communication is a two-way thing, and the current situation is
that the amateur ip boxes don't know how to route packets to
internet boxes, and internet boxes don't know how to route to
amateur boxes.

Therefore, even if you DO get a naughty packet or two through
the gateway brickwall, the guys on the other side are not going
to know how to talk back.

So, for a non-ham to obtain effective communications with hams
(and thus transmit illegally), she would need a ham on the other
side of the gateway to do devious things too.

> I guess what bothers me is the automatic action of the  >
gateway, I don't totally trust software, cuz someone always
finds a loophole

That's always true. Our ham rules here prevent a transmitter
transmitting for more than 10 minutes continuously, but I've not
found any hardware or know of any software in my TNC to prevent
this from happening. If the Z80 in my TNC goes off into
never-never land with the PTT down, I'll break the law. But I've
yet to see anybody stop using a TNC due to this worry.

To wrap up then, you set up your system to be as secure as you
can make it. You have to place some trust in the system,
otherwise you might as well turn it off. And then you do a
reasonable amount of monitoring to ensure that security isn't
breached. And you react as fast as you can when it is breached.
You can't do more than that.

       Warren Toomey VK1XWT, slow kermiting.      Deep in the
bowels of ADFA Comp Science.  `The key that I thought opened the
door doesn't'

------------------------------

Date: 30 Jul 91 16:06:53 GMT From:
swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!w2xo!dur
[e-mail] Subject: Packet<->Internet Gateway Notes To:
[e-mail]

The Packet<->Internet gateway here is getting a lot of use, of
which I'm glad. However, there are some problems...

Problem #1: People mailing on *internet/usenet* to my *packet*
address (W2XO.#WPA.PA.USA.NA). This causes mail to be sent to a
nameserver in Namibia, in Africa! Please don't do this! Packet
is a separate service with different addressing conventions. The
correct way to mail to the gateway is "[e-mail]",
which is a valid internet address. 8-) . Unfortunately, US
domain internet addresses and packet "hierarchial" addresses
look very similar at first glance. The packet address is not
domain-style at all, it's geographical source routing. Yeah..I
know..it's crude, rude and gross, but I can't change the packet
dudes. I've tried 8-( . Fortunately, the packet token ".NA." is
being changed by a lot of folks to ".NOAM.", as there is a
".NA." being used by the Australian bbses for "North Australia",
I believe, and some of the bbs parsers are not done correctly so
this can be overriden by ".AUS." .

Problem#2: Mail sent to the correct address but with incorrect
formatting. Mail sent to the gateway must start with a packet
"send" command line as the first line of the text, and end with
a "/EX" in the first column of the very last line (After text
and sig). *Please* don't e-mail to *me* at the "bbs" user name.
This causes grief, since the mail scanner doesn't know what it
is and bounces it. Please use "[e-mail]" to email
to *me*.

Problem #3: Slow delivery from internet to packet. Sorry..can't
be helped. FCC holds ham radio bbses responsible for *content*
of all mail passed on the packet network, as was amply
demonstrated by the recent fines/citations in the Norfolk case.
I have to *read* all the stuff that goes out on packet, and I'm
not here all the time, so....sometimes it's fast, sometimes not.

Thanks for your time..

Jim Durham  (Internet: [e-mail])

    (Packet:W2XO@W2XO.#WPA.PA.USA.NOAM)

------------------------------

Date: 31 Jul 91 10:12:16 GMT From: [e-mail]
Subject: Problems with $ bulls. To: [e-mail]

I was amazed to see the message from a poster on this group
saying that a $ had to be appended to bulletins before they
would leave the originating bbs.

Do people in the USA still use MBL ?  I doubt there is one
system left in Europe using it for a number of reasons; the
above being one of them.

All the software in general use (RLI,FBB,NNA,YFB,WSD) does not
require this $ to be added by the user.  Perhaps those still
operating MBL  systems should be encourages to change !!

On a similar note, I saw reference to the fact that 2 letter
continent designators were being changed to 4 letter ones.
Nothing has percolated across to this side of the Atlantic about
this.  If you want people to  change perhaps you should tell us !

Back to being an over-worked and under-paid sysop......

------------------------------

Date: 1 Aug 91 04:08:16 GMT From: [e-mail]
Subject: So what's wrong with .NA ??? To: [e-mail]

On 28 Jul 91 18:30:27 GMT aupair.cs.athabascau.ca!lyndon (Lyndon
Nerenberg) said: > Subject : Re: 'NA' country domain appears to
be non-unique

> Please pay attention, people. The bogus .NA addresses being
talked > about have NO relation to the RFC822 mailers you all
know and love.

> These addresses are for use with a certain type of BBS package
> used on amateur packet radio. Their close similarity to RFC822
> address syntax is purely a mistake. No amount of headstanding
> with MX records is going to solve the "gateway" problem,
because > there IS no gateway problem. These are completely
seperate networks.

> Now, would all the people who refused to listen to some of us
when > we said the RLI/MSYS syntax was only going to cause
trouble please > line up against that concrete wall ... Once
again, amateur radio > demonstrates its ability to be at the
very trailing edge of technology.

Lighten up Lyndon ... there was no mistake ... the country codes
were already defined by the ITU in a document ... see our paper
in the 7th CNC ...

I fail to see what trouble this is causing anyone ... as you
point out, it is not causing the problem that the gateways may
have -- that is rooted in the flat domain we seem to have ...
and folks seem to be working around that too ...

You are correct - these are 2 separate networks -- and the
interesting thing is that the bbs side has now moved so much
mail that the purists awaiting a Utopian network will never
catch up ... new standards are being set - that may upset those
that feel that the wheel is being reinvented, but I think that
the jury is still out as to whether land-line defined systems
are going to survive a whole-scale, non-optimized move to radio
...

I guess I have a hard-time understanding why there is so much
discontent that someone is actually providing the service
element of this, while the "theorists" are left to their ivory
towers to ponder the meaning of packet existence, which is hwere
they say they want to be ?!  <flame off> Dave VE3GYQ (Canadian
IP address coordinator)

ria.ccs.uwo.ca!toth!dave

------------------------------

Date: 31 Jul 91 20:30:01 GMT From:
ucselx!sol.ctr.columbia.edu!caen!uakari.primate.wisc.edu!aplcen!w
b3ffv![e-mail] Subject: Update info on the WB3FFV BBS...
To: [e-mail]

        HOW TO ACCESS THE WB3FFV AMATEUR RADIO TELEPHONE BBS !!!

 I have placed a BBS system on-line that is mainly oriented
towards the  Amateur Community (but there is other stuff
on-line). As of now I have not attempted to promote this system
any place except in the amateur channels (PACKET, USENET, & word
of mouth), and will continue under this policy, as I hope to
keep it oriented toward amateur radio. The various software for
UP/DOWNload is available via telephone dialup and Packet TCP/IP,
and through user support I hope to keep the latest and greatest
ham software on-line. Below is the information that is needed in
order to access the BBS via Telephone -or- TCP/IP, please pass
it around to as many ham's as possible.

 System Name: WB3FFV User Login: bbs

 Number: (301)-625-0817 -- 1200,2400,4800,9600,19200,38400
                     (V.32/V.42/V.42bis/MNP1-5)

 Number: (301)-625-9482 --
1200,2400,4800,7200,9600,12000,14400,19200,38400
          (V.32/V.32bis/V.42/V.42bis/MNP1-5/HST)

 Number: (301)-625-9663 -- 1200 & 2400 (MNP1-5), 9600 & 19200
(PEP)

 Data Settings: 8 Bits, NO Parity, 1 Stop Bit Times:
24hrs/365days  (except for routine maintenance) Software: XBBS
(UNIX/Xenix Multiuser BBS) Version 7.91u IP Address: 44.60.128.1
{wb3ffv.ampr.org} [for FTP access on 145.650 mhz ONLY] Misc.
Info: Machine is an 80486 computer running UNIX V.3.2 and
features 800              Meg of on-line storage. Most transfer
protocols are available!!

  I attempt to keep the latest and greatest HAM software
on-line, and encourage all to upload anything new that they come
up with, as it is of benefit to all. Here is a sample of a
couple pieces of software that is available for DOWNLOAD:

 KA9Q TCP/IP Software for the PC (Latest OFFICIAL release + TEST
Versions)  KA9Q TCP/IP for the Atari-ST, MAC, & Amiga KA9Q
TCP/IP for UNIX based systems KA9Q TCP/IP (The NOS release)
[UNIX, MS/DOS, Amiga] KA9Q TCP/IP (Version by G1EMM, PE1CHL,
PA0GRI, Etc.) N2GTE Packet Message Switch [GTEPMS] (Version 1.2
& 1.3) WA7MBL BBS for the PC (Versions 3.31, 4.31 & 5.1[2,3,4])
W0RLI BBS for the PC (Versions 10.xx, 11.xx, 12.xx, 13.xx) MSYS
BBS for the PC running KISS TNC's  (Version 1.07-1.11) AA4RE BBS
for the PC (Version 2.11) Various BBS utilities and enhancements
Several MORSE CODE Tutors TheNet software by NORD><LINK
(Version 1.01 1.16 & 2.06) Modifications for many HAM Rigs and
Scanners Digital Signal Processing software (DSP) DX and
contesting programs ARRL Newsletters & Gateway W5YI Electronic
Edition

 There is much more available on the BBS, and I don't want to
waste a lot of PACKET BBS space trying to list it all, so if you
are interested give it a call and see for yourself !!!

If you are interested in using UUCP to connect to the BBS, this
can also be done as I support Anon-uucp. The login to the system
is 'uucpanon', and there  is NO password. The listing of
avalible archives are stored in a file called 'FILES', and it is
located in the /usr/spool/uucppublic. To retrieve the files
listing just use the following command:

uucp wb3ffv!~/FILES /usr/spool/uucppublic

This will move a copy of my files listing into your uucppublic
directory.  If you have any questions or problems, feel free to
contact me at one of the  numbers/adresses below. Good Luck...

-----------------------------------------------------------------
-------------Internet  : [e-mail]    |    Howard D.
Leadmon UUCP      : wb3ffv!howardl        |    Advanced Business
Solutions TELEX     : 152252474             |    210 E. Lombard St -
Suite 410 FAX       : [phone]              |
Baltimore, MD 21202  PACKET    : WB3FFV @ WB3FFV.MD.USA.NA   |
    Phone: [phone]

------------------------------

Date: 30 Jul 91 19:53:45 GMT From: timbuk![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail]>
Subject : Re: 'NA' country domain appears to be non-unique

In article <[e-mail]>, [e-mail] (Jay
Maynard) writes: > [...] > Don't complain about a working system
unless you're prepared to implement > an alternative. The
hierarchical naming convention works well. It's the > users who
need to be fixed...in this case, educated that sending mail to >
a BBS address in North America from an Internet node will
instead result > in that mail getting sent to Namibia, and, most
likely, bounced there. > [...]

But we should be allowed to complain about the implementation of
a system which is beginning not to work (especially when it's on
the trailing edge of technology.)

-andyw.    (W0/G1XRL)

[e-mail]    Andy Warner, Cray Research, Inc.    (612)
683-5835

------------------------------

Date: (null) From: (null) I think the problem stems from the
fact that we started off with only one or two BBS programs, and
the authors of those programs managed to keep them fairly
compatible. However, there are now people all over the world
writing BBS software, and a lot of them don't know what is
happening in other countries. It also seems that everyone wants
to change something just to make their system stand out from the
others (just look at all the different headers).

As you say, it will probably be very difficult to come up with a
set of standards that everyone will agree to, but if we don't
start doing it now then it will soon become impossible.

Brian G1NNA

------------------------------

Date: 31 Jul 91 00:56:05 GMT From:
pa.dec.com!jrdzzz.jrd.dec.com!jrd.dec.com![e-mail]
 To: [e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Reply-To :
[e-mail] Subject : Re: 'NA' country domain appears
to be non-unique

In article <[e-mail]>,
[e-mail] (Lyndon Nerenberg) writes: :As I said
before, the problem is not with gatewaying. The problem :lies in
the very poor choice of address syntax chosen by the AX.25 :BBS
software authors.

I once heard that W0RLI (The author of the W0RLI systems) did
NOT intend to enhance his system in this way.

:However, how do you explain these sort of problems to the
:technically illiterate "appliance operator" that typifies
amateur :radio today? They have something that works for *them*
so obviously :the rest of the world is at fault and should
change their ways. :I like this about as much as you do, but the
bottom line is it's :an attitude that we are stuck with in the
amateur community today.

True. You are correct. And that's why I feel strong resentment
to "Amateur Radio" itself right now. I personally do not want to
forward ANY W0RLI/MSYS messages to the Internet/USENET
community, unless W0RLI/MSYS sysops COMPLETELY UNDERSTAND the
Internet/USENET naming schemes and INVENT their way to convert
names. FIDOnet have successfully done this.

BTW, one of PRUG members have written a conversion program
between W0RLI/MSYS messages and RFC1036 ones. He runs it on our
network and works nicely.

:The result of this attitude will be a LOT of ill will from the
:Internet community at large when this group of appliance
operators :refuses to change their operating habits. And believe
me, they :WON'T change!

I know. PRUG members have tried many times to convince
W0RLI/MSYS operators in Japan in vain. :-<

:[e-mail] (Kenji Rikitake) writes: :>The PRUG has
been using a domain name "prug.or.jp" and IP network number
:>133.168, since January 1990. I don't want USENET people to
think that :>ALL packet radio guys are ignoring the Internet
policy and rules.

:And not all of us are. But we are a minority when compared to
the :total number of packet operators who have never heard of
TCP/IP. :(Or even worse, those who have and refuse to
acknowledge that it :might be of use, just because they don't
understand it.)

Being a minority is not a problem. The main point is how to
integrate two different cultures of networks. And I do not want
to change my principles, just because lots of packet radio
operators do not understand what the Internet is.

BTW - PRUG do not forward any W0RLI/MSYS messages outside the
prug.or.jp domain.

-- Kenji, [e-mail]

------------------------------

Date: (null) From: (null) Your assumption is false. My software,
and a lot of other software, does not require the $.

>    Another case in point was the propensity of the original
hierarchical > addressing software to scan from left to right: a
procedure which meant, for > example, that 'WA' (for Western
Australia) couldn't be used due to probable > confusion with
Washington State. Rather than modify the software, the solution
> proposed was to use 'WA' for Washington, and '#WA' for Western
Australia. >    Both of these were elevated to the 'it's not a
bug: it's a feature' category > and became almost impossible to
change. >    Why not just change the software and make it easier
on everybody? >  > .....Ron >

I love the way you say `just'. You must bear in mind that all
packet BBS software (at least as far as I am aware) is written
and distributed by people who spend a great deal of time and
money in producing something which is then given away free of
charge. Changes are made if it is found that something doesn't
work as well as it was originally thought, but those changes do
take time, because they have to be fitted in to whatever little
spare time is available to the software writers. Any changes
which require co-ordination between the various software writers
take longer because there are quite a few of them spread around
the world (I can think of 4 in the USA, 3 in the UK, 1 in France
and 1 in Germany off the top of my head). Changing something as
fundamental as the heirarchical addressing scheme is going to be
very difficult, because both the old and the new scheme would
have to be run in parallel until everyone was capable of
supporting the new one.

Don't assume that we aren't doing our best to improve the
system. You ask any packet BBS software writer, and they will
show you a list of requested changes as long as your arm. It
might take us a while, but we will get there as soon as we can.

Brian G1NNA

------------------------------

Date: (null) From: (null) As far as I know, only the WA7MBL
software requires this.

>    Another case in point was the propensity of the original
hierarchical > addressing software to scan from left to right: a
procedure which meant, for > example, that 'WA' (for Western
Australia) couldn't be used due to probable > confusion with
Washington State. Rather than modify the software, the solution
> proposed was to use 'WA' for Washington, and '#WA' for Western
Australia.

Solved in AA4RE V2.11 available for many months now.  Wildcards
in the routing file look like this:

WA\.USA\.NA

This matches WA, WA.USA, and WA.USA.NA but not WA.AU.  The "\"
(backslash) means that the string to the right is optional but
must match if present.  The scan goes left to right so that
anything before the WA is ignored thus #NWA.WA will match
correctly.  If you want the field in front of the WA to be
useful, you have to code for it.

Note that the use .NOAM poses a problem now.  We must either all
switch or not.  I have had to circumvent this in my routing
tables by using WA\.USA\.N* (the N* matches anything starting
with N) but you can see the side effects of this.

Roy, AA4RE

------------------------------

End of Packet-Radio Digest V91 #193
****************************** Date: Fri,  2 Aug 91 04:30:06 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #194 To: packet-radio

Packet-Radio Digest         Fri,  2 Aug 91       Volume 91 :
Issue 194

Today's Topics:             'NA' country domain appears to be
non-unique                       .NA and other atrocities
            Academic research by amateurs             BBS Mail
Standards -- Stagnant or Evolving? Forwarding W0RLI/MSYS
messages in AMPRnet-JA (Re: 'NA' country domain appears to be
non-unique)               Messages from internet domain to
packet                     NOS and forwarding NTS stuff
           So what's wrong with .NA ???        Where do I find
out about the KISS protocol. (2 msgs)

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 1 Aug 91 17:31:17 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

  My comments with "***"  (no, I don't have a good news poster
available ... sorry).

  Note that the country identifiers chosen by the packet network
 correspond to ISO 3166-1981(E/F).  This is part of the EDIFACT
standard, and is in much wider use than any other standard I'm
personally aware of.  These are 3 letter ids.  We chose two
letter continent IDs for no particular reason.  Changing to  4
letter continent IDs would not change much of anything, the
underlying problem remains the same.

  If there are other standards we bbs authors should consider,
we need to be made aware of them.  At least some of us come
from a world far from unix, where we have moved data around  the
world since way before unix existed ...

  We don't all have access to the various standards documents
referenced in this thread.  PLEASE SEND US COPIES VIA E-MAIL!
If we knew what you were all talking about, we might actually
go and do something!

  If you think about the structure of the packet radio network,
how it interconnects, you will see major differences with the
way a wired network (e.g. the various parts that make up the
internet) work.  The standards developed for the packet network
function in different ways because they need to ...

   ...  Hank  - W0RLI

-----------------------------------------------------------------
----From: [e-mail] (Grant Willis VK5ZWI)
Subject: Re: 'NA' country domain appears to be non-unique
Keywords: Packet BBS Version of Internet RFC's Message-ID:
<[e-mail]>

I guess a problem like this had to crop up eventually, but I
think it exposes a larger underlying problem with the Packet
Radio BBS Network. I have been a BBS SysOp for a couple of years
now and have also been involved in writing a BBS Program
(RTTYGate RTTY><Packet Gateway). In that time I dont recall
seeing any documents that set down the standards for the
operation of the BBS system.

I have seen several discussion documents (and would love to see
the one explaining the 4 letter continent designators) on mainly
the Hierarchial addressing but nothing on how BBS forwarding is
supposed to be conducted, how headers should be formulated and
only small amounts on White Pages and BID/MID's. All of these
seemed to be worded like DISSCUSSION doccuments, or passed on
because the majority of the existing software does whatever
function a particular way, and not really as standards.

Thinking about these things and also the current problem of the
NA ** LOCATION ** code on the BBS Network and *.na top level
Internet Domain, I started to wonder whether the Software
writers and Packet Operators should put together a set of Packet
BBS "RFC like" documents, called for example PBS's (Packet BBS
Standards)? (if they dont already exist, or if they do, make
them much more widely known and formalised).

If such a set of standards existed, it would be a good starting
place for those wishing to write BBS software, and a good
starting point to modify existing code to produce a uniform
network. Aspects that could be formalised may include,

*** > BBS Feature ID - SID grammer and use.  Assigned feature
IDs. BBS Forwarding - Definition of Forwarding Dialogue BBS
Forwarding - BBS Header Standards BBS Forwarding - Definition of
Standard Compression Algorithm BBS Addressing - Hierarchial
Address Definition and Location Codes BBS Addressing -
Hierarchial Address - Parsing Procedure BBS Addressing -
Bulletin BID Definition, Message MID Definition BBS Operation  -
Gatewaying BBS Operation  - White Pages

just to name a few!

It is pretty obvious that this will be a monster task, but then
can we afford not to do it? As the BBS net becomes more and more
connected to other networks, problems like the NA Address will
no doubt become more prevelent. Getting all BBS Software to
conform will take time as new versions will need to be written
and the Thousands of BBS's world wide upgrade to the new
software but I think it is a step that should be taken.

I would like to hear others thoughts on this. I am not
volenteering to write them, that should be a co-operative
activity amongst ALL BBS software writers but I do believe that
if we dont move in a similar direction to this that the Packet
Network will run into more and more problems in the future.

Cheers de Grant VK5ZWI

***  I distribute a set of documents with my code that describe
***  the standards presently in use for all of the items you ***
 mention.  They would make a starting point.  Please e-mail ***
me anything you write up, I'll include it with the next ***
distribution.  ...  Hank

From: [e-mail] (Brian Lloyd) Subject: Re: 'NA'
country domain appears to be non-unique Message-ID:
<[e-mail]> Reply-To:
[e-mail] Organization: British Telecom Labs

I think this is a good idea. At present just about the only way
you can implement a new feature that someone else has come up
with is to get a copy of their software, run it, and try to work
out the protocol (or whatever). This is obviously far from ideal.

I think the problem stems from the fact that we started off with
only one or two BBS programs, and the authors of those programs
managed to keep them fairly compatible. However, there are now
people all over the world writing BBS software, and a lot of
them don't know what is happening in other countries. It also
seems that everyone wants to change something just to make their
system stand out from the others (just look at all the different
headers).

As you say, it will probably be very difficult to come up with a
set of standards that everyone will agree to, but if we don't
start doing it now then it will soon become impossible.

Brian G1NNA

***  Brian, if we (the various authors) all exchanged
information via the ***  packet network, we could remain in
synch.  For example, I plan to ***  implement rfc-822 style
forwarding in my next release.  I'll probably ***  just choose a
random SID feature ID ("R" ?, no Roy has used that, ***  "S" ?,
seems to be unused ...). ***  As a longer term solution, we need
a coordinating body.  Oh no ... ***  i.e. a clearing house that
can collect and distribute the required ***  information.  Many
of us have asked ARRL to take on this function. ***  They have
refused.  Perhaps (RSGB / WIA / PRUG) would be interested? ***
We also need coordination and distribution of MANY other data.
***  Example: bulletin grouping and distribution designators.
***  It's time to move ahead with the 'next step' in the packet
BBS network. ***  We've been at about the same place for seven
years now ... ***    ...  Hank

--

Hank Oredson @ Mentor Graphics Net   : [e-mail] Packet:
W0RLI @ W0RLI.OR.USA.NA

------------------------------

Date: 1 Aug 91 23:47:31 GMT From: [e-mail]
Subject: .NA and other atrocities To: [e-mail]

In response to Brian Kantor's observations: I cannot say why
they chose the  .  as the separator  ... I believe that they
(Hank) felt that it would not be a problem, and I believe he
still believes that ... I think he does read the list (or at
least tcp-group) so he may hop in here ... Personally, I do not
user the continental codes in routing. I am not convinced that
you can base routing on continents, when Israel and Japan are
both in Asia ... So to answer your question, no, the country
codes are not too long to search ... I aplogozize for missing
the start of this thread - is the continental designator somehow
the big stumbling block ???

And you mean to tell me that you are not fully X.400 yet ???

Someone has to be the first ! <grin>

73, Dave VE3GYQ

ria.ccs.uwo.ca!toth!dave

------------------------------

Date: 2 Aug 91 05:34:20 GMT From:
munnari.oz.au!manuel!ccadfa!rodos2![e-mail] Subject:
Academic research by amateurs To: [e-mail]

Hi all,        This may not be the best place, but can anyone
give me some references to research papers involving digital
radio communications, which were written by amateurs. I am
currently knocking up a paper about packet/Internet gateways to
sway the minds of some of the Universities here in Oz (who
`control' Internet access), and need to be able to place amateur
packet activity on a research footing. So any references, such
as ftp sites, abstracts, proceedings etc.) would be most welcome.

Thanks,

       Warren Toomey VK1XWT, cold but happy      Deep in the
bowels of ADFA Comp Science.  `POSIX Job Control?! POXY job
control more like!'

------------------------------

Date: 1 Aug 91 22:48:27 GMT From:
usc!cs.utexas.edu!helios!cs.tamu.edu![e-mail] Subject:
BBS Mail Standards -- Stagnant or Evolving? To:
[e-mail]

[e-mail] (Hank  - W0RLI) writes [some reasonable
comments, and some others:...]

" If there are other standards we bbs authors should consider,
we need to be made aware of them.  At least some of us come
from a world far from unix, where we have moved data around  the
world since way before unix existed ..."

Two problems: One, I assume you're not trying to imply packet
electronic mail existed before Unix. Or that it even existed
before TCP/IP. There were and are standards that could be
applicable.  Although I  do not understand how one could avoid
knowing of the RFCs, I'm sending you by email a copy of the
index.  Any you need, let me know & I'll send those on.

" If you think about the structure of the packet radio network,
how it interconnects, you will see major differences with the
way a wired network (e.g. the various parts that make up the
internet) work.  The standards developed for the packet network
function in different ways because they need to ..."

Yes, there are *some* differences {most notably in that the
packet radio net is not fully connected}.  In fact, the current
packet BBS system looks a lot like Usenet (systems connected
only thru UUCP).  The standards we are talking about do not,
however, "function in different ways because  they need to"
{your quote}.  Functionally, I think the packet BBS system is
identical to Usenet -- yet there are different schemes.
Probably 'cause different people thought them up without really
looking at one another's  work.

It's true that the Internet naming & mail system is not the
*only* one around.  It's also true that the BBS s/w did *not*
directly cause the problem that started this thread.  It *is*
true that protocols that may have evolved in isolation should
take into account the current environment, which includes SMTP &
UUCP & the Domain Name System.  The code written by you and
others has been a great help in getting packet BBS mail exchange
started.  Don't assume it shouldn't grow or change.

Want a specific hint?  (1) Don't use "." as the separator in
your  geographical routing. (2) Separate routing hints from a
user's address {might help for really mobile stations}.  BTW,
while sending this I tried to send you mail, with the result
shown  below.  If you'll send mail to [e-mail], I'll
try to
reply.-----------------------------------------------------------
------------From [e-mail] Thu Aug  1
17:30:53 1991 Received: from mgc.mentorg.com by
neuron.cs.tamu.edu (AA22032); Thu, 1 Aug 91 17 :29:19 CDT
Received: from NEURON.TAMU.EDU by mgc.mentorg.com with SMTP
  (15.11/15.5+MGC-TD 2.20) id AA02882; Thu, 1 Aug 91 15:28:52
pdt Date: Thu, 1 Aug 91 17:26:40 CDT From: Mail Delivery
Subsystem <[e-mail]> Subject: Returned
mail: User unknown Message-Id:
<[e-mail]> To: <[e-mail]>
Status: R

   ----- Transcript of session follows -----

While connected to mentorg.com [110.0.0.11] (tcp): >-> RCPT
To:<[e-mail]> <<< 550 <[e-mail]>... User
unknown 550 <[e-mail]>... User unknown

------------------------------

Date: 1 Aug 91 03:53:16 GMT From:
pa.dec.com!jrdzzz.jrd.dec.com![e-mail] Subject:
Forwarding W0RLI/MSYS messages in AMPRnet-JA (Re: 'NA' country
domain appears to be non-unique) To: [e-mail]

This should rather be treated as a local issue within PRUG, but
I would like to clarify things, so I post it here.

In article <[e-mail]>,
[e-mail] (Futoshi Miyamori) writes: ]In article
<[e-mail]> [e-mail] (Kenji
Rikitake) writes: ] |BTW - PRUG do not forward any W0RLI/MSYS
messages outside the prug.or.jp ] |domain.

]But, many people in PRUG domain want to read W0RLI/MSYS
messages with ]TERAKOYA or [BC]news system. So, I feed that
messages to someone want to ]read. (my system also join to
AMPRnet-JA.)

I see no problem on forwarding W0RLI/MSYS messages on the
AMPRnet-JA (A radio USENET system using KA9Q SMTP facility and
Terakoya news cruncher/reader/poster kit, running in Japan, with
prug.or.jp and genesys-p.or.jp).  I don't want W0RLI/MSYS
messages forwarded out of prug.or.jp, because PRUG cannot be
responsible to things written in there.

-- Kenji

------------------------------

Date: 1 Aug 91 21:31:35 GMT From: gatech!prism![e-mail]
Subject: Messages from internet domain to packet To:
[e-mail]

I have heard that there are packet<->internet gateways, although
they must be monitored before going out over the air.  Does
anyone have any information on any of these gateways and how to
use it?

I've got my tech ticket, but no access to packet yet, and I
wanted to drop a note to N6KK in california.

--Pete--  Peter L. Thomas (Junior AE) "Figures never lie, but
liars always figure." Georgia Institute of Technology, Atlanta
Georgia, 30332 Internet: {gt5139c,ce202a2}@prism.gatech.edu

------------------------------

Date: 1 Aug 91 07:15:23 GMT From:
cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.na
sa.gov!ncar!asuvax!stjhmc![e-mail] Subject:
NOS and forwarding NTS stuff To: [e-mail]

Hi, I just got NOS up and running.  If anyone is using NOS to
forward NTS  traffic to/from AX25 stations, or just email back
and forth with AX25, I  would appreciate hearing from you.

Please send me email, and include a voice telephone if you don't
mind a phone  call.

Thank you.

David WB7TPY

----

--
-----------------------------------------------------------------
--------          St. Joseph's Hospital and Medical Center,
Phoenix, Arizona        uucp: {gatech, ames,
rutgers}!ncar!asuvax!stjhmc!ddodell    Bitnet: ATW1H @ ASUACAD
                 FidoNet=> 1:114/15    Internet:
[e-mail]       FAX: [phone]

------------------------------

Date: 1 Aug 91 13:54:02 GMT From:
sdd.hp.com!cs.utexas.edu!utgpu!nrcnet0!bnrgate!bwdls61!bnr.ca!mle
[e-mail] Subject: So what's wrong with .NA ??? To:
[e-mail]

In article <[e-mail]>, [e-mail] (David
B. Toth) writes: |>... |> I guess I have a hard-time
understanding why there is so much discontent |> that someone is
actually providing the service element of this, while the |>
"theorists" are left to their ivory towers to ponder the meaning
of packet |> existence, which is hwere they say they want to be
?!

Oh, crap, Dave.

There *are* people working on the "service element".  Somewhat
slowly, since there's little point to providing "services"  on a
network that doesn't work.  I can't get very excited about
providing  21st century services on a network that is currently
firmly planted in  the late 1960s.  Real-world "wired" networks
move orders-of-magnitude  more mail/news/files with much higher
reliability than the network you  hold up as a shining example.
That paradigm *can* be moved into the  packet-radio domain, but
until we get more buy-in from die-hard  NETROM/PBBS/AX.25
addicts, progress is going to be slow and tedious.

Until we "ivory tower types" can get a decent highspeed/modern
network in  place, there is little point in providing whizzo
services.

|>  |> Dave VE3GYQ |> (Canadian IP address coordinator) |>  It's
very sad that an IP address coordinator has such narrow vision.

-Marcus Leech, 4Y11             Bell-Northern Research
|opinions expressed [e-mail]                  P.O. Box
3511, Stn. C   |are my own, and not [e-mail]
  Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

------------------------------

Date: 1 Aug 91 16:31:15 GMT From:
bonnie.concordia.ca!ccu.umanitoba.ca!bison!sys6626!inqmind!walzer
@uunet.uu.net Subject: Where do I find out about the KISS
protocol. To: [e-mail]

I would like to know how KISS works. What is the format of the
frames? What about extensions such as parameter setting? I have
the impression it's a pretty simple protocol.

Has anyone ever seen a description of KISS? Or does everyone
just figure it out from various hunks of source code?

And no, I don't know how SLIP works either if that makes any
difference (I heard it was like KISS).

Thanks, Bruce Walzer VE4XOR

[e-mail] The Inquiring Mind BBS, Winnipeg,
Manitoba  204 488-1607

------------------------------

Date: 2 Aug 91 00:34:48 GMT From:
munnari.oz.au!manuel!ccadfa![e-mail]
 Subject: Where do I find out about the KISS protocol. To:
[e-mail]

------------------------------

Date: (null) From: (null) Yep, sure is. If you can anonymous
ftp, ftp to ucsd.edu, cd to hamradio/ka9q/arrl/1987, and get
kisstnc.ms.Z, binary-wise. Uncompress, and nroff -ms it!

Cheers,

       Warren Toomey VK1XWT, cold but happy      Deep in the
bowels of ADFA Comp Science.  `POSIX Job Control?! POXY job
control more like!'

------------------------------

End of Packet-Radio Digest V91 #194
****************************** Date: Sat,  3 Aug 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #195 To: packet-radio

Packet-Radio Digest         Sat,  3 Aug 91       Volume 91 :
Issue 195

Today's Topics:        'NA' country domain appears to be
non-unique (2 msgs)                     .NA and other noxious
things                          KA9Q SLIPDIAL.DOC
   Packet<->Internet Gateway Notes
PACTOR Information                          PK-232 and IC-2GE
              PTC, PACTOR Controller Information

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 2 Aug 91 16:50:33 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

***  In comments re Dave Toth's response to the .NA silliness,
***  Marcus Leach comments:

From: [e-mail] (Marcus Leech) Newsgroups:
rec.radio.amateur.packet Subject: Re: So what's wrong with .NA
??? Date: 1 Aug 91 13:54:02 GMT

In article <[e-mail]>, [e-mail] (David
B. Toth) writes: |>... |> I guess I have a hard-time
understanding why there is so much discontent |> that someone is
actually providing the service element of this, while the |>
"theorists" are left to their ivory towers to ponder the meaning
of packet |> existence, which is hwere they say they want to be
?!

Oh, crap, Dave.

There *are* people working on the "service element".  Somewhat
slowly, since there's little point to providing "services"  on a
network that doesn't work.  I can't get very excited about
providing  21st century services on a network that is currently
firmly planted in  the late 1960s.  Real-world "wired" networks
move orders-of-magnitude  more mail/news/files with much higher
reliability than the network you  hold up as a shining example.
That paradigm *can* be moved into the  packet-radio domain, but
until we get more buy-in from die-hard  NETROM/PBBS/AX.25
addicts, progress is going to be slow and tedious.

Until we "ivory tower types" can get a decent highspeed/modern
network in  place, there is little point in providing whizzo
services.

|>  |> Dave VE3GYQ |> (Canadian IP address coordinator) |>  It's
very sad that an IP address coordinator has such narrow vision.

***  What a bunch of nonsense! ***  Marcus - WHERE is this work
that is going on? ***  Please e-mail me some status information
about it. ***  I'm one of those "die-hard NETROM/PBBS/AX.25
addicts" you talk about. ***  I've seen NOT ONE PROPOSAL that
realistically suggests anything ***  better than what we have
now.  What we have now works pretty well. ***  If there is
something better we could do, we'll do it. *** ***  i.e.  your
negative comments do not move things forward. ***  "Don't tell
me what NOT to do, tell me WHAT to do." *** ***  ...  Hank -
W0RLI--

Hank Oredson @ Mentor Graphics Net   : [e-mail] Packet:
W0RLI @ W0RLI.OR.USA.NA

------------------------------

Date: 2 Aug 91 17:07:24 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

From: [e-mail] (Willis Marti) Newsgroups:
rec.radio.amateur.packet Subject: BBS Mail Standards -- Stagnant
or Evolving? Date: 1 Aug 91 22:48:27 GMT Sender:
[e-mail]

[e-mail] (Hank  - W0RLI) writes [some reasonable
comments, and some others:...]

" If there are other standards we bbs authors should consider,
we need to be made aware of them.  At least some of us come
from a world far from unix, where we have moved data around  the
world since way before unix existed ..."

Two problems: One, I assume you're not trying to imply packet
electronic mail existed before Unix. Or that it even existed
before TCP/IP. There were and are standards that could be
applicable.  Although I  do not understand how one could avoid
knowing of the RFCs, I'm sending you by email a copy of the
index.  Any you need, let me know & I'll send those on.

***  Ummm ... yes, I did indeed imply that e-mail existed before
unix. ***  Didn't say anything about 'packet' since the
transmission protocol ***  really makes little difference.  I've
used e-mail since about 1967. ***  Wrote my first e-mail system
in about 1969 or 1970.  No, it had ***  nothing to do with
packet, unix, or the internet.  It had a little ***  bit of
influence from and on early arpanet.  i.e. PDP-11 and mainframe
***  technology using at first bisynch and asynch connections,
and later ***  on early packet technology.  Moved away from that
stuff in about ***  1972 and have been doing other things since.
 Thus no access to the ***  various rfcs unless someone sends
them to me.  Will send you a list ***  of those that I'm
missing.  In particular, I need up-to-date copies ***  of x.400
and x.500 and rfc-1036.  I do have rfc-822 itself.

" If you think about the structure of the packet radio network,
how it interconnects, you will see major differences with the
way a wired network (e.g. the various parts that make up the
internet) work.  The standards developed for the packet network
function in different ways because they need to ..."

Yes, there are *some* differences {most notably in that the
packet radio net is not fully connected}.  In fact, the current
packet BBS system looks a lot like Usenet (systems connected
only thru UUCP).  The standards we are talking about do not,
however, "function in different ways because  they need to"
{your quote}.  Functionally, I think the packet BBS system is
identical to Usenet -- yet there are different schemes.
Probably 'cause different people thought them up without really
looking at one another's  work.

***  The major difference (from a routing point of view) is that
the ***  connectivity changes on a short term basis.  As far as
I know, the ***  network is indeed fully connected, but NOT at
layer 2, for example. ***  If you think top down, from a layer 7
viewpoint, then it is indeed ***  fully connected.  As an
application writer, my main interest is ***  in those things
that support layer 7 services.  The fact that the ***  best we
can do right now is layer 4 (with some implied layer 5/6 ***
interfaces) does not stop me from creating useful applications,
***  it just makes it a whole lot harder.

It's true that the Internet naming & mail system is not the
*only* one around.  It's also true that the BBS s/w did *not*
directly cause the problem that started this thread.  It *is*
true that protocols that may have evolved in isolation should
take into account the current environment, which includes SMTP &
UUCP & the Domain Name System.  The code written by you and
others has been a great help in getting packet BBS mail exchange
started.  Don't assume it shouldn't grow or change.

***  We also need to take into account other existing standards,
for example ***  those standards promulgated by the United
Nations.  I'm speaking, ***  of course, of EDIFACT and x.12 and
all the ISO work on domain namings. ***  The fact that usenet
has chosen to ignore that standards work and go ***  off on it's
own is no excuse ...

Want a specific hint?  (1) Don't use "." as the separator in
your  geographical routing. (2) Separate routing hints from a
user's address {might help for really mobile stations}.

***  Oh fudd ... the problem is not in the name, nor in the
grammer of ***  the name.  The problem is with the software that
uses the names. ***  The internet name domain and the packet BBS
name domain are disjoint. ***  There is the obvious cure:
gateways need to handle the names properly. ***  We could
establish a simple convention: for example, append .ampr.org ***
 to the BBS net names when they are displayed in the internet
world.  BTW, while sending this I tried to send you mail, with
the result shown  below.  If you'll send mail to
[e-mail], I'll try to reply.

***  Try [e-mail] ***  We are in process of
improving our connections with the world, ***  and guess what?
Old names don't work.  Now if this was the BBS net, ***  you
could just query WP and find out where I was ... but it isn't
... ***  i.e. usenet technology lags behind BBS net technology
in many ways. *** ***   ...  Hank - W0RLI

--

Hank Oredson @ Mentor Graphics Net   : [e-mail] Packet:
W0RLI @ W0RLI.OR.USA.NA

------------------------------

Date: 3 Aug 91 01:38:06 GMT From: [e-mail]
Subject: .NA and other noxious things To: [e-mail]

Thanks to Brian and Bob for bringing me up to speed re .NA and
Namibia ... Sorry I appeared so dense, but I could not see what
the problem had been ... I agree - that IS a problem ... I'll
see if Hank watches the newsgroup and hopefully he will chime
in. Brian/Bob: is this a problem of general users/gateways/or
what ??? Just want to know where the biggest problem is ... I
doubt we could make a gateway smart enuff to overcome a PDU
(poor dumb user) <grin> Dave VE3GYQ

ria.ccs.uwo.ca!toth!dave

------------------------------

Date: 1 Aug 91 18:32:23 GMT From:
agate!apple!mips!swrinde!emory!wa4mei!nanovx!msa3b!kevin@ucbvax.b
erkeley.edu Subject: KA9Q SLIPDIAL.DOC To: [e-mail]

I'm looking at a message, posted to rec.ham-radio.packet, back
in December of '89. This message describes an extension to the
KA9Q attach command, to support modem-dialing.  Syntax is:

  attach <hw type> <I/O address> <vector> <mode> <label>
<bufsiz> <mtu>         [<speed>] [[optional '-' for debug]
<send> <expect <send> [...]]

However, when I enter:  attach asy 0x3f8 4 slip sl0 1024 256
9600 - ATDT5551212 CONNECT

NOTHING is sent to the modem, and the NOS prompt returns. I've
got NOS1130D.EXE.  The doc that came with it describes a
"DIALER" command, that my NOS does not recognize as a valid
command.

What do I have to do to get KA9Q do dial a modem for SLIP?--
Kevin Kleinfelter @ DBS, Inc [phone]
...gatech!nanoVX!msa3b!kevin

Dun&Bradstreet Software, 3445 Peachtree Rd, NE, Atlanta GA
30326-1276

------------------------------

Date: 2 Aug 91 18:39:09 GMT From:
sdd.hp.com!wupost!udel!haven.umd.edu!uvaarpa!murdoch!usenet@ucsd.
edu Subject: Packet<->Internet Gateway Notes To:
[e-mail]

  If Jim Durham and everyone else would not appreviate "packet
radio" to just "Packet" there would be A LOT less confusion.

  Recall that almost all computer networks are based on packet
transmissions, so a computer network person could legitimately
read "packet" and think computer network.

Please change to use "Packet Radio" instead of just "Packet" and
help avoid accidental confusion...

------------------------------

Date: 2 Aug 91 16:01:56 GMT From:
mcsun!cernvax![e-mail] Subject: PACTOR Information To:
[e-mail]

Find below the official PACTOR information brief from the WAA
Group. Any uncomprehensible errors is probably due to the laser
scanner and the accompaning translation software.

*****************************************************************
***

  THE WAA GROUP
     4/91

                  P A C T 0 R   Short system description

                              1. Introduction

  AMTOR and PACKET RADIO (PR) have become rather  popular  ARQ
techniques  in  Amateur  Radio.  Nevertheless,  concerning
poor-quality   channels,  their performance is far from optimum.
 AMTOR, matched  to  old  mechani-  cal teletype technology,
represents the state-of-the-art some  20  years  ago; PR was
adopted from the X.25 protocol for data  exchange  on  high-
quality telegraph lines.  PACTOR (PT), specially designed for
operation in noisy  and  fluctuating  channels, is an improved
half-duplex synchronous  ARQ  system  combining  the reliability
of PR with the fixed AMTOR time frame.

  Principal design considerations:

  PACTOR comprises all important AMTOR or PR (2-way)
characteristics:

  - fixed timing structure and full synchronism to ensure
maximum speed  - fast and reliable changeover / break-in  -
required bandwidth less than 600 Hz  - 100% ASCII compatible
(true binary data transmission)  - extremely low probability of
undetected errors (16 bit CRC)  - independent of shift
polarities  - no multi-user overhead in a narrow-band channel  -
inexpensive hardware (Z80 single-board)  - high operational
comfort (built-in message storage system, etc.)  - listen-mode
(monitor)  - FEC-mode (CQ-transmissions etc.)

  As a novelty in Amateur RTTY, some  additional  powerful
features  have  been realized:

  - optional  coherent  mode,  i.e.  system  clocks  locked  to
frequency    standards (e.g. DCF77, TV deflection signals  and
other  high  preci-    sion broadcasts)  - online data
compression (Huffman coding)  - automatic speed change (1001200
baud)  without  loss  of  synchroniza-    tion  - fully
acknowledged link termination (no QRT-timeout required)  -
memory ARQ (even noisy packets can be restored)

                          II. Some system details

  1 . Timing

  The basic PT  transmission  frame  is  very  similar  to
AMTOR;  blocks  (packets) containing data information are
acknowledged  by  short  con-  trol signals (CS) sent out by the
receiving station.  Shift levels are toggled with every cycle in
 order  to  support  memory  ARQ (see below).  Since  the  shift
 polarity  is  clearly  definined  at  synchronization time, any
conventions concerning 'mark /  space'  become  obsolete.

  cycle duration   1.25 sec  packets          0.96 sec = 192
(96) bits at 200 (100) baud  control signals: 0.12 sec = 12
bits, each 10 msec long  CS-receive gap : 0.29 sec   Change of
transmission  speed  only  alters  the internal  packet struc-
ture; all other timing parameters remain constant.

  2. Packets

  General packet structure:

  /header/..20 (8) data bytes at 200 (100) baud../status/CRC/CRC/

  header   This byte enables  fast synchronization  and delivers
 auxiliary           information (memory ARQ, listen mode)  data
    arbitrary binary information  status   system control  byte
(2  bit packet number, tx-mode,  break-in,           request,
QRT)  CRC      16  bit  cyclic  redundancy check  based  on
CCITT   polynomial           X^16+X^12+X^5+1,  calculated   over
 the  entire  packet (except           header)

  3. Control signals (CS)

  Four CS are used.  As a compromise between  reliability  and
fast  detec-  tion, a CS length of 12 bit was chosen.

  CS1: 4D5, CS2: AB2, CS3: 34B, CS4: D2C  (all hex numbers, LSB
right)

  The mutual Hamming  distance  is 8  bit, thus  minimizing  the
 chance of  receiving a false  CS.  CS1/2  and CS3/4  form
symmetrical pairs  (bitre-  verse patterns).

  CS1..3 have the same  function as their  AMTOR counterparts;
CS4  serves  as the speedchange  control.  In  contrast to
AMTOR,  CS3 is  transmitted  as head portion of a special
changeover packet (see below).

  4. Starting a PACTOR contact

  The calling station ('master') sends special synchronization
packets:

  /head  (100bd)/..address  (8 bytes, 1OObd)../..address  (6
bytes, 2OObd)/

  Normally,  the  receiver only  uses  the  100-baud-section  to
achieve  a  fast  synchronization.  The  200-baud-section
supplies additional infor-  mation  about  the  channel
quality:  if  it  is received correctly, the  first CS  will  be
 CS4, otherwise  CS1 is  sent.  After in  turn  having
synchronized a CS4 or CS1, the  master  will continue with
sending  nor-  mal data packets at 200 or  100  baud,
respectively.  The first transmit-  ted  characters  contain
the  'system  level  number'  (PACTOR software-  version),
followed by the master address (callsign).

  5. Changing the transmission direction

  Similar to AMTOR, the  receiving  station (RX)  can change
the transmis-  sion direction whenever it has  received a  valid
packet.  For this  pur-  pose  a  special  changeover-packet  is
transmitted,  starting at the  CS  time frame.  The transmitting
station (TX) will switch  to RX  mode  imme-  diately after it
has received the CS3  which  forms  the first section  of  the
changeover-packet.  It  then  reads  in  the  rest of that
packet  and  transmits a CS (CS1 and CS3 = acknowledge,  CS2 =
reject)  timed   at  the  last three bytes of the former packet
frame.  To  force a  break in,  the  TX sets the BK-status-bit
(this corresponds to AMTOR '+?').   6. Speedchange

  Speeddown  only  being useful in poor conditions or  at  low
data  input  rates  (e.g. manual typing),  both  directions  are
 treated  unsymmetri-  cally .

  i)  Speeddown

  The RX  may request speeddown after any  incorrectly received
packet  by  sending CS4, which  immediately  forces the  TX  to
build  up  100-baud-  packets  (any  unconfirmed  200  baud
information  is  repeated  at  low  speed) .

  ii) Speedup

  Any  valid  packet may be confirmed with CS4, forcing a  TX
speedup.  In  case the following high-speed-packet is not
acknowledged  after  a  num-  ber of tries, the TX will
automatically perform a speeddown.

  7. Termination of a PACTOR contact

  Cutting an ARQ link inevitably  leads  to the  problem  that
information  has to be transmitted  without  final
acknowledgement.  PT  applies  spe-  cial QRT  packets,
providing an expensive  but  rather  effective  solu-  tion.
These  packets contain an active QRT status bit  and  the  RX
ad-  dress in  byte-reverse  order (low speed pattern).  If
this  address  is  found  during  the standby synchronization
procedure,  the  RX  responds  with a  single  transmission of
the final CS (The timing relations  befo-  re  stby are stored).
 This method will always guarantee  a  well-defined  QRT.

  8. Data Compression

  Character  frequency  analysis of typical english or german
texts  shows  that the average amount  of information  per
character does not exceed  4  bits.  For that reason,  ASCII
text transmissions often  carry  a  redun-  dancy of 50%, which
could  be avoided by using a  variable  length  code  matched to
 the character  distribution.  The  most  popular  example  of
such a code  is the Morse code;  PACTOR  data  compression  mode
 applies  Huffman coding with  nearly  optimum  efficiency,
yielding  up  to  100%  speed gain.  Every  packet contains a
compressed data  string;  character  code lengths vary from 2 to
15 bits.

  9. Memory ARQ

  In conventional  ARQ systems the TX has to  repeat a packet
until it  has  been received completely error-free.  It is
evident  that  the  probabi-  lity of receiving  a complete
packet dramatically decreases  with  lower  S/N ratio.  The only
 way to maintain the contact  in  that  case  is  to  shorten
packet length  and/or to apply  error correcting codes  which
in  turn  will greatly  reduce maximum  traffic  speed  when
conditions  are  good.  The method chosen  by WAA Research Group
 is to sum up corresponding  bit  samples of subsequent  packets
and to test  if the  mean  value  (reduced  to a 0/1-decision)
passes the CRC.  To  keep  quantizing  errors  small,  the
samples  are taken  from the FSK-demodulator  low-pass-filter
output  by means of  an 8-bit AD-converter.  Assuming white
Gaussian noise,  this  accumulation  method - also  known as
'memory ARQ' - will obviously  con-  verge even at  a low  S/N
ratio.  Furthermore,  since  shift  levels  are  toggled with
every transmission,  constant  interfering  signals  within
the receiver passband  will  not affect  the  resulting  mean
value.  To  prevent accumulation of  old  request packets,  the
header  is  inverted  with every new information packet, thus
serving as a  RQ  indicator  (si-  milarity test).

  10. Listen Mode (Monitor)

  This mode resembles  Packet  Radio  monitoring: the  receiver
scans  for  valid packets which are detected by CRC  match.
This 'brute  force'  me-  thod was chosen in  order  to  ensure
maximum flexibility,  although  it  consumes a considerable
amount of the available CPU capacity.

  11. FEC Transmissions

  CQ and  bulletin  transmissions  are  supported by  means  of
a  special  non-protocol mode.  Packets  are  transmitted with
one  or  more repeti-  tions; the CS receive gap is omitted.
Since the  listen  mode  does  not  require  synchronization,
the  transmitting   station   possesses  great  freedom of
selecting packet repetition rate and speed.

  12. Practical Aspects

  The first PACTOR programs  were  running  on  'breadboarded'
Z80  single-  board-computers.  These early experiments  led  to
the  development  of a  stand-alone   'PACTOR-Controller'  with
 built-in  modem  and    tuning-  display.  The conventional
operating modes BAUDOT and  AMTOR  were  added  in order to
maintain compatibility  and  -  what  might be  more  intere-
sting - to allow easy comparisons.  Assuming  typical
conditions,  PACTOR  traffic can be expected to run 4 times
faster than over a AMTOR link.

*****************************************************************
*******

73 de Frode, LA2RL / HB9CHL

*****************************************************************
********* *    Frode Weierud        Phone    :    [phone]         * *    CERN,
SL        Fax    :    [phone]         * *    CH-1211 Geneva
    23    E-mail    :    [e-mail]     * *    Switzerland
or    [e-mail]     *
*****************************************************************
*********

------------------------------

Date: 3 Aug 91 10:27:21 GMT From: [e-mail]
Subject: PK-232 and IC-2GE To: [e-mail]

Is there anybody that can tell me how to connect an IC-2GE to
PK-232 ?

I have tried the following

PK-232                             IC-2GE

                    .1 uF TX AUDIO, WHT   -----!!-----+
                  +------ Tip of small connector PTT,      RED
----v^v^v---+                    33k RX AUDIO, GRN
------------------- Tip of large connector

GND,BRN/SHEILD  ------------------- Sleeve of large connector

This seems to work well i calibrate mode with both low and high
tones, but when i try to run packet radio PK-232 doesn't manage
to activate the transmitter. Any ideas ??

73 de LA3THA, Karl Olav Bergesen

------------------------------

Date: 2 Aug 91 16:04:51 GMT From:
mcsun!cernvax![e-mail] Subject: PTC, PACTOR Controller
Information To: [e-mail]

  PTC, The PACTOR-Controller

  After a long period of development and test...

  The hardware for the new ARQ radioteletype mode called PACTOR,
presented  in the German HAM-Magazine cq-DL 11/90, is now
available.  The PTC  consists of two boards, the mainboard (100
x 160mm) and a frontpanel.  It has the following features:

     * Modes: PACTOR, AMTOR (ARQ, FEC, Listen), RTTY.     *
Special features of PACTOR:         -  Error free data
transmission, 4 times faster than AMTOR         -  Complete
ASCII dataset on one level  available         -  Memory-ARQ, bad
 data  packages  are  restored         -  Online data
compression  (Iluffman  Algorithm)         -  Automatic speed
adaption depending on RF-conditions            (100 Bd, 200 Bd)
       -  Unproto mode (FEC)         -  Listen mode (to observe
PACTOR QSOS)         -  CW identification every 7 minutes and
at  QRT     * Connectors: RS232, Power, Transceiver     * Power
supply: 9... 14VDC, 2OOmA     * Developed in CMOS/HCMOS
technology as far as possible     * Digital tuning control: 8
LEDs     * Comfortable status display: 12 LEDs     * Demodulator
with A/D converter and switched capacitor filters     * Easy
calibration by software support     * Lithium battery buffered
realtime clock     * Automatic Logbook function, battery
buffered     * Build in PMS system (personal mailbox), also
battery buffered

  The PACTOR mode has been developed by DF4KV and DL6MAA, the
whole  PACTOR Group also includes DL3FCJ, DL2FAK, DLLZAM, DK5FIl
and DF4WC.

  Ordering-Conditions:  A PTC can be delivered completely
assembled or  as a kit including all parts.

  PTC assembled and calibrated        390$  PTC kit including
all parts         320$  Payments are due in advance.

  For further information see the corresponding articles soon
published  in several Amateur Radio magazines.  If these
publications do not  answer all questions feel free to write to
the address below, SAE and  IRC (or 1$) should be included for
convenient and delighting processing.

  Address all orders to: Dr. Thomas Rink
Rontgenstr. 36                         6450 Hanau I
           GERMANY

*****************************************************************
*********

73 de Frode, LA2RL / HB9CHL

*****************************************************************
********* *    Frode Weierud        Phone    :    [phone]         * *    CERN,
SL        Fax    :    [phone]         * *    CH-1211 Geneva
    23    E-mail    :    [e-mail]     * *    Switzerland
or    [e-mail]     *
*****************************************************************
*********

------------------------------

End of Packet-Radio Digest V91 #195
****************************** Date: Sun,  4 Aug 91 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #196 To: packet-radio

Packet-Radio Digest         Sun,  4 Aug 91       Volume 91 :
Issue 196

Today's Topics:             'NA' country domain appears to be
non-unique                .NA and other noxious things (2 msgs)
                        BPQ node question
HELP: Need info on TNC Firmware.                          KA9Q
SLIPDIAL.DOC                     PACTOR Information (2 msgs)
                  PTC - PACTOR Controller

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 2 Aug 91 19:19:57 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!ccml@uune
t.uu.net Subject: 'NA' country domain appears to be non-unique
To: [e-mail]

In <[e-mail]> [e-mail]
(Hank Oredson) writes:

>To the folks who say "the system is not compatible with
internet" ... >Yup, it's not.  Should it be?  Why? >What should
be done to make it compatible?

The addresses that appear on the signature are enough to fool a
_lot_ of people who simply try to use the networks as best they
know how. You yourself know a lot about the routing of email via
packet radio, and thus you know the signficance of the prefix
"packet" before your own personal signature. There are many many
plain ordinary folk to whom this means not a thing - why are
they expected to know how the email is routed, or what network
they/you are on? They see what is clearly an email address
(maybe several) so they fire off email to it. In the end, we pay
for the double hop across the Atlantic, thanks but no thanks if
you don't mind.

What to do - simple. Scrap the use of .NA for a packet radio
address, and use something that does not clash with the
addressing scheme of the Internet.

Or did packet radio set a standard before the Internet did? I do
not know the answer, maybe someone can comment with authority.

Mike--

Mike Lawrie Director Computing Services, Rhodes University,
South Africa
.....................<[e-mail]>.......................
... Rhodes University condemns racism and racial segregation

------------------------------

Date: 3 Aug 91 13:39:56 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!ccml@uune
t.uu.net Subject: .NA and other noxious things To:
[e-mail]

In <[e-mail]> [e-mail] (David B. Toth)
writes:

>I'll see if Hank watches the newsgroup and hopefully he will
chime in. >Brian/Bob: is this a problem of general
users/gateways/or what ??? >Just want to know where the biggest
problem is ... I doubt we could make >a gateway smart enuff to
overcome a PDU (poor dumb user)

There is absolutely nothing wrong with a gateway, and there is
nothing that you can do to any gateway to fix the problem.
Gateways on the Internet are _correctly_ routing .NA email to
Namibia via the .ZA link to the USA.

The problem is that certain folk (who have packet radio email
addresses) put into their signatures something like

"my email address on the packet radio network is
some.where.in.NA"

So the PDU        (your words not mine, I think that this

        problem is by no means limited to a dumb user)

who is on the Internet or other (non-packet) email network
decides to use the packet address    (which looks exactly like

                    an Internet address, hell,

                    how many folk in North

                    America spend very much time

                    thinking that NA is Namibia?)

which results in the message being delivered  _perfectly
correctly_ as far as the gateways etc are concerned                (but, of
course to the wrong

                    network, because .NA is

                    Namibia, not North America) and we pay for this
brain-damaged design of the packet-radio address space        (because
the message crosses

                    the Atlantic twice at our

                    expense)

and the poor sucker who is trying to get the Namibian networking
going on a shoestring under conditions that you in a high-tech
country cannot possible imagine gets hit with your goddamn email
and has to deal with it by hand because he has no better
hardware or software to do this goddamn job automatically.

One solution for him, for whom I have deep sympathies, would be
for you packet radio types to sponsor him for a SUN or other
Un*x box so that he can at least automate this bouncing.

Have some pity on him - he's a medical doctor trying to undo
some of the land mine damage done by my country on the locals.

Another thing that you can do is to change the format of the
signatures of those folk who use the packet radio network. Stop
them from publicising the format

    packet: [e-mail]

Best of all is to get into line with what the Internet laid down
for email addresses, and don't use the two letters .NA to mean
"North America's packet radio network". Surely you folk are
bright enough to implement this?

><grin>

Yes, well if this is your attitude then nothing will happen to
correct the situation, and good old North America will simply
steamroll over yet another developing country.

Mike--

Mike Lawrie Director Computing Services, Rhodes University,
South Africa
.....................<[e-mail]>.......................
... Rhodes University condemns racism and racial segregation

------------------------------

Date: 3 Aug 91 19:26:46 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net Subject: .NA and other noxious things To:
[e-mail]

In <[e-mail]> [e-mail] (Mike
Lawrie) writes:

>In <[e-mail]> [e-mail] (David B.
Toth) writes:

>>I'll see if Hank watches the newsgroup and hopefully he will
chime in. >>Brian/Bob: is this a problem of general
users/gateways/or what ??? >>Just want to know where the biggest
problem is ... I doubt we could make >>a gateway smart enuff to
overcome a PDU (poor dumb user)

>There is absolutely nothing wrong with a gateway, and there is
nothing >that you can do to any gateway to fix the problem.
Gateways on the >Internet are _correctly_ routing .NA email to
Namibia via the .ZA >link to the USA.

>The problem is that certain folk (who have packet radio email
addresses) >put into their signatures something like

>"my email address on the packet radio network is
some.where.in.NA"

>So the PDU        (your words not mine, I think that this >            problem
is by no means limited to a dumb user)

>who is on the Internet or other (non-packet) email >network
decides to use the packet address    (which looks exactly like
>                        an Internet address, hell, >                        how many folk in North
>                        America spend very much time >                        thinking that NA is
Namibia?)

>which results in the message being delivered  >_perfectly
correctly_ as far as the gateways >etc are concerned                (but, of
course to the wrong >                        network, because .NA is
>                        Namibia, not North America) >and we pay for this
brain-damaged design >of the packet-radio address
space        (because the message crosses >                        the Atlantic twice at
our >                        expense)

>and the poor sucker who is trying to get the >Namibian
networking going on a shoestring >under conditions that you in a
high-tech country >cannot possible imagine gets hit with your
goddamn >email and has to deal with it by hand because he >has
no better hardware or software to do this >goddamn job
automatically.

I am however quite proud on that it goes with software that is
entirely sharewre and/or in the public domaine. Some day they
will even finish the news software for uupc/extended and I can
put it up to read the interesting threads ony my own box
(lisse.NA, a very old AT with 1MB, 4dos and uupc 1.10a)

>One solution for him, for whom I have deep sympathies, would
>be for you packet radio types to sponsor him for a SUN or
>other Un*x box so that he can at least automate this bouncing.

You can not imagine hown mavelously expensive a 386 or anything
better is around here. I am not payed too bad, though not
handsomely either, but I cannot currently afford the 386SX that
I need to run even smail and/or news. I have thought about this
for some months but ...

>Have some pity on him - he's a medical doctor trying to undo
some >of the land mine damage done by my country on the locals.

Please, I feel ashamed when you say this, my own country
(Germany) wasn't any better to the locals. I am just trying to
do my job as good as I can (as I would anywhere).

Now if some foundation would be willing to pitch in the smallest
possible 386(SX) with a large hard disk or two medium sized
ones, a tape drive and at least 4MB of memory it really would
come to good use.

>Another thing that you can do is to change the format of the
>signatures of those folk who use the packet radio network. Stop
>them from publicising the format

>    packet: [e-mail]

>Best of all is to get into line with what the Internet laid
down >for email addresses, and don't use the two letters .NA to
>mean "North America's packet radio network". Surely you folk
>are bright enough to implement this?

Anyway,

it was a fascinating experience to create this thread and to
follow it, though I must say that I do not understand anything
of some messages recently posted in this particular group, but
this would be in line with the theme :-)-O, right?

Now if the postmasters of the hosts uk.ac.*.NA (there are at
least two) were answering me :-)-O? But JANET is another thread.

>><grin>

>Yes, well if this is your attitude then nothing will happen to
>correct the situation, and good old North America will simply
>steamroll over yet another developing country.

I personally think this will happen.

There are several packet radio operators who are in a position
and willing to help and anyway, internet can take care of us (by
way of CNAMEs).

If everything had come to the worst, I think the FCC might have
been quite interested.

greetings, el

ps: I am the poor sucker trying to get our litlle university to
sign an agreement, trying to find some sponsors to get us a line
(1000$ per month), trying to find a 386 to get us going, trying
to find a 9600 modem, trying to keep smiling :-)-O (Which is my
contribution to the smileys, a smiling doctor with stethoscope,
in case someone wondered.)--

Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

Date: 4 Aug 91 04:58:18 GMT From: [e-mail]
Subject: BPQ node question To: [e-mail]

Does anyone know how an application program can send a UI packet
thru the new BPQ HOST interface?  Packets to disconnected
channels seem to be ignored and I rather not build the whole
packet myself and send it via KISS.

I sent some notes to G8BPQ a while back but never heard anything.

Any help would be greatly appreciated.

Roy, AA4RE

------------------------------

Date: 2 Aug 91 16:46:45 GMT From:
hpda!hpcupna!hprdash!hpsmeng1!hpsmo100![e-mail]
Subject: HELP: Need info on TNC Firmware. To:
[e-mail]

Well I have but one question....

Has anyone had any experence in re-writing the source code in
the Eproms used in TNC's? I am looking for a source code listing
so as to  re-write the one used in a MFJ-1270B. I am also
intrerested in the one for  the MFJ-1274.

What my goal is to use the mailbox code from the 1270 or 1274
and add it to the WA8DED multi-connect firmware.

Any information or help would be much appreciated.



Eric Struble / Process Support / Support Materials California

    Hewlett-Packard  U.S.A. / Phone: [phone]
Internet: [e-mail] / Packet:
N6PYF@WA6NWE.#NOCAL.CA

------------------------------

Date: 2 Aug 91 23:51:11 GMT From:
hp-pcd!hpcvaac![e-mail] Subject: KA9Q SLIPDIAL.DOC
To: [e-mail]

/ hpcvaac:rec.radio.amateur.packet / [e-mail] (Kevin P.
Kleinfelter) / 11:32 am  Aug  1, 1991 / > I'm looking at a
message, posted to rec.ham-radio.packet, back in December > of
'89. This message describes an extension to the KA9Q attach
command, to > support modem-dialing.  Syntax is: >  >   attach
<hw type> <I/O address> <vector> <mode> <label> <bufsiz> <mtu> >
         [<speed>] [[optional '-' for debug] <send> <expect
<send> [...]] >  > However, when I enter: >   attach asy 0x3f8 4
slip sl0 1024 256 9600 - ATDT5551212 CONNECT >  > NOTHING is
sent to the modem, and the NOS prompt returns. > I've got
NOS1130D.EXE.  The doc that came with it describes a "DIALER"
command, > that my NOS does not recognize as a valid command. >
> What do I have to do to get KA9Q do dial a modem for SLIP? >
--  > Kevin Kleinfelter @ DBS, Inc [phone]
...gatech!nanoVX!msa3b!kevin >  > Dun&Bradstreet Software, 3445
Peachtree Rd, NE, Atlanta GA 30326-1276

This was a hack I added to NET (Pre-NOS) to allow my HP Portable
Plus to connect to the HP-UX (Series 500 at that time) at work
via the Plus's internal modem.

The hack appeared to work OK on the PC and was included in the
then current revision of NET by Bdale, N3EUA.  The last release
of NET which had that version of the attach command was
890421.1, I believe.

Current versions of NOS include the 'tip' command which
obsoletes my hack. If your version of NOS doesn't include the
'tip' command, you should update.

Ron Henderson WA7TAS [e-mail]

------------------------------

Date: 4 Aug 91 09:11:21 GMT From:
mcsun!cernvax![e-mail] Subject: PACTOR Information To:
[e-mail]

Find below the official PACTOR information brief from the WAA
Group. Any uncomprehensible errors is probably due to the laser
scanner and the accompaning translation software.

*****************************************************************
***

  THE WAA GROUP
     4/91

                  P A C T 0 R   Short system description

                              1. Introduction

  AMTOR and PACKET RADIO (PR) have become rather  popular  ARQ
techniques  in  Amateur  Radio.  Nevertheless,  concerning
poor-quality   channels,  their performance is far from optimum.
 AMTOR, matched  to  old  mechani-  cal teletype technology,
represents the state-of-the-art some  20  years  ago; PR was
adopted from the X.25 protocol for data  exchange  on  high-
quality telegraph lines.  PACTOR (PT), specially designed for
operation in noisy  and  fluctuating  channels, is an improved
half-duplex synchronous  ARQ  system  combining  the reliability
of PR with the fixed AMTOR time frame.

  Principal design considerations:

  PACTOR comprises all important AMTOR or PR (2-way)
characteristics:

  - fixed timing structure and full synchronism to ensure
maximum speed  - fast and reliable changeover / break-in  -
required bandwidth less than 600 Hz  - 100% ASCII compatible
(true binary data transmission)  - extremely low probability of
undetected errors (16 bit CRC)  - independent of shift
polarities  - no multi-user overhead in a narrow-band channel  -
inexpensive hardware (Z80 single-board)  - high operational
comfort (built-in message storage system, etc.)  - listen-mode
(monitor)  - FEC-mode (CQ-transmissions etc.)

  As a novelty in Amateur RTTY, some  additional  powerful
features  have  been realized:

  - optional  coherent  mode,  i.e.  system  clocks  locked  to
frequency    standards (e.g. DCF77, TV deflection signals  and
other  high  preci-    sion broadcasts)  - online data
compression (Huffman coding)  - automatic speed change (1001200
baud)  without  loss  of  synchroniza-    tion  - fully
acknowledged link termination (no QRT-timeout required)  -
memory ARQ (even noisy packets can be restored)

                          II. Some system details

  1 . Timing

  The basic PT  transmission  frame  is  very  similar  to
AMTOR;  blocks  (packets) containing data information are
acknowledged  by  short  con-  trol signals (CS) sent out by the
receiving station.  Shift levels are toggled with every cycle in
 order  to  support  memory  ARQ (see below).  Since  the  shift
 polarity  is  clearly  definined  at  synchronization time, any
conventions concerning 'mark /  space'  become  obsolete.

  cycle duration   1.25 sec  packets          0.96 sec = 192
(96) bits at 200 (100) baud  control signals: 0.12 sec = 12
bits, each 10 msec long  CS-receive gap : 0.29 sec   Change of
transmission  speed  only  alters  the internal  packet struc-
ture; all other timing parameters remain constant.

  2. Packets

  General packet structure:

  /header/..20 (8) data bytes at 200 (100) baud../status/CRC/CRC/

  header   This byte enables  fast synchronization  and delivers
 auxiliary           information (memory ARQ, listen mode)  data
    arbitrary binary information  status   system control  byte
(2  bit packet number, tx-mode,  break-in,           request,
QRT)  CRC      16  bit  cyclic  redundancy check  based  on
CCITT   polynomial           X^16+X^12+X^5+1,  calculated   over
 the  entire  packet (except           header)

  3. Control signals (CS)

  Four CS are used.  As a compromise between  reliability  and
fast  detec-  tion, a CS length of 12 bit was chosen.

  CS1: 4D5, CS2: AB2, CS3: 34B, CS4: D2C  (all hex numbers, LSB
right)

  The mutual Hamming  distance  is 8  bit, thus  minimizing  the
 chance of  receiving a false  CS.  CS1/2  and CS3/4  form
symmetrical pairs  (bitre-  verse patterns).

  CS1..3 have the same  function as their  AMTOR counterparts;
CS4  serves  as the speedchange  control.  In  contrast to
AMTOR,  CS3 is  transmitted  as head portion of a special
changeover packet (see below).

  4. Starting a PACTOR contact

  The calling station ('master') sends special synchronization
packets:

  /head  (100bd)/..address  (8 bytes, 1OObd)../..address  (6
bytes, 2OObd)/

  Normally,  the  receiver only  uses  the  100-baud-section  to
achieve  a  fast  synchronization.  The  200-baud-section
supplies additional infor-  mation  about  the  channel
quality:  if  it  is received correctly, the  first CS  will  be
 CS4, otherwise  CS1 is  sent.  After in  turn  having
synchronized a CS4 or CS1, the  master  will continue with
sending  nor-  mal data packets at 200 or  100  baud,
respectively.  The first transmit-  ted  characters  contain
the  'system  level  number'  (PACTOR software-  version),
followed by the master address (callsign).

  5. Changing the transmission direction

  Similar to AMTOR, the  receiving  station (RX)  can change
the transmis-  sion direction whenever it has  received a  valid
packet.  For this  pur-  pose  a  special  changeover-packet  is
transmitted,  starting at the  CS  time frame.  The transmitting
station (TX) will switch  to RX  mode  imme-  diately after it
has received the CS3  which  forms  the first section  of  the
changeover-packet.  It  then  reads  in  the  rest of that
packet  and  transmits a CS (CS1 and CS3 = acknowledge,  CS2 =
reject)  timed   at  the  last three bytes of the former packet
frame.  To  force a  break in,  the  TX sets the BK-status-bit
(this corresponds to AMTOR '+?').   6. Speedchange

  Speeddown  only  being useful in poor conditions or  at  low
data  input  rates  (e.g. manual typing),  both  directions  are
 treated  unsymmetri-  cally .

  i)  Speeddown

  The RX  may request speeddown after any  incorrectly received
packet  by  sending CS4, which  immediately  forces the  TX  to
build  up  100-baud-  packets  (any  unconfirmed  200  baud
information  is  repeated  at  low  speed) .

  ii) Speedup

  Any  valid  packet may be confirmed with CS4, forcing a  TX
speedup.  In  case the following high-speed-packet is not
acknowledged  after  a  num-  ber of tries, the TX will
automatically perform a speeddown.

  7. Termination of a PACTOR contact

  Cutting an ARQ link inevitably  leads  to the  problem  that
information  has to be transmitted  without  final
acknowledgement.  PT  applies  spe-  cial QRT  packets,
providing an expensive  but  rather  effective  solu-  tion.
These  packets contain an active QRT status bit  and  the  RX
ad-  dress in  byte-reverse  order (low speed pattern).  If
this  address  is  found  during  the standby synchronization
procedure,  the  RX  responds  with a  single  transmission of
the final CS (The timing relations  befo-  re  stby are stored).
 This method will always guarantee  a  well-defined  QRT.

  8. Data Compression

  Character  frequency  analysis of typical english or german
texts  shows  that the average amount  of information  per
character does not exceed  4  bits.  For that reason,  ASCII
text transmissions often  carry  a  redun-  dancy of 50%, which
could  be avoided by using a  variable  length  code  matched to
 the character  distribution.  The  most  popular  example  of
such a code  is the Morse code;  PACTOR  data  compression  mode
 applies  Huffman coding with  nearly  optimum  efficiency,
yielding  up  to  100%  speed gain.  Every  packet contains a
compressed data  string;  character  code lengths vary from 2 to
15 bits.

  9. Memory ARQ

  In conventional  ARQ systems the TX has to  repeat a packet
until it  has  been received completely error-free.  It is
evident  that  the  probabi-  lity of receiving  a complete
packet dramatically decreases  with  lower  S/N ratio.  The only
 way to maintain the contact  in  that  case  is  to  shorten
packet length  and/or to apply  error correcting codes  which
in  turn  will greatly  reduce maximum  traffic  speed  when
conditions  are  good.  The method chosen  by WAA Research Group
 is to sum up corresponding  bit  samples of subsequent  packets
and to test  if the  mean  value  (reduced  to a 0/1-decision)
passes the CRC.  To  keep  quantizing  errors  small,  the
samples  are taken  from the FSK-demodulator  low-pass-filter
output  by means of  an 8-bit AD-converter.  Assuming white
Gaussian noise,  this  accumulation  method - also  known as
'memory ARQ' - will obviously  con-  verge even at  a low  S/N
ratio.  Furthermore,  since  shift  levels  are  toggled with
every transmission,  constant  interfering  signals  within
the receiver passband  will  not affect  the  resulting  mean
value.  To  prevent accumulation of  old  request packets,  the
header  is  inverted  with every new information packet, thus
serving as a  RQ  indicator  (si-  milarity test).

  10. Listen Mode (Monitor)

  This mode resembles  Packet  Radio  monitoring: the  receiver
scans  for  valid packets which are detected by CRC  match.
This 'brute  force'  me-  thod was chosen in  order  to  ensure
maximum flexibility,  although  it  consumes a considerable
amount of the available CPU capacity.

  11. FEC Transmissions

  CQ and  bulletin  transmissions  are  supported by  means  of
a  special  non-protocol mode.  Packets  are  transmitted with
one  or  more repeti-  tions; the CS receive gap is omitted.
Since the  listen  mode  does  not  require  synchronization,
the  transmitting   station   possesses  great  freedom of
selecting packet repetition rate and speed.

  12. Practical Aspects

  The first PACTOR programs  were  running  on  'breadboarded'
Z80  single-  board-computers.  These early experiments  led  to
the  development  of a  stand-alone   'PACTOR-Controller'  with
 built-in  modem  and    tuning-  display.  The conventional
operating modes BAUDOT and  AMTOR  were  added  in order to
maintain compatibility  and  -  what  might be  more  intere-
sting - to allow easy comparisons.  Assuming  typical
conditions,  PACTOR  traffic can be expected to run 4 times
faster than over a AMTOR link.

*****************************************************************
*******

73 de Frode, LA2RL / HB9CHL

------------------------------

Date: 4 Aug 91 09:18:48 GMT From:
mcsun!cernvax![e-mail] Subject: PACTOR Information To:
[e-mail]

Find below the official PACTOR information brief from the WAA
Group. Any uncomprehensible errors is probably due to the laser
scanner and the accompaning translation software.

*****************************************************************
***

  THE WAA GROUP
     4/91

                  P A C T 0 R   Short system description

                              1. Introduction

  AMTOR and PACKET RADIO (PR) have become rather  popular  ARQ
techniques  in  Amateur  Radio.  Nevertheless,  concerning
poor-quality   channels,  their performance is far from optimum.
 AMTOR, matched  to  old  mechani-  cal teletype technology,
represents the state-of-the-art some  20  years  ago; PR was
adopted from the X.25 protocol for data  exchange  on  high-
quality telegraph lines.  PACTOR (PT), specially designed for
operation in noisy  and  fluctuating  channels, is an improved
half-duplex synchronous  ARQ  system  combining  the reliability
of PR with the fixed AMTOR time frame.

  Principal design considerations:

  PACTOR comprises all important AMTOR or PR (2-way)
characteristics:

  - fixed timing structure and full synchronism to ensure
maximum speed  - fast and reliable changeover / break-in  -
required bandwidth less than 600 Hz  - 100% ASCII compatible
(true binary data transmission)  - extremely low probability of
undetected errors (16 bit CRC)  - independent of shift
polarities  - no multi-user overhead in a narrow-band channel  -
inexpensive hardware (Z80 single-board)  - high operational
comfort (built-in message storage system, etc.)  - listen-mode
(monitor)  - FEC-mode (CQ-transmissions etc.)

  As a novelty in Amateur RTTY, some  additional  powerful
features  have  been realized:

  - optional  coherent  mode,  i.e.  system  clocks  locked  to
frequency    standards (e.g. DCF77, TV deflection signals  and
other  high  preci-    sion broadcasts)  - online data
compression (Huffman coding)  - automatic speed change (1001200
baud)  without  loss  of  synchroniza-    tion  - fully
acknowledged link termination (no QRT-timeout required)  -
memory ARQ (even noisy packets can be restored)

                          II. Some system details

  1 . Timing

  The basic PT  transmission  frame  is  very  similar  to
AMTOR;  blocks  (packets) containing data information are
acknowledged  by  short  con-  trol signals (CS) sent out by the
receiving station.  Shift levels are toggled with every cycle in
 order  to  support  memory  ARQ (see below).  Since  the  shift
 polarity  is  clearly  definined  at  synchronization time, any
conventions concerning 'mark /  space'  become  obsolete.

  cycle duration   1.25 sec  packets          0.96 sec = 192
(96) bits at 200 (100) baud  control signals: 0.12 sec = 12
bits, each 10 msec long  CS-receive gap : 0.29 sec   Change of
transmission  speed  only  alters  the internal  packet struc-
ture; all other timing parameters remain constant.

  2. Packets

  General packet structure:

  /header/..20 (8) data bytes at 200 (100) baud../status/CRC/CRC/

  header : This byte enables  fast synchronization  and delivers
 auxiliary           information (memory ARQ, listen mode)  data
  : arbitrary binary information  status : system control  byte
(2  bit packet number, tx-mode,  break-in,           request,
QRT)  CRC    : 16  bit  cyclic  redundancy check  based  on
CCITT   polynomial           X^16+X^12+X^5+1,  calculated   over
 the  entire  packet (except           header)

  3. Control signals (CS)

  Four CS are used.  As a compromise between  reliability  and
fast  detec-  tion, a CS length of 12 bit was chosen.

  CS1: 4D5, CS2: AB2, CS3: 34B, CS4: D2C  (all hex numbers, LSB
right)

  The mutual Hamming  distance  is 8  bit, thus  minimizing  the
 chance of  receiving a false  CS.  CS1/2  and CS3/4  form
symmetrical pairs  (bitre-  verse patterns).

  CS1..3 have the same  function as their  AMTOR counterparts;
CS4  serves  as the speedchange  control.  In  contrast to
AMTOR,  CS3 is  transmitted  as head portion of a special
changeover packet (see below).

  4. Starting a PACTOR contact

  The calling station ('master') sends special synchronization
packets:

  /head  (100bd)/..address  (8 bytes, 1OObd)../..address  (6
bytes, 2OObd)/

  Normally,  the  receiver only  uses  the  100-baud-section  to
achieve  a  fast  synchronization.  The  200-baud-section
supplies additional infor-  mation  about  the  channel
quality:  if  it  is received correctly, the  first CS  will  be
 CS4, otherwise  CS1 is  sent.  After in  turn  having
synchronized a CS4 or CS1, the  master  will continue with
sending  nor-  mal data packets at 200 or  100  baud,
respectively.  The first transmit-  ted  characters  contain
the  'system  level  number'  (PACTOR software-  version),
followed by the master address (callsign).

  5. Changing the transmission direction

  Similar to AMTOR, the  receiving  station (RX)  can change
the transmis-  sion direction whenever it has  received a  valid
packet.  For this  pur-  pose  a  special  changeover-packet  is
transmitted,  starting at the  CS  time frame.  The transmitting
station (TX) will switch  to RX  mode  imme-  diately after it
has received the CS3  which  forms  the first section  of  the
changeover-packet.  It  then  reads  in  the  rest of that
packet  and  transmits a CS (CS1 and CS3 = acknowledge,  CS2 =
reject)  timed   at  the  last three bytes of the former packet
frame.  To  force a  break in,  the  TX sets the BK-status-bit
(this corresponds to AMTOR '+?').   6. Speedchange

  Speeddown  only  being useful in poor conditions or  at  low
data  input  rates  (e.g. manual typing),  both  directions  are
 treated  unsymmetri-  cally .

  i)  Speeddown

  The RX  may request speeddown after any  incorrectly received
packet  by  sending CS4, which  immediately  forces the  TX  to
build  up  100-baud-  packets  (any  unconfirmed  200  baud
information  is  repeated  at  low  speed) .

  ii) Speedup

  Any  valid  packet may be confirmed with CS4, forcing a  TX
speedup.  In  case the following high-speed-packet is not
acknowledged  after  a  num-  ber of tries, the TX will
automatically perform a speeddown.

  7. Termination of a PACTOR contact

  Cutting an ARQ link inevitably  leads  to the  problem  that
information  has to be transmitted  without  final
acknowledgement.  PT  applies  spe-  cial QRT  packets,
providing an expensive  but  rather  effective  solu-  tion.
These  packets contain an active QRT status bit  and  the  RX
ad-  dress in  byte-reverse  order (low speed pattern).  If
this  address  is  found  during  the standby synchronization
procedure,  the  RX  responds  with a  single  transmission of
the final CS (The timing relations  befo-  re  stby are stored).
 This method will always guarantee  a  well-defined  QRT.

  8. Data Compression

  Character  frequency  analysis of typical english or german
texts  shows  that the average amount  of information  per
character does not exceed  4  bits.  For that reason,  ASCII
text transmissions often  carry  a  redun-  dancy of 50%, which
could  be avoided by using a  variable  length  code  matched to
 the character  distribution.  The  most  popular  example  of
such a code  is the Morse code;  PACTOR  data  compression  mode
 applies  Huffman coding with  nearly  optimum  efficiency,
yielding  up  to  100%  speed gain.  Every  packet contains a
compressed data  string;  character  code lengths vary from 2 to
15 bits.

  9. Memory ARQ

  In conventional  ARQ systems the TX has to  repeat a packet
until it  has  been received completely error-free.  It is
evident  that  the  probabi-  lity of receiving  a complete
packet dramatically decreases  with  lower  S/N ratio.  The only
 way to maintain the contact  in  that  case  is  to  shorten
packet length  and/or to apply  error correcting codes  which
in  turn  will greatly  reduce maximum  traffic  speed  when
conditions  are  good.  The method chosen  by WAA Research Group
 is to sum up corresponding  bit  samples of subsequent  packets
and to test  if the  mean  value  (reduced  to a 0/1-decision)
passes the CRC.  To  keep  quantizing  errors  small,  the
samples  are taken  from the FSK-demodulator  low-pass-filter
output  by means of  an 8-bit AD-converter.  Assuming white
Gaussian noise,  this  accumulation  method - also  known as
'memory ARQ' - will obviously  con-  verge even at  a low  S/N
ratio.  Furthermore,  since  shift  levels  are  toggled with
every transmission,  constant  interfering  signals  within
the receiver passband  will  not affect  the  resulting  mean
value.  To  prevent accumulation of  old  request packets,  the
header  is  inverted  with every new information packet, thus
serving as a  RQ  indicator  (si-  milarity test).

  10. Listen Mode (Monitor)

  This mode resembles  Packet  Radio  monitoring: the  receiver
scans  for  valid packets which are detected by CRC  match.
This 'brute  force'  me-  thod was chosen in  order  to  ensure
maximum flexibility,  although  it  consumes a considerable
amount of the available CPU capacity.

  11. FEC Transmissions

  CQ and  bulletin  transmissions  are  supported by  means  of
a  special  non-protocol mode.  Packets  are  transmitted with
one  or  more repeti-  tions; the CS receive gap is omitted.
Since the  listen  mode  does  not  require  synchronization,
the  transmitting   station   possesses  great  freedom of
selecting packet repetition rate and speed.

  12. Practical Aspects

  The first PACTOR programs  were  running  on  'breadboarded'
Z80  single-  board-computers.  These early experiments  led  to
the  development  of a  stand-alone   'PACTOR-Controller'  with
 built-in  modem  and    tuning-  display.  The conventional
operating modes BAUDOT and  AMTOR  were  added  in order to
maintain compatibility  and  -  what  might be  more  intere-
sting - to allow easy comparisons.  Assuming  typical
conditions,  PACTOR  traffic can be expected to run 4 times
faster than over a AMTOR link.

*****************************************************************
*******

73 de Frode, LA2RL / HB9CHL

*****************************************************************
********* *    Frode Weierud        Phone    :    [phone]         * *    CERN,
SL        Fax    :    [phone]         * *    CH-1211 Geneva
    23    E-mail    :    [e-mail]     * *    Switzerland
or    [e-mail]     *
*****************************************************************
*********

------------------------------

Date: 4 Aug 91 09:21:34 GMT From:
mcsun!cernvax![e-mail] Subject: PTC - PACTOR
Controller To: [e-mail]

  PTC, The PACTOR-Controller

  After a long period of development and test...

  The hardware for the new ARQ radioteletype mode called PACTOR,
presented  in the German HAM-Magazine cq-DL 11/90, is now
available.  The PTC  consists of two boards, the mainboard (100
x 160mm) and a frontpanel.  It has the following features:

     * Modes: PACTOR, AMTOR (ARQ, FEC, Listen), RTTY.     *
Special features of PACTOR:         -  Error free data
transmission, 4 times faster than AMTOR         -  Complete
ASCII dataset on one level  available         -  Memory-ARQ, bad
 data  packages  are  restored         -  Online data
compression  (Iluffman  Algorithm)         -  Automatic speed
adaption depending on RF-conditions            (100 Bd, 200 Bd)
       -  Unproto mode (FEC)         -  Listen mode (to observe
PACTOR QSOS)         -  CW identification every 7 minutes and
at  QRT     * Connectors: RS232, Power, Transceiver     * Power
supply: 9... 14VDC, 2OOmA     * Developed in CMOS/HCMOS
technology as far as possible     * Digital tuning control: 8
LEDs     * Comfortable status display: 12 LEDs     * Demodulator
with A/D converter and switched capacitor filters     * Easy
calibration by software support     * Lithium battery buffered
realtime clock     * Automatic Logbook function, battery
buffered     * Build in PMS system (personal mailbox), also
battery buffered

  The PACTOR mode has been developed by DF4KV and DL6MAA, the
whole  PACTOR Group also includes DL3FCJ, DL2FAK, DLLZAM, DK5FIl
and DF4WC.

  Ordering-Conditions:  A PTC can be delivered completely
assembled or  as a kit including all parts.

  PTC assembled and calibrated        390$  PTC kit including
all parts         320$  Payments are due in advance.

  For further information see the corresponding articles soon
published  in several Amateur Radio magazines.  If these
publications do not  answer all questions feel free to write to
the address below, SAE and  IRC (or 1$) should be included for
convenient and delighting processing.

  Address all orders to: Dr. Thomas Rink
Rontgenstr. 36                         6450 Hanau I
           GERMANY

*****************************************************************
*********

73 de Frode, LA2RL / HB9CHL

*****************************************************************
********* *    Frode Weierud        Phone    :    [phone]         * *    CERN,
SL        Fax    :    [phone]         * *    CH-1211 Geneva
    23    E-mail    :    [e-mail]     * *    Switzerland
or    [e-mail]     *
*****************************************************************
*********

------------------------------

End of Packet-Radio Digest V91 #196
****************************** Date: Mon,  5 Aug 91 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #197 To: packet-radio

Packet-Radio Digest         Mon,  5 Aug 91       Volume 91 :
Issue 197

Today's Topics:        'NA' country domain appears to be
non-unique (2 msgs)                              Continent
HELP: trying to set up my first packet station (2 msgs)
       Packet Radio Addressing & Signatures
    TCP/IP, KISS, etc                        The dreaded .NA
topic!

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 5 Aug 91 01:12:48 GMT From:
pa.dec.com!rust.zso.dec.com!nntpd.lkg.dec.com!tkou02.enet.dec.com
!jrdzzz.jrd.dec.com![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

In article <[e-mail]>, [e-mail]
(Mike Lawrie) writes:

]What to do - simple. Scrap the use of .NA for a packet radio
]address, and use something that does not clash with the
addressing ]scheme of the Internet.

Kazumi Ide, JL1KUF, who's the writer of RFC822<->W0RLI message
converter, proposed to use ".fwdnet" as the virtual top domain.
I think this is one of the possible solutions, although making
another top domain causes some problems.

-- Kenji

------------------------------

Date: 5 Aug 91 06:11:39 GMT From:
mips!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!w2xo!durham
@decwrl.dec.com Subject: 'NA' country domain appears to be
non-unique To: [e-mail]

First, I sincerely apologize to the gentleman from Nambia. I
feel somewhat responsible for his grief with bounced mail to
".NA." . I just didn't forsee that some folks would mistake
packet radio addresses for internet addresses.

This is *exactly* the problem. Mail was mailed to the wrong
addresses. Neither network malfunctioned.

I humbly submit that screaming at each other that we have
duplicate names in our addressing widgets is *not* going to
solve the problem. How in the world can anyone guarantee that
every network developed from now on will have unique address
widgets? I don't think that's possible.

All mail carried by a gateway should encapsulate the original
addresses. If a "reply" command had been used on either network,
each would have functioned correctly.

Here's what is probably going to be an unpopular suggestion, but
I can see no other way. Shouldn't each network have a "network
name" appended to the address? Someone suggested something like
this with "ampr.org", but that is really an internet type
address with ".org" being the highest-order address widget. I'm
suggesting that *all* internet addresses would be tagged with
".inet" or some such, and all packet addresses with ".pckt" or
the like. I believe bitnet already is handled this way ? This,
along with right-to-left scanning by mailer processes, would
guarantee that at least the thing goes out on the right network.
Think of it like variable names within subroutines. In C, these
can be duplicated, as long as they are in different subroutines,
which have unique names.

Flame gear on...

-Jim Durham  ([e-mail]) (Yes, I have a packet

    radio address, but wild horses....)

------------------------------

Date: 5 Aug 91 02:07:04 GMT From: [e-mail]
Subject: Continent To: [e-mail]

The purpose of the continent code is to shorten the routing
search. My BBS knows that all .EU traffic goes one way and
doesn't worry about the country code.

As far as just removing the continent code that doesn't solve
anything. Some other name will conflict.

------------------------------

Date: 4 Aug 91 17:20:38 GMT From:
ra!Ra.nrl.navy.mil![e-mail] Subject: HELP: trying to
set up my first packet station To: [e-mail]

I have recently acquired an MFJ 1270B and I am discovering a few
things I hadn't read concerning packet setup.  I have an ICOM
2AT and an AT Clone, and so for the TNC talks to the computer
just fine, but...

I have two questions:

1) With the TNC connected to the computer and the radio
connected to the TNC, there is so much RFI from the computer
equipment that my HT doesn't receive a thing (I suspect it's due
to a built in AGC circuit).  Using a shielded cable for the
TNC<->AT doesn't seem to help at all. Also, I am using the
prefabricated MFJ HT<->TNC cable, built *specially* for the IC
2AT ;-) .  The manual did mention that a shielded cable is
recommended for the TNC<->HT -- do my problems mean that this
cable is not shielded properly? (there goes another $15...) Any
suggestions/recommendations for this problem are very welcome.
But how come on the cover of CQ you see the guys in there decked
out shacks with there computers and TNC's sitting side by side?
Is the CPU in the back of the house? ;-)

2) The MFJ manual explains that to configure the 1270B for
digital loopback mode all you have to is connect JMP10 on the
board.  Well, I did that (and set MYCALL to my call), but the
TNC timed out sending packets and never did connect.  Is
something wrong with my TNC?

Thanks in advance for any suggestions.

John.--

=================================================================
== John Haynes                             Space Science
Division Strategic Scene Generation Model        Naval Research
Laboratory                                        Washington,
D.C.

[e-mail]               Phone: [phone]
[e-mail]                Amateur Radio: N5HEI
=================================================================
==

------------------------------

Date: 5 Aug 91 01:10:19 GMT From:
swrinde!cs.utexas.edu!utgpu!news-server.csri.toronto.edu!bonnie.c
oncordia.ca!ccu.umanitoba.ca!bison!sys6626!inqmind![e-mail]
u Subject: HELP: trying to set up my first packet station To:
[e-mail]

[e-mail] (John Haynes) writes:

> I have recently acquired an MFJ 1270B and I am discovering a
few > things I hadn't read concerning packet setup.  I have an
ICOM 2AT and > an AT Clone, and so for the TNC talks to the
computer just fine, > but... >  > I have two questions: >  > 1)
With the TNC connected to the computer and the radio connected
to > the TNC, there is so much RFI from the computer equipment
that my HT > doesn't receive a thing (I suspect it's due to a
built in AGC > circuit).  Using a shielded cable for the
TNC<->AT doesn't seem to > help at all. Also, I am using the
prefabricated MFJ HT<->TNC cable, > built *specially* for the IC
2AT ;-) .  The manual did mention that a > shielded cable is
recommended for the TNC<->HT -- do my problems mean > that this
cable is not shielded properly? (there goes another $15...) >
Any suggestions/recommendations for this problem are very
welcome. > But how come on the cover of CQ you see the guys in
there decked out > shacks with there computers and TNC's sitting
side by side? Is the CPU > in the back of the house? ;-)

I have a MFJ-1274. It's very noisy RFI wise. There is no RFI
suppression on it's board at all. The RFI comes out of any
cables you might have connected to it. Try a torrid on both the
radio cable and the power cable. I used a Radio Shack type clip
on choke and wrapped the 2 cables on opposite sides of the
choke. Shielded cables might help, but the case doesn't bond
anywhere close to where the cables ground so I'd be skeptical.
The shielded cable on the data cable might be just serving to
get the computers RFI out to the TNC where it can be reradiated.
Oh, of course do the old scrape the paint off the place where
the screws go through the cover so as to ground the cover to the
rest of the case. Remember that you can test for RFI by
disconnecting the suspect cable while listening to the noise on
a HT or whatever. The one cable this doesn't work for is the
power cable for obvious reasons. As a personal note I'm very
disapointed with the amount of RFI my TNC puts out. I'm a
computer person that went over to radio recently. I have various
nasty old computers around here that produce a lot less RFI than
my supposedly designed for radio TNC.

>  > 2) The MFJ manual explains that to configure the 1270B for
digital > loopback mode all you have to is connect JMP10 on the
board.  Well, I > did that (and set MYCALL to my call), but the
TNC timed out sending > packets and never did connect.  Is
something wrong with my TNC?

If you look at the schematic you'll see why that doesn't work.
Connecting JMP10 means that the output u10-8 has to fight with
the output u20-7. If the output on u20 is stronger you won't see
any data coming back. I found that jumpering JMP7 (analog
loopback) worked just fine for talking to oneself (disconnect
the radio of course).

>  > Thanks in advance for any suggestions. >  > John. > --

Bruce    Amateur Radio: VE4XOR @ UOSAT3 (note lack of continent
des)

[e-mail] The Inquiring Mind BBS, Winnipeg,
Manitoba  204 488-1607

------------------------------

Date: 4 Aug 91 15:22:07 GMT From:
haven.umd.edu!uvaarpa!murdoch![e-mail] Subject: Packet
Radio Addressing & Signatures To: [e-mail]

Folks,  As an INTERIM fix, PLEASE go now and edit your
.signature files or whatever you use to indicate your email
address in email or postings you send to clearly distinguish
one's Amateur Radio address from one's Internet address in a
foolproof manner.

  If folks would simply mark their Packet Radio addresses as
"Packet Radio" and their Internet addresses as "Internet" then
there would be a lot less chance that some other person would
get confused and use the incorrect address.  This doesn't solve
the fundamental naming conflict, but it should go a long way
towards eliminating user confusion.  Please note that most
computer networks use packets in their implementation, so the
word "Packet" by itself would be confusing.  "Packet Radio"
should not be very confusing.  An example of what I suggest
follows:

"Internet:    [e-mail] Packet Radio:
[e-mail]"

In article <[e-mail]> [e-mail]
(Mike Lawrie) writes: >Or did packet radio set a standard before
the Internet did? I do >not know the answer, maybe someone can
comment with authority.

  The Internet naming scheme was implemented first; It isn't
clear to me that that is or should be an issue either way.

  Long term, there might be some thought about moving the US
packet radio addresses into the .US domain of the Internet
naming scheme and the Canadian packet radio addresses into the
.CA domain, etc.  I do fully understand the regulatory
requirements of gateways, but if  the routing software is
well-designed it should be feasible to keep packet radio traffic
within that network and only transfer traffic that really needs
to be transferred.  Registration in the .US domain is free,
though one is required to find an Internet host who is willing
to route mail to you (though it can be via any number of
intermediate nodes and need not be direct to you).  Folks
interested (pro or con) in this idea should find out the details
on registering in the .US domain from the DDN NIC before
commenting pro or con (on the principle of keeping the
discussion technical rather than personal :-).

ASIDE:  One doesn't really need to have the continent to do
routing.  One can use a simple small lookup table in the routing
software that only needs to see the ISO Country Code.

Regards,

  Ran Atkinson                Computer Networks Lab
[e-mail]            University of Virginia

  (holder of commercial FCC radio operator's license   and
future Amateur Radio operator once I get time   and find an
examiner after I move next month :-)

------------------------------

Date: 4 Aug 91 16:15:53 GMT From:
swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.
columbia.edu!cunixa.cc.columbia.edu![e-mail] Subject:
TCP/IP, KISS, etc To: [e-mail]

I was on packet for several years until about 1987 or so, after
which I moved and never got around to re-mounting a VHF antenna.
 To that end, I've sort of been out of it for four or so years.

As I remember things then, connectivity between points was still
sort of spotty, and the chance of getting a message over great
distance without human intervention wasn't always that good.

As I'm about to get back on the air, I'm very interested to know
that the  "state of packet" is right now.  Is 1200 baud still
the standard operating speed?  Or have things gotten faster?
145.01 was basically "where it was at." Have things broadened a
bit w/the increasing traffic?

I'm particularly interested in things like TCP/IP and KISS,
though I'm not sure I really understand their current
application in Packet.  I use machines  running TCP/IP all the
time on the internet, so I understand the workings of the
technology vis-a-vis computers, but I haven't until now followed
its  development in Packet.  Is it something that is still
experimental?  or is it in common use?  I take it that a good
number of stations would have to be running it to make it of any
useful value?

Thanks in advance...

-Gabe Wiener - Columbia Univ.     "This 'telephone' has too many
shortcomings  [e-mail]       to be seriously
considered as a means of  [e-mail]
communication. The device is inherently of
[e-mail]         no value to us." -Western
Union memo, 1877

------------------------------

Date: 4 Aug 91 17:19:58 GMT From:
usc!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio
-state.edu!linac!att!cbnewsj![e-mail] Subject: The
dreaded .NA topic! To: [e-mail]

I don't see why a continent is needed at all! Get rid of both
.NA, .NOAM and for that matter all the continent ids. Why
doesn't packet radio just use the 3 letter ISO abbreviations for
country. I think the percentage of PBBS that do inter-country
routing is rather small. Not every PBBS in every country needs
to know the destination continent. Only those that route
international traffic. In that case they would have a route for
each country or maybe even a default route if one is not defined
for the country. I think this would be utilzing the good old
KISS princeable. Since the continent id is such a hot topic I
think the whole thing is humorous. Much to do about nothing. Why
is the blasted thing needed why can't the long haul PBBS routers
just use countries. Yes it's more work on them but it's not
needed by the average PBBS. Just my two cents. I guess I'll put
my flame protection suit on now....

73 Tom, KB2GLO. PS - if you want to reach me on packet its
KB2GLO@N2KZH.#CNJ.NJ.USA and use the continent id of your choice
:-)

--  Tom Kenny, KB2GLO uucp: att!mtuxo!tek
internet: [e-mail] packet radio:
kb2glo@n2kzh.#cnj.nj.usa  ampr: [e-mail] [44.64.0.10]

------------------------------

Date: (null) From: (null) I think in the long run, we amateurs
are going to have to come to some Internet naming convention
that fits all.  Hank mentioned CA.USA.NA.AMPR.ORG but I kinda
like CA.USA.NA.AX25BBS.AMPR.  Lets get AMPR as a high level name
from the Internet instead of having it under ORG.  Them
something like AX25BBS or AX25 (or ???) will indicate that what
follows is routing information.  This would actually allow us to
construct gateways based on what area of the world a gateway
wanted to cover.  For example, a gateway could be established
for CA.USA.NA.AX25BBS.AMP.  SMTP would send mail to that gateway
where it would be translated into AX25 BBS format and sent via
packet radio.

To the purists who hate the idea of domains and hierarchical
addressing mixing, I am sorry but something needs to be done to
allow TCP/IP and the AX25 Non-TCPIP people to successfully
integrate their networks.

Roy, AA4RE

------------------------------

End of Packet-Radio Digest V91 #197
****************************** Date: Tue,  6 Aug 91 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #198 To: packet-radio

Packet-Radio Digest         Tue,  6 Aug 91       Volume 91 :
Issue 198

Today's Topics:        'NA' country domain appears to be
non-unique (2 msgs)                         56kb FDX on 430 MHz
                        Continent (4 msgs)
    DSP Evalulation                       FTP sites for KA9Q
code?       HELP: trying to set up my first packet station (2
msgs)                             mobile setup             Need
local packet info for Mary Ester, Fla.       Status and
backgrounds of Packet Radio in Japan (4 msgs)
    The dreaded .NA topic!                      The great .NA.
controversy

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 5 Aug 91 22:34:54 GMT From: [e-mail]
Subject: 'NA' country domain appears to be non-unique To:
[e-mail]

Postel: >... it seems that always expressing the "packet wise"
address >in signature lines and so on as
[e-mail] would be a >practical and pragmatic
step that would do much to reduce the >confusion...

Regrettably, however, if that address were to be used on the
packet radio network, which does NOT use RFC822 nor any of the
other internet addressing and mailing standards, it would fail.

My suggestion was that the Namibian mailers could rewrite the
address [e-mail] as [e-mail] to
cause it to use a gateway, should one exist, or else to fail.
However, it turns out that they want to avoid the transport of
those messages in the first place, which they have achieved by
placing dummy wildcard records in the nameserver for *.USA.NA.
That has achieved the desired result at much less pain, and
since there are no gateways between internet and the ham packet
radio network, at no loss of mail connectivity.

That is a hack that works.  Some more-or-less correct solutions
are to:

1) make it extremely clear in one's signature block that one
address is for the internet and the other for the packet radio
network - or better yet, append only the address which is
appropriate for the network to which the message is sent.

2) change the ham packet radio network (since it's newer and
smaller) so that its addresses do not look like internet
addresses.  The simplest way to do that is to change the routing
separator character from the dot to (for example) the colon.
Thus  W2XO@W2XO:PA:USA:NA, which does not look at all the same
as the internet address that might be adjacent in the sender's
signature block, yet retains precisely the same meaning as the
dotted ham packet radio address did.  The colon is not currently
significant in ham packet radio networks, so it is even possible
to make the changeover gradually, without a flag day.

Regrettably, the ham packet radio network is not a fully
connected network, and it uses very small computers which cannot
hold or maintain large routing tables, so a hierarchical
geographical routing scheme is really all that's workable right
now.  Would that it were not so.

- Brian

------------------------------

Date: 6 Aug 91 01:25:06 GMT From:
pa.dec.com!jrdzzz.jrd.dec.com![e-mail] Subject:
'NA' country domain appears to be non-unique To:
[e-mail]

In article <[e-mail]>, brian@ucsd (Brian
Kantor) writes:

]2) change the ham packet radio network (since it's newer and
smaller) ]so that its addresses do not look like internet
addresses.

The simplest one is username (callsign) +separator+hostname,
because it's not really domain-based.  (e.g.  jj1bdx@jh1ynw) The
fake domain PRUG is going to use to identify them is
[e-mail], because RLI/MSYS sysops in Japan call
themselves forming a network called FWD-NET (forward-net).

]Regrettably, the ham packet radio network is not a fully
connected ]network, and it uses very small computers which
cannot hold or maintain ]large routing tables, so a hierarchical
geographical routing scheme is ]really all that's workable right
now.  Would that it were not so.

Is it really geographical? I think most of RLI/MSYS people are
still using bang-style source routing.

-- Kenji

------------------------------

Date: 6 Aug 91 05:05:44 GMT From: [e-mail]
Subject: 56kb FDX on 430 MHz To: [e-mail]

>Via UO-14 >From      : WB9MJN >To        : ALL >Title     : 430
Mhz, 56 KB FDX Station. >Keywords  : CELLNET, FDX, 56KB, TCP/IP
>Uploader  : WB9MJN >Uploaded  : Fri Aug 02 19:18:13 1991
__________________________

        430 Mhz Band Full Duplex 56 KBaud CELLNET Prototype Notes

            Donald V. Lemke, WB9MJN

           25 July, 1991.

    These notes cover the technical details of our two operational
56 KB 430 band full duplex CELLNET prototype stations, using the
WA4DSY 56 KBaud RF modem. These stations are operating on a 10
mile test link, with 10 watts, on 425 Mhz and 433 Mhz. Full
details of the CELLNET concept are available in the "7 th ARRL
Networking Conference Notes", in the article "Celluar Area
Coverage Transport Networks" authored by myself. The RF
prototypes have been  operated at the ILNAP:K9VXW-1 and the
N4PCR-1 (Gracilus) sites for nearly 2 years, and  have been in
active network use since the installation of a  Gracilus
PacketTEN at the ILNAP site for nearly a year. For the first
year of  operation, the ILNAP site station was in regenerative
mode, simply relaying  the transmitted data from the Gracilus
site, back to that site, for testing purposes. This test link
has been very reliable. During one memorable trip to the ILNAP
site, to work on equipment, all links to the site including the
telephone were down,  except for the 56 KB full duplex link due
to iceing conditions, and t/r switching wair and tear.

    Utilisation of a single 430 Mhz antenna, and feedline, results
in a very economical 3 link radio system, as a result of
operating in full duplex. Duplexor Cavities are usually required
when operating a station from a high performance RF site, for
protection from IMD and nearby lightning strikes. Consequently,
split band technigues, such as 220 and 440, are more expensive,
since these technigues still require Cavities to be reliable, as
well as the added cost of a second feedline and antenna.
Multi-banded systems are also  more dificult to obtain
permission to instal on high performance RF sites.  Besides the
extra tower loading of the additional antenna(s), the determin-
ation of the interference potentional with the sites primary
services is much more complicated.  Diplexing 220 and 440 on a
single feedline with a compact antenna mounted filter network is
tuff to do. I don't believe a 220/440 Mhz nor a 145/220 Mhz
diplexers are available commercially. 145/430 diplexors are very
common, however. Thus, with diplexing filters, a 2 meter network
access  station can also easily be accomadated with the same
feed-line as the CELLNET transport radio system. If the
Japanese, or European versions of the popular  dual band
antennas were availbale in the U.S., cost would be even less, as
a diplexor filter on the antenna end of the feedline would not
be neccassary. Allas, the 2 meter / 440 antennas that are
available here, do not work very well below 433 Mhz, and pleas
to both COMET and DIAMOND antenna companies  to supply their
home market versions of their popular antennas in the U.S. have
either not been understood or rebuffed.



Configuration of 430 band, 56KB CELNET Prototype Stations:

                              _____
\ ! / Antenna                               \!/
              !

            !             ------------- ! -------------                  !   /\
     ! ! !      /\   !                --!     \     !-!-!     /
   !------------                ! !      \/   !   !   \/      !
         !        RG-142  ! -------------   -------------
   ! RG-142                !        BPBR Duplexor
    !                  !        (Phelps Dodge 4 Can, >10 watts)
!  10 Watts out          -------------  (Motorola 2 Can, 10
watts)       /\  Pauldon PD440 Filter A !    /\     !
                   ft /  \ (uses S-AU4)          !   /  \    !
                    +12v(A)---/    \           !  /    \   !
                           /______\          -------------
                             ! .25 Watt in     - - - - - -!- - -
- - - - - -                         !    :           !  425
(433) Mhz  :                        !  433 (425) Mhz     :
-------------           :                  -------------
     :     ! Hamtronics!           :ft                !     /\
 ! Filter B    :     ! CA432-2   !-------------- +12v(B)
!    /  \   !     :     ! RX Conv.  !           :
  !   /    \  !     :     -------------           :
    -------------    :           !   21 (29) Mhz   :
  - - - - -!- 1 Watt in- - - -    :           !
:               :        !  433 (425) Mhz  :    :
-------------           :ft             :  -------------
  :    :     ! WA4DSY    !-------------- +5v       ft:  !
Hamtronics!           :    :     ! RX'er     !           :
+12v(A)-----! XV4       !           :    :     !           !
      :               :  ! TX Conv.  !           :    :
-------------           :               :  -------------
  :    :           !  RXA            :               :        !
29 (21) MHz    :     - - - - - -!- - - - - - - - -
 :        !  ~1 miliWatt    :    - - - ------------- - - - -ft
            ft:  -------------           :    :     !WA4DSY
!       :---- +5v      +5v-----! WA4DSY    !           :    :
 !Demodulator!       :ft               ft:  ! TX'er     !
   :    :     !Decoder    !       :---- -5v      -5v-----!
    !           :    :     -------------       :
  :  -------------           :    :           !  RXD,RXC,DCD - -
- - - - - -    - - - - -!- - - - - - - - -    - - - - - - ! - -
- - - - - - - - - - - - :            ! TXAI,TXAQ,TXEN
--------------------------------  :  - - - -------------- - - -
        !                              ! TXD,RTS   ! WA4DSY
!     :          ! PacketTEN 5port Stand-Alone  !-----------!
modulator  !     :          ! "NosInABox" uses 68302 chip  !  :
,TXC   ! encoder    !     :          !
   !  :        --------------     :
--------------------------------  :                           :
             !   !   !   !                - - - - - - - - - - -
- - - -

     4 Other ports to                     other radios, and
    ft - Pi Section DC Feed Thru filter             local
console.                  Murata-Erie # NFT403-806D1H403

         ---------------     --- +12v(A)   --------------
  ! ASTRON      !    /              ! Switching  !------ +12v(B)
        ! RS-7a       !-------------------! Power      !------
+5v         !             !                   ! Supply
!------ -5v         ---------------
--------------

    Enclosures - The Hamtronics CA432-2 and WA4DSY Reciever(s)
are enclosed                 in a 9 by 4 by 4 inch Die Cast
Aluminum Box, Hammond #                 The CA432-2 was mounted
on the bottom of the box, along                 with one WA4DSY
reciever. There is room for a second reciever                 to
be mounted on the removeable top of the box over the first
          WA4DSY reciever.

                 The Hamtronics XV4 and WA4DSY Transmitter are
also enclosed                 in a 9 by 4 by 4 inch Die Cast
Aluminum Box, Hammond #                 seperate from the
Reciever Enclosure. XV4 was mounted on                 the
bottom of the box, with the WA4DSY reciever mounted
   to the removeable top.

                 The WA4DSY Demodulator/Decoder and
Modulator/Encoder are                 encolsed in a 9 by 7 by 2
inch aluminum chassis, Bud # AC406                 with #
BPA-1593 bottom plate. A second such chasis, was in-
    cluded to allow for 2 additional WA4DSY Demodulator/Decoder
                Circuit Boards. The chasis were butted together,
and a hole                 drilled to allow for wiring to pass
between them. Shielded                  DB9 connectors were
mounted on the back of the first chasis                  for the
signals to and from the WA4DSY transmitter and re-
  ciever.     Switching Power Supply - Radio Shack # 277-1016
(AKA Kogyo # 10053214-2),                 modified for 12 Volt
D.C. input, per RMPRA notes. I.E. change                 R7 (a
240 Ohm, 1 watt) to 120 Ohm, 1 watt, and R19 (a 910 Ohm)
        to 470 Ohm. Remove the input Full Wave Bridge rectifier,
                short the "+" terminal to the terminal that
leads to L2 and                 the "-" terminal to the terminal
that leads to L1. This sup-                 ply provides plus
and minus 5 volts for the WA4DSY modem, and                 a
filtered +12 volts for the Hamtronics CA432-2, with 12
       volts D.C. input.

    Filter A - 6 Helical Resonator Band Pass Filter.
Approximately 4 dB               loss. We used the MIXER
assembly from a Motorola MOTRAC-               Mobile. Similar
filters can be found in MOCOM70-Mobiles,               and
MICOR-Mobiles. The MOTRAC-Mobile has a tube transmitter,
      making it cheaper to junk for parts. The basic casting is
             what is of value. We stripped out the mixer diode
C.B., and               soldered on a BNC connector and lead
tapped at the same               point as the original input
was. The original input was used               as the output to
the Hamtronics Recieve converter, and the               BNC was
used to connect to the Duplexor, with double shielded
   1/4 inch size coax.                  Filter B - 6 Helical
Resonator Band Pass Filter. This filter is from the
 Motorola MICOR-Mobile. It is smaller than Filter A, and has
          more loss, 6 dB, and a tighter Bandpass response. Its
is                needed to reduce the linear modulator, and
mixer noise floor,               which is only about -70 dB out
of the XV4. Measurements also               indicate that the
great majority of the noise is from the                WA4DSY
Modulator C.B.. THIS FILTER IS AN ABSOLUTE MUST, for full
       duplex to work. To get it down to 433 and 425 MHz, add
about 1                turn to each helical resonator coil of a
450-470 MHz version                filter, or buy the 400 to 420
version filter coils. Sorry,               don't have the
Motorola Part numbers for the coils. Anybody out
there know these? Here is a talley of the RF levels to convince
             you to USE a filter in the transmitter.

                      TX power                              40
dBm                      Linear Modulator Noise Floor
-70 dB                      Duplexor Isolation (2 Can)
-50 dB
---------------------------------------------
  Noise Power ON-RX-CHANNEL W/O Filter -80 dBm  <-Desense!
               Filter loss at 8 Mhz Split           -55 dB
               ---------------------------------------------
                 Noise Power ON-RX-CHANNEL W/ Filter -135 dBm
<-Negligable
                Desense.

 Why is the WA4DSY Modem Linear Modulation anyway?

    The WA4DSY modem uses a linear I and Q modulator to achieve
true coherently modulated MSK. This modulation is narrower in
modulation than non-coherent FSK, with about the same BER rate
for Eb/N0 . Also, it meets the FCC Bandwidth rules for data
emisions on the 220 and 440 MHz Bands, while doing the legal
signalling rate limit of 56 KBaud. This is probably the pri-
mary reason for linear I and Q modulation, to meet the bandwidth
limitations and still be able to do the legal signalling rate.
Thus, we have only a  -70 dB modulator noise floor and the the
requirement for the TX'er filter when doing Full Duplex with
this modulation.

More On Filters:

 The TX'er filter isn't a big thing, its easy to modify and tune
up, alto it is probably something that those familiar with full
duplex radio construction for FM voice are not expecting.
Filters such as these are an everyday affair for RF engineers.
In recent years exciting improvements have been made in these
kind of filters. They made possible the Cellular Telephone
revolution. Each Cellular phone has a small ceramic duplexor,
which is the equivalent of the Motorola 2 Can BPBR duplexor, in
performance. At Dayton in 1991, the Motorola booth had
demonstrations of similar 400 Mhz filters that were
approximately 1 by 3 by .7 inches! Two of these could do the
433/425 duplexor , and be smaller than the 10 watt RF power amp!
One more in the TX strip, and another as the RX preselector
filter, and your done.

    Looking forward, its not hard to see that FULL DUPLEX book
sized 56 KB USER ACCESS stations are a possibility. When
Microwave links replace the CELLNET links, way down the road,
the 433/425 CELLNET hardware could easily be converted to
support users of book sized data stations. How fast do u want
your 100 K file, 2 seconds good enuf?!?! Its only RF.



 Modification of the WA4DSY RF modem to 21 Mhz band.

    The CELLNET prototype stations use Hamtronics recieve and
transmit converters to translate the 29 and 21 Mhz WA4DSY modem
outputs to 433 and 425 Mhz respectively. Thus, no modifications,
or even recrystalling of the Hamtronics transverters was
neccassary. Since the WA4DSY RF circuits are somewhat less
involved than the Hamtronics Transverter, it was easier to
modify the WA4DSY RF circuitry. Since crystals for the WA4DSY
modem are not supplied with the kit, and had to be ordered
anyway, we ordered the  neccassary 21 Mhz crystals straight
away. Note: in the CELLNET application, only A transmitter, or
THE recievers at a single site are modified, but not BOTH the
transmitters, and the recievers.

 Modification of the WA4DSY Data Radio for 21 Mhz Operation:

 Reciever Modifications:

 Change Componants as follows:

  C1  - 300 pF  C2  - 47 pF  C4  - 10 pF  C5  - 51 pF

  L1  - 1.33 uH  (TOKO # BTKANS-9449HM, Digikey stock # TK1412)

 Transmitter Modifications:

 Change Componants as follows:

  C28  - 100 pF  C29  - 200 pF (Parallell 150 with 50)

  C35,39  - 43 pF  C48  - 130 pF  L13,L14  - .29 uH  (TOKO #
BTKXNS-T1047Z , Digikey stock # TK1406)    C41  - 30 pF  C42  -
300 pF  L10  -  1.33 uH  (TOKO # BTKANS-9449HM , Digikey stock #
TK1412)

Retune per WA4DSY instructions. Its easier if both a Transmiter
and a Reciever are modified at the same time.

Observed Performance:

    The two test radios have consistantly resulted in good BER
performance. The PacketTEN NOS has a monitoring facilities which
indicates the number of frames recieved, and the number of those
frames in error. With this fa- cility we have monitored the the
56 KB Full Duplex links psuedo BER. As the BER's of the link are
so good, always observed to be in better than 5e-5, its a safe
assumption that the psuedo BER is very close to the actual BER.
On  average the link puts in a 1e-5 BER. As stated above its
never been observed  to have worse than 5e-5 BER and at times
its as good as 1e-6. The 10 mile path is a slightly sub-grazing
path, with a 100 foot high 6 dBd antenna at one end, and a 50
foot high 10 dBd antenna at the other.  Significant foil- iage
blokage is present on the 50 foot high end. The path is not flat
terrain, but includes a river valley, and ridge line at least 50
foot higher than  ground level at the 50 foot high antenna end.
Overall, this is a good path to  test over, with many real world
path variations. The Gracilus end of the link is close to
downtown Aurora,IL, which seems to be a very intense RF envior-
ment. The police station is nearby, with a communications tower,
and many  antennas. There are several FM broadcast stations in
downtown Aurora, and  apparently allot of paging transmitters. 2
meter hts can not be operated, even in the basement, and on a
rubber ducky antenna without the familiar paging  IMD breaking
squelch. Significant reduction in BER was observed when the
above mentioned ICE storm caused the 10 dBd antenna at the
Gracilus site to sag at a 30 degree down-angle. Previous to that
time, the link was regurlarily doing 1e-6, and afterwards only
occaisionally. The reported average perfor- mance, tho, includes
the performance with the damaged antenna, since to date it has
not been repaired.

The reported performance is in line with prediction equations in
the "7th Computer Networking Conference Notes". First let me
mention that the equation on page 125 for Reciever Noise Power
begins 198.6, when in actuality it should have begun -198.6. The
tables calculated used the correct equation. 4 dB Noise Figure
was not atainable with this hardware prototype, due to
additional reciever preselector loss, and larger CA432-2 Noise
Figure than assumed for the estimation of 4 dB. The actual Noise
Figure of the prototype recievers was approximately 6 to 8 dB,
depending on individual preselector variation, and the larger
CA432-2 Noise Figure. Additionally, the test path used has an
unknown path loss, due to its variability. The combined impact
of these effects, easily accounts for the observed BER's. I
approximate a 30 mile truely grazing path link using this same
hardware would have a 7.5 dB worse performance, which would be
about 4 e-5 average BER, or about a 14 dB margin over 10e-3. In
otherwords, the link would successfully send 1000 byte packets
between 90 and 95 % of the time.

------------------------------

Date: 5 Aug 91 14:21:20 GMT From:
swrinde!sdd.hp.com!think.com!news![e-mail] Subject:
Continent To: [e-mail]

In article <[e-mail]> [e-mail]
(Roy Engehausen) writes:

...   From another point of view, why does Internet want Nambia
as .NA?   Why aren't the countries using their ISO country code?

They are.  The Internet domain naming system uses the two-letter
ISO country code.  I believe ISO defines both 2- and 3-letter
country codes.

------------------------------

Date: 5 Aug 91 12:48:20 GMT From:
swrinde!zaphod.mps.ohio-state.edu!wupost!udel!haven.umd.edu!uvaar
pa!murdoch![e-mail] Subject: Continent To:
[e-mail]

In article <[e-mail]> [e-mail]
(Roy Engehausen) writes: >The purpose of the continent code is
to shorten the routing search. >My BBS knows that all .EU
traffic goes one way and doesn't worry about >the country code.

  There is a small finite set of countries in Europe.  The
country codes are well known and don't change.  A lookup table
is a practical and efficient way to route to other continents.
There is no technical need for a continent code to perform
routing.  Using a lookup table would not take any noticable
length of time.

>As far as just removing the continent code that doesn't solve
anything. >Some other name will conflict. > >From another point
of view, why does Internet want Nambia as .NA? >Why aren't the
countries using their ISO country code?

"NA" IS the ISO country code for Namibia, what are you talking
about ??

  If the Amateur Radio folks would consolidate into the regular
Internet namespace, the ISO country code scheme (without
continent codes) would work and not conflict with Internet names
because the Amateur Radio packet network would be another
network that interconnected with the Internet and shared the
same namespace.

>I think in the long run, we amateurs are going to have to come
>to some Internet naming convention that fits all.

  The above is indeed the case and to my mind it matters less
which convention is used than that some convention that is
consistent with and compatible with the Internet be adopted.

  In some sense using *.AMPR.ORG makes a whole lot of sense
because that gives a separate unique namespace for amateurs run
by amateurs. The Internet will not give out any new top level
domain, so the notion of having *.AMPR as a legal top level
domain isn't going anywhere.

>Hank mentioned >CA.USA.NA.AMPR.ORG but I kinda like
CA.USA.NA.AX25BBS.AMPR.  Lets >get AMPR as a high level name
from the Internet instead of having it >under ORG.  Them
something like AX25BBS or AX25 (or ???) will >indicate that what
follows is routing information.  This would >actually allow us
to construct gateways based on what area of >the world a gateway
wanted to cover.  For example, a gateway could >be established
for CA.USA.NA.AX25BBS.AMP.  SMTP would send mail >to that
gateway where it would be translated into AX25 BBS format >and
sent via packet radio.

  Gateways and routers do not need to have the continent in the
address.  Save everyone much grief and use lookup tables based
on ISO country codes.  The X.25 people can map the names without
problem if *.AMPR.ORG were used or ISO country codes alone or
both were used.

>To the purists who hate the idea of domains and hierarchical
>addressing mixing, I am sorry but something needs to be done to
allow >TCP/IP and the AX25 Non-TCPIP people to successfully
integrate their >networks.

A lot of the quoted material appears to be based on
misunderstandings of routing technology and the Internet.
Hopefully things are a bit clearer now.

Ran [e-mail]

------------------------------

Date: 5 Aug 91 11:37:05 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net Subject: Continent To: [e-mail]

In <[e-mail]> [e-mail] (Roy
Engehausen) writes:

>The purpose of the continent code is to shorten the routing
search. >My BBS knows that all .EU traffic goes one way and
doesn't worry about >the country code.

>As far as just removing the continent code that doesn't solve
anything. >Some other name will conflict.

>From another point of view, why does Internet want Nambia as
.NA? >Why aren't the countries using their ISO country code?

Quite clearly you are not really up to date: The countries ARE
using their ISO country code. If you look up the standard you
will see that there are two the 2 letter and the 3 letter. It is
up to the country to decide which one they want and they usually
(even the US :-)-o) choose the 2 letter one.

And what is even more clear: First come first serve. If you
people had registered NA as your NorthAmerica top level with
sri.nic.MIL, they would have old me so and I would have chosen
something else, most likely the 3 letters NAM.

>I think in the long run, we amateurs are going to have to come
>to some Internet naming convention that fits all.  Hank
mentioned

No question about this. This is the idea about internet, you go
ahead and register with sri.nic.MIL ANY domaine name that you
like as long as it is not already used and they will in all
likelyhood do that.

>CA.USA.NA.AMPR.ORG but I kinda like CA.USA.NA.AX25BBS.AMPR.
Lets >get AMPR as a high level name from the Internet instead of
having it >under ORG.  Them something like AX25BBS or AX25 (or
???) will >indicate that what follows is routing information.
This would >actually allow us to construct gateways based on
what area of >the world a gateway wanted to cover.  For example,
a gateway could >be established for CA.USA.NA.AX25BBS.AMP.  SMTP
would send mail >to that gateway where it would be translated
into AX25 BBS format >and sent via packet radio.

>To the purists who hate the idea of domains and hierarchical
>addressing mixing, I am sorry but something needs to be done to
allow >TCP/IP and the AX25 Non-TCPIP people to successfully
integrate their >networks.

>Roy, AA4RE

Nobody is opposed to do this. Actually I personally am very
interested in internet over the radio as we are a developing
country with rudimentary phone services to the rural areas where
the majority of our poplulation live and quite large hospitals
without many specialists are that need to consult with us here
in Windhoek where we have first world conditions more or lesss
(for a price :-)-O).

greetings, el--

Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

Date: 5 Aug 91 17:04:08 GMT From:
usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!w2xo!durham@
ucsd.edu Subject: Continent To: [e-mail]

In article <[e-mail]> [e-mail]
(Roy Engehausen) writes: >The purpose of the continent code is
to shorten the routing search.

I agree, as most PBBSes use slow PC XTs and there are several
hundred countries in the world.

>As far as just removing the continent code that doesn't solve
anything. >Some other name will conflict. > Amen... > >I think
in the long run, we amateurs are going to have to come >to some
Internet naming convention that fits all.

I was not aware ham packet BBSes were part of the Internet.
Tcp/Ip operations as "network 44" definintely is, but the PBBS
network is not part of the internet to my knowledge, so don't we
have to make this distinction, that they are a separate entity
from the internet?

>                                              Hank mentioned >CA.USA.NA.AMPR.ORG but I kinda
like CA.USA.NA.AX25BBS.AMPR.

Yes, "AMPR.ORG" sounds like network 44 to me. I think if PBBSes
are to be part of the internet, then they *must* follow internet
addressing schemes. If they are *not* part of the internet, then
somehow the addresses should have some component at the
right-hand side that *clearly* indicates this.

>get AMPR as a high level name from the Internet instead of
having it >under ORG.

Sounds like this is a vote in favor of putting ham PBBSes on the
Internet. Then you could do something like "PBBS.ORG", which
would differentiate the PBBS network from ham TCP/IP.

>          Them something like AX25BBS or AX25 (or ???) will >indicate
that what follows is routing information.

Uh..now we're back to the original problem, this is the point at
which the addresses "go screwy" by internet standards.

>                                              This would >actually allow us to construct
gateways based on what area of >the world a gateway wanted to
cover.  For example, a gateway could (stuff deleted)> >To the
purists who hate the idea of domains and hierarchical
>addressing mixing, I am sorry but something needs to be done to
allow >TCP/IP and the AX25 Non-TCPIP people to successfully
integrate their >networks.

I endorse the idea that if we have at top-level domain name
assigned to ham PBBSes, then it doesn't matter at that point
*how* the rest of the address is used. The fact that it is
actually routing information is not important to the internet
hosts that merely forward to the ham PBBS gateways on the
internet. They know what to do with the rest of the address.

-Jim, W2XO

------------------------------

Date: 5 Aug 91 23:23:53 GMT From:
swrinde!cs.utexas.edu!convex![e-mail] Subject: DSP
Evalulation To: [e-mail]

I would like input from anyone who has experience or opinions on
this issue:

I am setting up a packet station and plan to also do satellites
in the future. I don't have a TNC and in shopping, I find that
there are several DSP units on the market.   When I look at the
prices of a PK232 plus PSK modems, etc. it seems that the price
of several different pieces of packet equipment nearly equals
what is advertized by the various DSP makers.

So, I'd like to find a single unit that will do it all, but I'm
not sure what is best or if these units really do it all??

  1. There is a DSP-12 from L.L. Grace.    $595.       They
claim   400bps PSK

       1200bps PSK

       2400bps packet

       9600bps DFSK

       If you add the extra 1MB of RAM it's $744

  2. There is the Kantronics Data Engine with all 3 modems
~~$700       They claim 1200 buad AFSK                  2400
baud QPSK          and     9600 baud DFSK  which is supposedly
"UoSAT compatible"

  3. And of course, there's the AEA DSP  at $789 or $999

       Which claims all the same things...

Any information or reactions from others that you might have
would be most interesting in helping decide.  Looks like I'm
going to spend  somewhere between $600 and $800 to for the
packet and modems... Maybe the older PK232 and PSK modems of
some sort is best??  I've read in the AMSAT Journal where there
may be problems getting into and out of KISS mode with the
PK232?  I'm not sure how real that is...

I've got the benefit of not having any equipment and thus
starting from scratch, but I want to spend that money wisely and
get things that work well and will last for several years
without having to spend a more money.

Thanks in advance for any help, experiences, or suggestions you
might have.

Presley Smith  [e-mail]

------------------------------

Date: 5 Aug 91 20:31:37 GMT From:
sun-barr!newstop!grapevine!twobeers![e-mail] Subject:
FTP sites for KA9Q code? To: [e-mail]

Hi,

I did a dumb thing and accidentally deleted my mail files with
the locations of the FTP sites for KA9Q NOS code. Could some
kind soul please either send me a list of these site or post
them?

Thanks Keith

+----------------------------------------------------------------
-------+ |  Keith E. Thompson  KA6LRR  |
[e-mail]  (Internet)or | |  Sun Microsystems,
Inc.     | Keith.Thompson@EBay        (Internet)   | |  1210
California Circle     | 408-276-3464             (Phone-work)
| |  Milpitas, CA               | 415-782-0974
(Phone-home)   |
+----------------------------------------------------------------
-------+

------------------------------

Date: 5 Aug 91 14:11:32 GMT From:
stanford.edu!agate!eos!aio![e-mail] Subject:
HELP: trying to set up my first packet station To:
[e-mail]

In <[e-mail]> [e-mail]
(John Haynes) writes:

>I have recently acquired an MFJ 1270B and I am discovering a
few >things I hadn't read concerning packet setup.  I have an
ICOM 2AT and >an AT Clone, and so for the TNC talks to the
computer just fine, >but...

>I have two questions:

>1) With the TNC connected to the computer and the radio
connected to >the TNC, there is so much RFI from the computer
equipment that my HT >doesn't receive a thing (I suspect it's
due to a built in AGC >circuit).  Using a shielded cable for the
TNC<->AT doesn't seem to >help at all. Also, I am using the
prefabricated MFJ HT<->TNC cable, >built *specially* for the IC
2AT ;-) .  The manual did mention that a >shielded cable is
recommended for the TNC<->HT -- do my problems mean >that this
cable is not shielded properly? (there goes another $15...) >Any
suggestions/recommendations for this problem are very welcome.
>But how come on the cover of CQ you see the guys in there
decked out >shacks with there computers and TNC's sitting side
by side? Is the CPU >in the back of the house? ;-)

>2) The MFJ manual explains that to configure the 1270B for
digital >loopback mode all you have to is connect JMP10 on the
board.  Well, I >did that (and set MYCALL to my call), but the
TNC timed out sending >packets and never did connect.  Is
something wrong with my TNC?

>Thanks in advance for any suggestions.

>John.
>->==============================================================
===== >John Haynes                             Space Science
Division >Strategic Scene Generation Model        Naval Research
Laboratory >                                        Washington,
D.C.

>[e-mail]               Phone: [phone]
>[e-mail]                Amateur Radio: N5HEI
>================================================================
===

I'm not familuar with the 1270B, and can't comment on the
loopback stuff, but I have successfully used a IC 2AT with a
PK-232 and an XT clone.  At first (while lining in a temporary
apartment with an indoor antenna, I had interference problems
such as you describe.  This was solved by simply moving the
antenna further from the radio/computer/TNC.  Later, set-up in a
house with an ourdoor groundplane, the same problem reappeared.
Pkt had been down for a while due to a bad power supply in the
computer.  After the PS was replaced, noise!!! I blamed it on
the PS, and gave up on packett untill I decided to replace the
antenna with a homebrew J-Pole - vola packett again.  In other
words, try  lots of things, but always suspect that the computer
and/or the TNC may be radiating into the antenna.

Now I'm moving into an apartment again, so ---.

Good luck and 73

Sarge - W0RIJ

------------------------------

Date: 6 Aug 91 03:04:01 GMT From:
usc!wupost!uwm.edu!linac!att!cbnewse!cbnewsd!cbfsb!cbnewsb.cb.att
.com![e-mail] Subject: HELP: trying to set up my first
packet station To: [e-mail]

A possible partial solution to TNC RFI is to use a rooftop
antenna, and not a rubber duck on the HT.  Also, using seperate
power supplies for the HT, TNC and computer helps some.  One
other thing: I use a very long (20')  TNC<>radio connection
cable in my packet station.  Ferrite cores didn't do a whole lot
for me, but may still be worth trying.

73 de WA2ISE@KD6TH (packet)

------------------------------

Date: 6 Aug 91 09:10:51 GMT From: [e-mail]
Subject: mobile setup To: [e-mail]

I would like to build a mobile packet radio station. Who has
seen a design for a small portable tnc + terminal running at 12
volts.

Wim NIJNTJES   PE1NTW    The Netherlands.

------------------------------

Date: 5 Aug 91 12:12:56 GMT From:
swrinde!elroy.jpl.nasa.gov!usc!snorkelwacker.mit.edu!stanford.edu
!leland.Stanford.EDU![e-mail] Subject: Need local packet
info for Mary Ester, Fla. To: [e-mail]

Could someone point a finger to where I can get any information
on the local packet radio situation down in Mary Ester, Fla.
(just outside of Fort Walton Beach)?  I hope to be leaving my
current assignment here at Clark AB, Philippines (the home of
Mt. Pentatobo (sp)) soon and moving onto my next assigment at
Hurbert Field, Fla.

I need to find out who the local packet coordinator is and what
equipment and software would be of use to best intergrate into
the local packet net.

I have two UNIX systems that I hope to do some experimental
packet work with and to setup as a internet/packet gateway.  I
also hope to put my  largest machine online as a public UNIX
system and BBS (I'll have room for over 1.2 Gig of
UNIX/packet/ham sources and utilities online).

I know that many would be very happy to see such a resource
become  available to the ham community.  But, I need to know the
above info before I can start to budget for TNCs and rigs (I
already have the computing power :-)).

73 de ka0tgn (hm. looks like I'll have to get a new callsign)

-Freeman



-Freeman P. Pascal IV       John 3:16 -    For the Lord so loved the
world that [e-mail]        He sent his only begotten
Son, that KA0TGN                    whoever believes in Him should not Jesus is
LORD of all.            perish but have everlasting life.

------------------------------

Date: 6 Aug 91 01:44:34 GMT From:
pa.dec.com!jrdzzz.jrd.dec.com!jrdbdx![e-mail]
Subject: Status and backgrounds of Packet Radio in Japan To:
[e-mail]

Following is status of Japanese packet radio, representing my
points of view as the domain administrator of prug.or.jp, not
necessarily representing views of other PRUG staff members, nor
of RLI/MSYS sysops in Japan. I hope this helps to find out
naming issues that packet radio enthusiasts face now.

First on techcical policy issues:

* prug.or.jp (IP network 133.168) and genesys-p.or.jp (IP
network 133.? (sorry I don't remember, but they have another
class-B network) domain administrators have agreed not to
connect to ampr.org sites unless they meet the requirements of
IP network connection (An IP network should have only one
gateway to other IP networks).

* prug.or.jp have a policy that no RLI/MSYS messages should be
forwarded into  Japan Internet/JUNET. JUNET does not allow
anonymous postings. And the risk  of anonymous postings is very
high on RLI/MSYS in Japan. prug.or.jp and genesys-p.or.jp also
prohibits message exchange between their radio sites and
Internet sites outside prug/genesys-p.or.jp.

* Japan has been paying very high cost to maintain Internet
connection to the  USA and the rest of the world. If you set up
ham radio stations here to use  ampr.org, you have to use an
American primary name server for identifying  Japanese station.
The reason why PRUG established their own domain is to  reduce
this cost and make things manageable within Japanese Internet
community.

* Of course you can choose several other alternatives. ampr.org
can contain  IP networks other than 44. But I don't want to do
this without agreement of  Phil Karn, the domain administrator.

Next, the local political issues:

* Many of RLI/MSYS sysops in Japan do not want to forward their
messages to  those who are using KA9Q. We have long been arguing
this issue and we want  open bi-directional unrestricted
forwarding inside ham radio community, but  they disagree, so I
have to treat them separately.

* RLI/MSYS people says all persons on the packet radio should
use his/her callsign as the username to represent himself. I
feel this is absurd, since AX.25 packets ALWAYS contain valid
callsign.

* ampr.org subnet coordinator in Japan (who can assign 44.129)
does not want to accept application from those who are actually
running KA9Q (most of them are running Terakoya news systems),
because of different policy. PRUG obtained a legitimate IP
network (133.168) and assigning 1/4 of it (133.168.[1-63].*)
solely for ham radio use (and WILL NOT ROUTE the datagrams to
the existing Internet), to meet high demands from newcomers.
genesys-p.or.jp does this too now for Osaka and other Kansai
area people.

For conclusion: my opinion is that ham radio is just another
media for non-profit hobby use (although I respect pioneers of
ham radio).  And ham radio people should not form closed
society.  They should break the barriers of old traditions (that
everybody should identify themselves by callsigns[sic], etc.) or
they will lose support for local societies. I strongly disagree
with idea that ham radio should have closed incompatible naming
space.

-- Kenji, PRUGNET zone contact

------------------------------

Date: 6 Aug 91 03:10:10 GMT From:
munnari.oz.au!manuel!ccadfa![e-mail]
 Subject: Status and backgrounds of Packet Radio in Japan To:
[e-mail]

------------------------------

Date: 6 Aug 91 02:55:16 GMT From:
munnari.oz.au!manuel!ccadfa![e-mail]
 Subject: Status and backgrounds of Packet Radio in Japan To:
[e-mail]

------------------------------

Date: 6 Aug 91 05:23:17 GMT From:
pa.dec.com!jrdzzz.jrd.dec.com![e-mail] Subject:
Status and backgrounds of Packet Radio in Japan To:
[e-mail]

In article <[e-mail]>, [e-mail]
(Warren Toomey) writes: ]I missed this in my first reply. Yes,
AX.25 packets always contain valid ]callsigns, but not always
the callsign of the originating station. For ]example, a TCP/IP
packet from me to Hawaii will be transmitted there ]with the
callsign of ah6bw.

You are right.  Let me comment in this way; it is only the gov't
authorities who wants to know where an datagram is coming from.
All they need to identify the source of the datagram is the
callsign of relaying station. And the operator of relaying
station is responsible for some extent (not solely) for contents
what the station transmits.

]This implies that the amateur authorities need to know the IP
addresses ]of all the amateurs. I think that this is quite all
right.

No problem on this, although I don't want to register my IP
addresses to the gov't database - it takes too much time to be
authorized.

-- Kenji

------------------------------

Date: 5 Aug 91 11:30:54 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net Subject: The dreaded .NA topic! To:
[e-mail]

In <[e-mail]>
[e-mail] (thomas.kenny) writes:

>I don't see why a continent is needed at all! Get rid of both
.NA, .NOAM and >for that matter all the continent ids. Why
doesn't packet radio just use >the 3 letter ISO abbreviations
for country. I think the percentage of PBBS [...]

This is a VERY GOOD idea. Internet usually uses the 2 letter ISO
abbreviation and therefor packet radion can nicely use the 3
letter ISO. You people should however establish a central
clearing post that makes sure they use the right one and it is
actually not used on the internet.

>73 Tom, KB2GLO. >PS - if you want to reach me on packet its
KB2GLO@N2KZH.#CNJ.NJ.USA >and use the continent id of your
choice :-)

>--  >Tom Kenny, KB2GLO >uucp: att!mtuxo!tek
internet: [e-mail] >packet radio:
kb2glo@n2kzh.#cnj.nj.usa  ampr: [e-mail] [44.64.0.10]

regards, el

-Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

Date: 5 Aug 91 19:22:00 GMT From: [e-mail]
Subject: The great .NA. controversy To: [e-mail]

    Since the vast majority of the world seems to insist on a
host/domain name of the form "I.AM.HERE.SO.THERE!..." with the
incorporated geographical mumbo-jumbo, why isn't it just
shortened down to something that won't change for any reason
other than the earth being blown to bits.  Continents become an
irrelevant issue.  It won't matter if the national governments
are overthrown, decide to change their name, have several
prefixes for callsigns, or simply have different name/spellings
in other languages, etcetera, etcetera.  It would be very easy
to determine (geographically) where the distant end is.  A
computer could even figure out where the destination was in X-Y
coordinates with this method.  If we ever have large-scale
satellite switching, this might make things easier.

    Use grid-locators.  ;-)

No, I'm not serious.

Reid @ WB7CJO.DN71eh.AMPR.ORG (find me if you can)

(Packet-radio)       (Internet) WB7CJO @ N0ESG       FLETCHER @
LODE.UWYO.EDU                     FLETCHER @ MOHO.UWYO.EDU
              FLETCHER @ CORRAL.UWYO.EDU

------------------------------

Date: (null) From: (null) I missed this in my first reply. Yes,
AX.25 packets always contain valid callsigns, but not always the
callsign of the originating station. For example, a TCP/IP
packet from me to Hawaii will be transmitted there with the
callsign of ah6bw.

This implies that the amateur authorities need to know the IP
addresses of all the amateurs. I think that this is quite all
right.

On my home TCP/IP radio station, I use `warren' as my default
name, and `warren', `wkt' and `vk1xwt' to accept mail.

       Warren Toomey VK1XWT, cold but happy      Deep in the
bowels of ADFA Comp Science.  `POSIX Job Control?! POXY job
control more like!'

------------------------------

Date: (null) From: (null) > * prug.or.jp and genesys-p.or.jp ...
> have agreed not to connect to ampr.org sites unless they meet
the > requirements of IP network connection (An IP network
should have > only one gateway to other IP networks).  I run an
ampr.org. site that has one interface to the local amateur radio
 community, and one interface to the Internet, with the new
encapsulation  methods described in rfc1226 and rfc1241. Would
you consider adding a  route from your machines to mine? I seem
to meet your requirement.  Perhaps you might also be able to
explain why you formed the requirement.

> * Of course you can choose several other alternatives.
ampr.org can contain > IP networks other than 44. But I don't
want to do this without agreement of > Phil Karn, the domain
administrator.  Brian Kantor, [e-mail], is now the 44.
domain administrator.

> * ampr.org subnet coordinator in Japan (who can assign 44.129)
does not > want to accept application from those who are
actually running KA9Q         then   > For conclusion: my
opinion is that ... ham radio people should not form > closed
society.  They should break the barriers of old  traditions ...
I take it that you are in disagreement with the Japan ampr.org
subnet coordinator. I'm glad, because I can't see how someone
can disagree with an implementation of the Internet protocol
suite. To me, it would be like not connecting to PK-232 TNCs,
even though they use standard AX.25.

       Warren Toomey VK1XWT, cold but happy      Deep in the
bowels of ADFA Comp Science.  `POSIX Job Control?! POXY job
control more like!'

------------------------------

Date: 5 Aug 91 11:35:17 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net To: [e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: 'NA' country
domain appears to be non-unique

In <[e-mail]> [e-mail]
(Kenji Rikitake) writes:

>In article <[e-mail]>, [e-mail]
(Mike Lawrie) writes:

>]What to do - simple. Scrap the use of .NA for a packet radio
>]address, and use something that does not clash with the
addressing >]scheme of the Internet.

>Kazumi Ide, JL1KUF, who's the writer of RFC822<->W0RLI message
converter, >proposed to use ".fwdnet" as the virtual top domain.
I think this is one of the >possible solutions, although making
another top domain causes some problems.

>-- Kenji

I think the 3 letter ISO abbreviation (NAM for NAMibia) would go
very nicely as apposed to the 2 letters used on the internet.

regards, el--

Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

Date: 5 Aug 91 14:54:28 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net To: [e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail]> Subject :
Re: 'NA' country domain appears to be non-unique

In <[e-mail]> [e-mail] (Jim Durham)
writes:

>First, I sincerely apologize to the gentleman from Nambia. I
feel >somewhat responsible for his grief with bounced mail to
".NA." . >I just didn't forsee that some folks would mistake
packet >radio addresses for internet addresses.

No apology necessary.

>This is *exactly* the problem. Mail was mailed to the wrong
>addresses. Neither network malfunctioned.

>I humbly submit that screaming at each other that we have
>duplicate names in our addressing widgets is *not* going to
>solve the problem. How in the world can anyone guarantee that
>every network developed from now on will have unique address
>widgets? I don't think that's possible.

I don't think that we screamed. (NA and .ac.ZA). The point is
you register with sri.nic.MIL and then get a domain name which
you can choose as long as it not confilicts with aleady existing
ones.

I concede that the packet net existed prior to NAmibia, but I
registered first. If NA had been registered as North America
they would have told me and I would have chosen another name. So
if the packet radio software ti not so intelligent that it needs
the continent to know where the message is to be routed to that
is mainly a design flaw but not a political issue. There are
only about 160 countries so a databaselookup should not be so
difficult. If the three letter ISO abbreviations were used there
is no chance of a conflict (after checking with sri.nic.MIL, of
course). If the continent is necessary then use four letters.

>All mail carried by a gateway should encapsulate the original
>addresses. If a "reply" command had been used on either
>network, each would have functioned correctly.

True, true, but it doesn't really matter why. Most users are
users and not professional networkers. If you stick an internet
like looking adress into your signature someone will use it
whether you write there packet only or not.

>Here's what is probably going to be an unpopular suggestion,
>but I can see no other way. Shouldn't each network have >a
"network name" appended to the address? Someone suggested
>something like this with "ampr.org", but that is really >an
internet type address with ".org" being the highest-order
>address widget. I'm suggesting that *all* internet >addresses
would be tagged with ".inet" or some such, and >all packet
addresses with ".pckt" or the like. I believe >bitnet already is
handled this way ? This, along with >right-to-left scanning by
mailer processes, would >guarantee that at least the thing goes
out on the right >network. Think of it like variable names
within subroutines. >In C, these can be duplicated, as long as
they are in different >subroutines, which have unique names.

What for?  This is quite unnecessary. Just register a name with
sri.nic.MIL as a domine and everything is clear. If you perhaps
registered .PACK you can MX each continent's gateway for the
shortes possible routing.

I am beeing told by some friends who happen to radio amateurs
that this and other problems were forseen and the
operators/designers were forewarned and the still choose not to
listen. So be it...

Anyway, it has been stopped now. Now I only get the occasional
typo for NZ and of course anything in ac.UK that starts with na.
(-->uk.ac.*.NA)

greetings, el--

Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

Date: (null) From: (null)      Countries

         The English two letter code (alpha-2) identifying a
country         according the the ISO Standard for "Codes for
the         Representation of Names of Countries" [5].

---Bruce Walker  Thinking Machines Corp., Cambridge, MA
[e-mail]; [phone]; WT1M

------------------------------

Date: 6 Aug 91 05:18:18 GMT From:
orion.oac.uci.edu!ucivax!jarthur!elroy.jpl.nasa.gov!sdd.hp.com!sp
ool.mu.edu!munnari.oz.au!uniwa!cc.curtin.edu.au![e-mail]
 To: [e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail]>
Subject : Re: 'NA' country domain appears to be non-unique

In article <[e-mail]>, I foolishly
said: >    In case you missed it, if you enter 'sb rhubarb@xxx',
your bulletin goes > to the Great Bit Bucket In The Sky (at
least it does on an MBL system: I assume > the others are no
better). You have to enter 'sb rhubarb@xxx $' if you expect > it
to leave your own BBS.

   Several people have pointed out that this only happens with
MBL software. They're probably right: my local BBS is an MBL
system (whose sysop hasn't got around to changing), and it gets
a bit messy trying to send stuff from any others (I'd need to go
through a digipeater, and I get sick of waiting). I naturally
assumed they were all like that! (No wonder I got irate).
Apologies to all concerned.

   The point was, however, that there seems to be a strong
tendency to get the users to do strange things in order to
overcome bugs/deficiencies in the software. (I'm willing to bet
that a lot of the fossils are still typing the '$' when they
want to send a bulletin, long after the system has changed from
an MBL system to something else.) I suspect part of the problem
is that somebody gets a bright idea for his/her BBS program,
doesn't think it through, (and ABOVE ALL doesn't discuss it with
some of the other BBS authors), then we get stuck with the
results for a couple of years till it all blows away. Surely we
can do better than this? We are, after all, supposed to be in
the communications business.

   Currently the problem is that packet radio addresses look
like Internet addresses, and I wouldn't blame some poor sod who
didn't know the difference for sending mail to Outer Slobbovia
by mistake. (Somebody, of course, had to claim that a packet
address isn't an address after all: apparently it's a routing
hint. All I can say is that if it looks like a duck and quacks
like a duck, then I'm forced to assume it's a duck. Especially
when all my local sysops tell me that mail out of the local area
don't go nowhere without it). I think I'd agree with the poster
who suggested that changing the separator from '.' to something
else would be a good start.

.....Ron--                                  *** Ron Murray
(VK6ZJM) Internet: [e-mail]     "The world is
a pork chop" -- #44 in a series of profound sayings

------------------------------

End of Packet-Radio Digest V91 #198
****************************** Date: Wed,  7 Aug 91 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #199 To: packet-radio

Packet-Radio Digest         Wed,  7 Aug 91       Volume 91 :
Issue 199

Today's Topics:                         'NA' not unique.....
                      DSP Evalulation
Packet-Radio Digest V91 #198

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 6 Aug 91 16:22:59 GMT From: [e-mail]
Subject: 'NA' not unique..... To: [e-mail]

Someone earlier stated:> >  There is a small finite set of
countries in Europe.  The country > codes are well known and
don't change. > The country-set of Europe may be small, but not
always easy to define; at the moment it is subject to
change......! Are there ISO country-codes for Latvia, Lithuania,
Estonia, Serbia, Croatia...? Maybe the hams in 'new' European
countries will at least get to choose/use confusion-minimising
country-codes.

 Pete Lucas [e-mail] [e-mail]
PJML%IA.NWL.AC.UK@UKACRL

------------------------------

Date: 6 Aug 91 22:34:18 GMT From:
sun-barr!olivea!spool.mu.edu!rex!rouge!pc.usl.edu![e-mail]
Subject: DSP Evalulation To: [e-mail]

[e-mail] (Presley Smith) writes: >I am setting up a
packet station and plan to also do satellites in the future. >I
don't have a TNC and in shopping, I find that there are several
DSP units A 9600 baud packet modem that is serially interfaced
should be run at 19.2 kb and this can create a heavy interrupt
load.  A 16550a uart can help but I don't think current versions
of PG and PB make use of its FIFO buffer.

I'm leaning toward the TAPR DSP board since it is mounted inside
a PC and interfaces to the XT or AT bus.  No more serial port
bottlenecks.  Instead we'll have software interface problems ;-)

73,

-- -- James Dugal,    N5KNX        Internet: [e-mail] Associate
Director        Ham packet: n5knx@k5arh Computing Center        US Mail: PO
Box 42770  Lafayette, LA  70504 University of Southwestern
LA.    Tel. [phone]    U.S.A.

------------------------------

Date: 6 Aug 91 15:39:00 GMT From: [e-mail]
Subject: Packet-Radio Digest V91 #198 To: [e-mail]

Hello friends !

I restored e-mail activity after war and vacations.

.NA discussion triggered me. I allways think that packet radio
is HAM radio first, and digital communications second. Herewith
I would like to rise question on the packet radio history:

Why was strange, unknown, non-HAM standard chosen for addresses
? We have all grown up with HAM calls, HAM prefixes. I used YU
for Yugoslavia since my first QSO back in 1973, and W/K for USA.
All hams know this system, etc.

Then somebody decided this system is boring, and picked up
another standard list... Now, NA is Namibia and YUG is Yugslavia
and we have confusion. BBS mail is directed @YU and not @YUG, I
guess only some 5% of YU packeteers heard of .YUG ... And it is
.DEU and not .DL... Some countries picked one system, some
another. I allways send mail to @HA and not @HUN; @OE and not
@AUS - but @ITA and not @I. Anyhow, some BBS sysops can handle
both systems, some of them would never learn how to run BBS,
others are inbetween. Most used paths work, obscure are hadled
by sysops manually etc.

And there are still some more standards to rise confusion. How
about using car registrations list ? This is standard also, and
ALL europeans are quite used to it. In fact, children are rised
up with this standard, I knew D means Germany long before I ever
heard of ham-radio. [ maybe foreign cars are not common in US
and other parts, but I saw at least two while going to QRL this
morning].

Now... how about independent Slovenia ? SL is Sweeden in one
code; Siera Leone in another, South Luckyville in another...

Yes, of course, authorities would find an solution. My proposal
was to devide YU,YT,YZ,4N and 4O prefixes, so some YT or YZ
would mean Slovenia. [why should we use new codes, like S1 for
Slovenia and H1 for Croatia ? Thus, one small country would grab
all 5 nice prefixes of former YU] You can already see SLO on
cars. And so on.

Sigh. Maybe those picking .YUG, .HUN, .NA never heard of
prefixes and HAM calls ??

And before there is a stream of hate mail, please do not take me
too seriously. This is 80% joke.

good luck, peace to everybody !

      iztok, YU3FK

[e-mail]

[e-mail]

------------------------------

Date: 6 Aug 91 16:23:54 GMT From: [e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : re: 'NA'
country domain appears to be non-unique

1. Think you miss the point.  That address would be used on
internet. The gateway from internet to bbsnet (gotta call it
something!) would strip the '.ampr.org' when it did the transfer.

2. The bbsnet does indeed use rfc-822 addressing.  It simply is
not visible to most folks.  It is indeed used for all (that I'm
aware of) inter-network transfers via gateways.  It is at the
gateway that the network addresses must be resolved.

3. There is no chance that the bbsnet will change it's address
grammar. Again, it is the responsibility of the gateway to
properly translate addresses, if required.  Note that this is
already quite common within usenet - there are internet forms,
arpa forms, et al.

4. The real problem is that there are multiple domains, and the
existing software (and the existing 'standards') do not address
that fact.  Some domains are orthogonal to others: the
'ampr.org' example shows that. i.e. there are organizational
hierarchies, network connectivity hierarchies (remember 'An
address is not a route'?), and geopolitical hierarchies. To
address all three of the above hierarchies requires three
addresses. Note also my use of quotes around 'standards'.  There
are few actual standards in networking addresses.  There are
some 'requests for comment', some de facto standards, and a
(very few!) actual standards.  The ISO country naming comes to
mind as an 'actual standard' ... I don't have the ISO number
handy ...

So we have this problem ... users mostly don't understand much
of the above.  My suggestion is the same as yours: education.
No matter what we do with the software, users will make
mistakes.  I'm trying to get more involved here on usenet
because I'll probably write more software ...

Would  *MUCH*  rather carry on this discussion via bbsnet ...
then the audience would be much wider.

   ...  Hank

p.s. would you distribute this (or any other comments) wherever
you see fit?  I don't have access to distribution lists of
interested  parties ...

------------------------------

Date: 6 Aug 91 22:47:09 GMT From: [e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: 'NA' country
domain appears to be non-unique

Within the context of hostnames specified in accordance with
internet specifications, "wb6ymh.ampr.org" might be a domain, a
hostname, or both.  If it is a hostname, there is a mapping from
it to one or more IP address(es) and/or mail exchangers.  It
might also be a domain name, with mail exchanger(s) for it,
and/or hosts specified within it.  It is the custom for AMPRNET
(that's the ham tcp/ip network, to give it a name) to have only
callsigns for the host-level domain/host.  Thus we have
"wb6cyt.ampr.org" and "pc.wb6cyt.ampr.org" as possible
host/domain names.

However, in the ham packet radio BBS world, hostnames are simply
callsigns (with optional SSIDs).  Thus a mailbox specification
is "W0RLI@W0RLI", or "wb6cyt@wb6ymh-2".  That's because the word
on the right side of the "@" is always a ham radio callsign, and
they are unique worldwide.

What confuses things is that it is possible to include routing
information to be used as default routing hints in an address by
placing a dot followed by successively-larger enclosing
geographical regions, each separated by dots.  Thus we can have
"WB6CYT@WB6YMH.#SOCA.CA.USA.NA", which specifies that there is a
mailbox on host WB6YMH, in the SOuthern CAlifornia region of
CAlifornia of the USA of North America.  (The "#" prefix to the
SOCA indicates that it is an unregistered local subregional
routing designator that may not be unique.  This is because the
address scan takes place from narrow to large piecewise, fer
cripessake.)

A BBS in the ham packet radio network is free to ignore any of
the routing information found after a dot on the right-hand side
of the @ if it wishes - typically if it has direct knowledge of
a way to get mail directly to the addressed host.

Thus you see "addresses" that on the surface appear to be
syntactically identical, but have entirely different semantics
on the two networks.

The internet probably can't change (too big), and others have
rather stubbornly stated that the ham packet radio "BBSNET"
won't.

This is separate from the issue of gatewaying mail between the
two networks.  Ignoring for the moment issues of archaic
18th-century government telco monopoly protection, gateways can
handle it rather easily, in fact, by annexing any BBSNET traffic
return addresses into the ampr.org internet domain, discarding
routing hints in the process, yielding something like
"[e-mail]" as the return address as seen on the
internet side of the gateway.  On the BBSNET side of the
gateway, internet addresses would simply appear as
"[e-mail]", and the BBSNET people would have a single
routing entry from their host to their internet gateway for
"*.IN".  That's not complicated.

The gateway from BBSNET to internet could dynamically build a
BBSNET routing table from the routing hints supplied by mail
passing through the gateway; for example, mail from
"wb6cyt@wb6ymh.#soca.ca.usa.na" would become
"[e-mail]" as it left the gateway into the
internet, and the gateway would have built a routing table entry
that listed the routing hints for the "wb6ymh" BBSNET host as
"#soca.ca.usa.na".  Cooperating gateways might even arrange to
periodically share this info; I can think of a nifty way to do
it with DNS TXT RRs.  Of course the AMPR.ORG nameserver would
have to be updated with this info too.

I hope this clears up some of the muddle about what's happening
on the two networks.  It is essential to understand that we are
dealing with two completely separate networks with completely
separate methods of transport and routing.  It's only because
the addressing LOOKS the same that the problem occured in the
first place.

- Brian

------------------------------

End of Packet-Radio Digest V91 #199
****************************** Date: Thu,  8 Aug 91 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #200 To: packet-radio

Packet-Radio Digest         Thu,  8 Aug 91       Volume 91 :
Issue 200

Today's Topics:        'NA' country domain appears to be
non-unique (9 msgs)                          .NA and rapier wit
                         DSP Evalulation
Internet / packet gateway info                Using packet radio
to connect to work

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 7 Aug 91 07:43:13 GMT From:
mcsun!ukc!axion!kitkat![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

------------------------------

Date: 7 Aug 91 04:46:00 GMT From:
pa.dec.com!nntpd.lkg.dec.com!tkou02.enet.dec.com!jrdzzz.jrd.dec.c
om!jrdbdx.jrd.dec.com![e-mail] Subject: 'NA'
country domain appears to be non-unique To: [e-mail]

In article <[e-mail]>,
[e-mail] (Marc T. Kaufman) writes...
>[e-mail] (Hank Oredson) writes: >>3. There is no
chance that the bbsnet will change it's address grammar.

If FWD-NET (that's what we're saying in Japan for "bbsnet") does
not change the address scheme, it's getting harder to gateway
the two networks.

>Amateur radio does not stand alone, and >you can not pretend
that the decisions you make (e.g. re: geographic >routing) are
irrelevant to the outside world, because users "should know"
>the difference.

I have nothing personal against Hank Oredson, so the following
paragraph has no intention to insult him.  I just want to
express my general feelings on people who are using FWD-NET.

All I can say on this issue is: Leave those who want to
self-indulge in the close world of ham radio.  Leave them alone
because they don't care they are getting behind.

I don't want to get behind.  And PRUG people around me do not
want to get incompatible with Internet either. And PRUGNET wants
to get connected with FWD-NET if they allow (They do NOT). :-<
*sigh*

>Well, just what are YOU going to do about educating YOUR users
to not use >bbsnet addresses on Internet?

I think Hank is not solely responsible on this issue. So don't
blame him alone.

My opinion is: if you want to introduce geographical routing,
don't put it in your address explicitly. All you need on to
identify a person on FWD-NET is user@host, both user and host
are callsigns.

>Marc Kaufman ([e-mail])

-- Kenji, JJ1BDX

------------------------------

Date: 7 Aug 91 17:02:05 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

       System IDentifier (SID)

The initial exchange between "smart" MailBox systems uses what
is called an "SID", short for System IDentifier.  All future
work on MailBox systems should adopt this standard.  It will
help to remove a GREAT deal of confusion as to which systems
have what features, and how one should interface to them.  In
the longer future, perhaps all this junk can be done away with,
and the computers can talk to each other in a more natural way.

     The system identifier is structured:

     "[f1-f2-f3]"

The dashes delimit the end of the first field and the start of
the last. There might be only one dash, if f2 is void. f2 may
contain dashes.

f1, f2, and f3 may not contain "[" or "]".

f1 is the author identification.  It may not contain a dash.
Normally it will contain a few characters from the authors
callsign.

f2 is author specific data. It may contain anything the author
wishes, for example software version. It may contain dashes.

f3 is the supported feature set.  It may not contain a dash. It
contains a string of non-numeric characters, one for each
negotiable feature supported.  Each character may also have
trailing digits, giving the revision of that feature.  If there
is no trailing digit, the feature revision is revision zero.

Defined features are:

C - Supports "forwarding" of date and time (obsolete). H -
Supports hierarchical location identifiers. M - Supports message
identifiers. R - Supports extended forwarding responses. Y -
Supports YAPP binary protocol (unused). $ - Supports BID.  MUST
BE LAST CHARACTER IN f3 for downward compatibility.

The existance of the system ID implies that the system supports
reverse forwarding and OK/NO message rejection.

Some examples of existing standard system identifiers:

[RLI-12.0-H$]          - w0rli version 12.0, supports BID and H
location. [CBBS-5.1-$]          - ag3f release of the rli/gyq cbbs.
[MSYS-1.11-H$]          - wa8bxn version 1.11, supports BID and H
location. [MBL-5.14-H$]          - wa7mbl V5.12, supports BID and H
location. [4RE-2.3-MH$]          - aa4re V2.3, supports MID, BID,
and H location.



The connect rules:

Send the SID as first line at connect. Answer the SID (when seen
as a command) with a short command prompt.



The forwarding rules:

If you do not see an SID at connect, use the old style
fowarding. This handles the case of Xerox 820 systems, for
example.

If you do see an SID at connect, answer with your SID. Use
whatever features are appropriate.



  The message entry command:

Sx TO [@ BBS[.LOC]] [< FROM] [$[BID]]

x may be B, T, or P. If x is absent, P is assumed if TO is a
callsign, otherwise B is assumed. The $ is not part of the BID,
but identifies the field. There is no space between the "$" and
the BID.  If only the "$" is present, a system generated unique
BID will be supplied. The spaces surrounding the @ may be
omitted.



  OK/NO message rejection.

Instead of sending the "S" command and Title, send only the "S"
command. The remote system will reply with either OK or NO,
possibly followed by some text.  If the response is NO, it will
be followed by a prompt. If the response is OK, then go ahead
and forward the message.  Usually, NO will only be seen if you
attempt to forward a message with BID already known to the
receiving system.    It may also be seen in the case of full disk,
or any other reason the receiving system does not want the
message. Possiblities under discusion range from "I do not
handle NTS traffic." to "I do not know that user, nor any route
to reach him."

Note that only the "N" or "O" are required.

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 7 Aug 91 17:35:25 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

My comments with *** ...

<Ummm ... wait a sec ... flame thrower is in the garage ...>

   ...  Hank

Newsgroups: rec.radio.amateur.packet From:
[e-mail] (Marc T. Kaufman) Subject: Re: 'NA'
country domain appears to be non-unique Message-ID:
<[e-mail]> Organization: Computer
Science Department, Stanford University, Ca , USA References:
<[e-mail]> <[e-mail]>
<[e-mail]>
<[e-mail]> Date: Wed, 7 Aug 1991
00:58:54 GMT

[e-mail] (Hank Oredson) writes:

>1. Think you miss the point.

Actually, Hank, it is YOU who miss the point.  The problem is
NOT the gateway function, it is that bbsnet has deliberately
adopted an address syntax that will often "work" on internet,
albeit incorrectly.  This, coupled with naive users, can and
does lead to mail sent to, e.g. Namibia. Now, no one would give
a hoot about this except that it is costing the Namibians real
$$ money to receive and bounce (or ignore the mail).

***  Sorry, I'm not in charge of anything at all within
internet. ***  As with everything else, ignorant users will make
a mess. ***  That's too bad, and can only be changed by
education. ***  Please post some education.

>3. There is no chance that the bbsnet will change it's address
grammar.

Thanks for your cooperation.  That's what makes Amateur Radio
great. You're the one primarily responsible for relegating
amateur radio protocols to the lowest possible levels that a
512K PC-XT can support -- and be damned with the rest of the
world.  Amateur radio does not stand alone, and you can not
pretend that the decisions you make (e.g. re: geographic
routing) are irrelevant to the outside world, because users
"should know" the difference.

***  "Cooperation"?  What is it you would like me to do? ***
Now that you have told me what *NOT* to do, tell me what ***  it
is I  *SHOULD* do. ***  i.e. you didn't say anything useful here
... ***  Anyway ... the problem is not in the grammar.

>So we have this problem ... users mostly don't understand much
of the >above.  My suggestion is the same as yours: education.
No matter >what we do with the software, users will make
mistakes.  I'm trying to >get more involved here on usenet
because I'll probably write more software ...

Well, just what are YOU going to do about educating YOUR users
to not use bbsnet addresses on Internet?

***  "MY Users"  have never used a bbsnet address on internet.
***  Probably never will, since the only user on this machine is
me, ***  and I  *DO*  understand the issues.

Marc Kaufman ([e-mail])

***  Well Marc,  we (the bbs authors) await your suggestions.
***  What is it we should do?  How should we do that? ***  While
doing that (whatever it is) keep in mind that we ***  wish to
support only a small number of users (about 100,000) ***  with
only a small number of servers (about 10,000), and that ***
those users will often have *NO* local processing capability.
***  So post some useful ideas please, since it sounds like you
***  know what the solutions are.

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 7 Aug 91 17:45:37 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

  My comments with "***"

Newsgroups: rec.radio.amateur.packet From:
[e-mail] (Marc T. Kaufman) Subject: Re: 'NA'
country domain appears to be non-unique Message-ID:
<[e-mail]> Organization: Computer
Science Department, Stanford University, Ca , USA References:
<[e-mail]> <[e-mail]>
<[e-mail]>
<[e-mail]>
<[e-mail]>
<[e-mail]> Date: Wed, 7 Aug 1991 16:32:06 GMT

First, let me apologize for the strident tone of my last
posting.  I really have nothing personal against Hank, and I am
even one to appreciate all he has done for the amateur BBS
community.

***  Ok ... I'll also appologize for my flame ... (ain't this
fun!)

However, there are some folks out there who just do not
understand the issue. for example:

[e-mail] (Kurt Freiberger) writes:

>  OK, by the same token, all other mail systems in the world,
if they want to >gateway into the Internet, must change their
addressing scheme to match the >Internet??  N.F.W.!!!!  As a
W0RLI BBS op for many years,  I can say that  >traffic went very
well all over the globe, thank you, WITHOUT the "benefit" >of
the Internet.  Hank did a damn fine job with his stuff.  It
worked.   >To change the whole BBSnet to a "compatible"
addressing scheme would mean  >that all of the BBSes,
simultaneously, would have to change to the new code. >Get real!
 It'll never happen.  And, why should it?

I *DID NOT SAY* that the BBS adressing scheme should be
compatible with Internet.  In fact, what I *DID* say was that
the BBS addressing scheme should *NOT* be compatible with the
internet -- in the sense that a BBS address, if inadvertently
used to address a piece of mail on the Internet (by a confused
or naive user) should *NOT* accidently route to places like
Namibia, that cost real money to unsuspecting end users (in
Namibia) who have no desire to play amateur radio games.

Once again: this is *NOT* a gateway issue.  Gateways can do
(almost) anything. This is a *USER CONFUSION* issue, where a
user uses the wrong address for the network he is on.  It is
akin to the UK folks writing their addresses backwards.  No one
cares, in general, if a few pieces of mail get bounced. However,
this confusion is costing real people real money.

***  It is indeed a gateway issue.  It is ONLY at the gateways
that ***  the networks meet.  The gateway must know about
addresses on ***  either side of the gate, and do the "proper
thing" with them. ***  The issue of user eductation remains the
same, in both networks. ***  Attempting to call me on the
telephone by dialing my home ***  address simply will not work,
nor will it work very well if you ***  attempt to send mail to
my phone number, or send me an internet ***  message by using my
bbsnet address.

The BBS folks deliberately ignored the pleas of the Internet
folk to adopt a different address syntax when geographic
"routing hints" were first adopted.  Because of this, I think
the BBS folks have the primary responsibility to alleviate the
confusion.  If you don't, even the gateways will be denied to
you (cf: the Japanese FWD-NET).

***  What pleas?  "We" not only heard nothing, we got NO
cooperation ***  in the form, for example of providing copies of
the pertinent ***  standards.  Now, some 4 years after the
initial bbsnet implementation, ***  we find there is a problem
... this is not a big surprise. ***  So ... send us some
standards documents ... then we can read them.

Marc Kaufman ([e-mail])

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 7 Aug 91 17:05:39 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

There is a "BID" (Bulletin IDentifier) associated with each
bulletin type message and with any message which has a
distribution list.

If a BID is not given explicitly with the "Send" command, one is
created automatically from the message number and callsign of
the MailBox into which the message was initially entered. It has
the form nnn_call.

There are 3 types of messages:

1) Personal.    If sent with SP, or with S and to a callsign.

2) NTS traffic. If sent with ST.

3) Bulletins.    If sent with SB, or with S and NOT to a callsign.

For Bulletins, a BID is ALWAYS associated with the message, and
is sent when forwarding to systems that indicate in their SID
that they  accept BIDs.

For Personal, the message can only be read by the sender,
addressee, and sysop.

There are several "flags" associated with each message.  These
are shown in the "message status" position in the "list message"
display.  Note that each flag has an associated "L" command, and
some have associated "K" commands.

   F - The "Forwarded" flag:

       This indicates the message has been forwarded to all
 its destinations, but has not yet been killed.

   H - The "Hold" flag:

       This indicates the message is held.       It will not
forward, and can only be seen by the sysop.

   I - The "In process" flag:

       This indicates the message is in the process of being
forwarded.

   K - The "Killed" flag:

       This indicates the message is killed, but has not yet
been purged       from the system.  Killed messages are purged
with the GM command.

   O - The "Old" flag:

       This indicates the message has been hanging around
un-forwarded and un-read for too long.

   Y - The "Read" flag:

       This indicates the message has been read by its
addressee,       but has not yet been killed.

 How do BID's work?

The various commands (S, M, CM) work in exactly the same way.
The basic command is S[type] TO [@ AT[.LOC]] [< FROM] [$[BID]]
Data inside [] may be omitted.

Messages differ in the following ways:

   TO may be translated.   TO is a callsign.   TO is an interest
group.   AT may be translated.   AT is a callsign.   AT is a
distribution list.   $ field is present.   $ field is present,
with BID.   Type is B   Type is P   Type is T   Type was not
specified.   Message is held.

A type B or P message gets a BID if the command that creates the
message has the "$" field.  A message of type B gets a default
BID if none was specified.  A message of type P gets a default
BID if none was specified and it has a distribution list.  A
message of type T never gets a BID. In the discussion below, the
same rules apply whether the message was created using the S, M,
or CM commands.

Here is how the system behaves:

1) If the user sends the message with "$ID" given in the
command,   the message is assigned identifier "ID".  If this
identifier   has been seen before, the message is rejected and
the text   "NO - Duplicate BID" is displayed.

2) If the user sends the message with "$" given in the command,
 the message is assigned a unique MailBox generated BID.  This
BID   is generated from the message number and callsign of the
MailBox.   The message is accepted, since this BID cannot have
been seen before.

3) If there is a distribution list, and a BID is not given with
the command,   a unique MailBox generated BID is assigned.    This
BID is generated from the   message number and callsign of the
MailBox OF ORIGIN.  If this BID has been   seen before, the
message is put on hold.

5) If a message is received from another MailBox, and has a BID
 sent along with it, and has a distribution list that includes
the MailBox from which the message was received, the message is
 marked as already forwarded to that MailBox.

Some results of applying these rules:

1) A message entered into the system without using "$" in the
command   and without a distribution list may loop within the
network.   These messages are held after they have passed
through the system   a small number of times, normally two.

2) A message which was entered with a "$" given in the command
will be rejected when it is forwarded back to any system it
previously passed through.

3) Messages of type B or P may have a distribution list,
messages of type T may not.

4) There will be no attempt to pass a message which has a BID
back to the station that sent it to you.

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 7 Aug 91 17:16:15 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

         INTERNATIONAL ROUTING DESIGNATORS

  Lew Jenkins, N6VV  David B. Toth, M.D., VE3GYQ  H. N. "Hank"
Oredson, W0RLI

  c/o Dr. D. B. Toth  499 Bobbybrook Drive  London, Ontario,
Canada  N5X 1G8

 It has become obvious by now that the work-horse of our
so-called packet network is the venerable BBS program. In fact,
some will argue that it has been too successful. Every time that
a band-aid is needed to "fix" the network, it is applied through
the various BBS programs. It is probably fair to say that the
maintenance of the forwarding tables is a drudgery that most
sysops could do without. This point also under-scores a serious
problem faced by all networks: ROUTING.

 With the introduction of W0RLI V7.00 and support for
Hierarchical routing designators, we have an opportunity to
improve traffic routing particularly for international traffic.
Since N6VV is at the present time responsible for traffic to
Asia and the Pacific, and occasionally Europe and Africa, he has
implemented some Hierarchical routing designators which will
assist him in international routing.

 Using this structure mail can now be addressed :

          JA1ABC @ JA1KSO.JPN.AS

          or

      VK4AHD @ AX4BBS.AUS.AU

 Starting today you can begin using Continental and Country
designators for international traffic destined for Asia and the
Pacific. A forward file may be set up to support the following
codes:

              ** Continental Designators **

  AF  - Africa  AS  - Asia  AU  - Australia  EU  - Europe  NA  -
North America  OC  - Oceana  SA  - South America

              **   Country Designators     **

For country codes there is a generally accepted international
standard for abreviations. These are used in international
electronic message standards such as ANSI X.12 and EDIFACT. They
are published by the International Standards Organization and
known formally as ISO 3166-1981(E/F).

--------------------------- CUT HERE
---------------------------------

Country codes (abbreviated list to show common country codes):

Argentina             ARG      Japan               JPN Australia             AUS
Korea,North           PRK Austria              AUT      Korea,South           KOR
Belgium              BEL      Lebanon               LBN Bermuda              BMU
Liechtenstein           LIE Bolivia              BOL      Luxembourg           LUX
Brazil                 BRA      Malaysia               MYS Brunei                 BRN
Mexico               MEX Bulgaria             BGR      Monaco               MCO
Canada                 CAN      Morocco               MAR Chile                 CHL
Netherlands           NLD China                 CHN      New Zealand           NZL
Colombia             COL      Nicaragua            NIC Costa Rica             CRI
    Norway               NOR Cuba                 CUB      Pakistan               PAK
Denmark              DNK      Panama               PAN Dominican Republic
DOM      Paraguay               PRY Ecuador              ECU      Peru               PER
Egypt                 EGY      Phillipines           PHL El Salvador             SLV
    Poland               POL Finland              FIN      Portugal               PRT
France                 FRA      Romania               ROM French Polynesia
PYF      Saudi Arabia           SAU German Demo. Rep.         DDR
Singapore            SGP Germany, Federal Rep         DEU      South
Africa           ZAF Greece                 GRC      Spain               ESP Greenland
    GRL      Sweden               SWE Guatemala             GTM
Switzerland           CHE Haiti                 HTI      Syria               SYR
Honduras             HND      Taiwan               TWN Hong Kong             HKG
Thailand               THA Hungary              HUN      Turkey               TUR
Iceland              ISL      United Kingdom           GBR India                 IND
    United States           USA Indonesia             IDN      Uruguay
URY Ireland              IRL      USSR               SUN Israel                 ISR
Venezuela            VEN Italy                 ITA      Yugoslavia           YUG

State and province codes shall be the recognized two-character
code established by the American and Canadian Post Offices.
These may also be found in the Callbook listings.

It is after we get down to the state/province/county level where
the trouble may begin. To understand why, we must examine how
the BBS code goes about matching things in the route. The first
principle is that it attempts to find a match between the items
in its forward file and the left-most item in the address field.
As an example, say that we send something to W0RLI @
W0RLI.OR.USA.NA, and that the only entries

--------------------- CUT HERE
-------------------------------------

that we have in the forward file are for CA. That match would be
sufficient to allow the message to be forwarded. If W0RLI were
found, that entry would take precedence (because it is more left
in the field than CA) and would of course also ensure delivery.
The best way to look at it is "W0RLI AT W0RLI which is in OR
which is in USA which is in NA". So far so good.

But the Japanese network wants to use area routing numbers. For
example,  JA1ABC @ JA1KSO.42.JPN.AS ... and everyone says, "So
what, let them!" Of course, that is very mature of all of us,
but the trouble is that the 42 in that string may also match
wild-card ZIP codes that some folks keep in their forward file,
such as 42*. The solution we propose is to use an agreed upon
key character for designators below the state and province
level, and we recommend the octothorpe, "#".

So now the above address would be JA1ABC @ JA1KSO.#42.JPN.AS .
Other examples could be:

1) W0RLI @ W0RLI.#PDX.OR.USA.NA - W0RLI within PDX (Portland)
within Oregon, etc.

2) VE3BTZ @ VE3GYQ.#LONDN.#SONT.ON.CAN.NA - VE3BTZ at VE3GYQ in
 London, in Southern Ontario, in Ontario, etc.

There is another added benefit to this scheme. It involves
Gatewaying between the BBS world and other networks, such as
TCP/IP via SMTP. Much of the pioneer work in setting up the
gatewaying protocols has been done by NN2Z, N3EUA, and PA0GRI,
amongst others. The W0RLI BBS package allows for the forwarding
of mail between the BBS world and the SMTP world. Of note is the
fact that the WA7MBL package has allowed such message exporting
and importing for some time now. This means that we can take
advantage of the the TCP/IP host-names and their domain or
hierarchal format for forwarding. Thus it is possible to send
mail from the BBS to VE3BTZ as [e-mail] or from
SMTP to [e-mail] and not have any ambiguity.

WA7MBL versions 5.13 and later are compatible with hierarchal
routing. This system is still compatable with older style
systems, as a system that handles hierarchal forwarding
identifies with the H feature letter: [RLI-8.00-CH$]. If it does
not get an appropriate response, it uses the left-most item in
the "@ BBS" string as the "@ BBS" for the message.

The authors hope that this paper will serve as a starting place
for improved message routing by means of implicit routing.
Low-level (VHF) BBSs need only maintain state or province or
country codes for distant BBSs, and route such traffic to their
nearest HF Gateway. In turn, the HF station routes it to the
desired state, where the receiving Gateway station would have a
detailed list of the BBSs it serves.

Correspondence may be addressed to the address given at the
start of this paper, or to VE3GYQ @ VE3GYQ.ON.CAN.NA or N6VV @
N6VV.CA.USA.NA .

 ***************************************************************
* * * * * *   D I G I T A L   R A D I O   N E W S   * * * * * *
***************************************************************

     * * * *   KEEPING YOUR SYSOP HAPPY   * * * *

Sysops    have  to  be  an  unusual  breed.  They assume    massive
responsibility,  give up large blocks of time to nurse-maid the
network and put up with a lot of hassle.  I  suspect  that they
somehow enjoy what they do.  At the same time, it's this rather
parculiar behavior of these very SYSOPS that gives mortals like
you and I the pleasure of using the PBBS NETS.

These guys are OK.

I think that the least we (as mear mortals) can do to add  some
glow  to  the  dreary  life  of  the  SYSOP, is  to  use proper
addressing.  The key phrase is: HIERARCHAL ADDRESSING.

Hierarchical  Addressing   makes  your    SYSOP's  job  easy  by
affording  automatic  routing  of  all    messages.  Your  SYSOP
doesn't have to stay up all hours manually digging out routing
paths  for  your  message.   It  also gets your message to its
destination MUCHO POSTO-QUICKO !

EXAMPLE 1:

   Ed's Hierarchal Address:  KB6DRN @ K6RAU.#NOCAL.CA.USA.NA

       Ed's Call--------: KB6DRN       Ed's PBBS--------: K6RAU
     Ed's Local Region: #NOCAL (optional)       Ed's
State-------: CA       Ed's Country-----: USA       Ed's
Continent---: NA

EXAMPLE 2:

   Marks's Hierarchal Address:  WB9QZB @ N3AIA.IL.USA.NA

       Mark's Call------: WB9QZB       Mark's PBBS------: N3AIA
     Mark's State-----: IL       Mark's Country---: USA
Mark's Continent-: NA

(There is also an international list of these labels in the
"W-Files" of many PBBS Boxes) By  addressing each and every
message with this method you can attempt  to  make  your SYSOP
HAPPY.   I Realize that the term "HAPPY SYSOP" may  be  a  bit
of  a paradox, however as  mear mortals we should make every
attempt to work towards this goal:

1.  USE THE HIERARCHAL ADDRESS

2.  INCLUDE THE HIERARCHAL ADDRESS IN THE BODY OF YOUR MESSAGE.

3.  BE NICE TO YOUR SYSOP.

ED/KB6DRN @ K6RAU.#NOCAL.CA.USA.NA

***  The following was provided by JA1KSO  ***

Following list is the world-wide country codes recognized by
ISO, prefixes recognized by ITU, and continental separation
recognized by IARU.

Note: This list was completed by refering ISO-3166/JIS X 0304

(3-ISO) (2-ISO) (3N-ISO) PREFIX   CONTINENT  COUNTRY AFG    AF    004
T6/YA       AS         AFGANISTAN ALB    AL    008     ZA       EU         ALBANIA
DZA    DZ    012     7X       AF         ALGERIA ASM    AS    016     KH8       OC
AME.SAMOA AND    AD    020     C3       EU         ANDORRA AGO    AO    024     D2
AF         ANGOLA ATA    AQ    010     8J/KC4..  AF/AN     ANTARCTICA
ATG    AG    028     V2       NA         ANTIGUA ARG    AR    032     LU       SA
ARGENTINA AUS    AU    036     VK       OC         AUSTRALIA AUT    AT    040     OE
EU         AUSTRIA BHS    BS    044     C6       NA         BAHAMAS BHR    BR    048
A9       AS         BAHRAIN BGD    BD    050     S2       AS         BANGLADESH
BRB    BB    052     8P6       NA         BARBADOS BEL    BE    056     ON       EU
BELGIUM BLZ    BZ    084     V3       NA         BELIZE BEN    BJ    204     TY       AF
  BENIN BMU    BM    060     VP9       NA         BERMUDA BTN    BT    064     A5       AS
    BHUTAN BOL    BO    068     CP       SA         BOLIVIA BWA    BW    072     A2
AF         BOTSWANA BVT    BV    074     3Y       AF         BOUVET I. BRA    BR    076
PY       SA         BRAZIL IOT    IO    086     VQ9       AF         CHAGOS ARCH
VGB    VG    092     VP2V       NA         BR.VIRGIN IS BRN    BN    096     V8       OC
  BRUNEI BGR    BG    100     LZ       EU         BULGARIA BUR    BU    104     XZ
AS         BURMA BDI    BI    108     9U5       AF         BURUNDI BYS    BY    112
UC2       EU         BYELORUSSIAN SSR CMR    CM    120     TJ       AF
CAMEROON CAN    CA    124     VE       NA         CANADA CTE    CT    128     KH1/T3
OC         CANTON IS CPV    CV    132     D4       AF         CAPE VERDE
CYM    KY    136     ZF       NA         CAYMAN IS CAF    CF    140     TN       AF
C.AFRICAN REP TCD    TD    148     TT       AF         CHAD CHL    CL    152     CE
SA         CHILE CHN    CN    156     BY       AS         CHINA CXR    CX    162     VK9X
 OC         XMAS I CCK    CC    166     VK9Y       AF         COCOS KEELING
COL    CO    170     HK       SA         COLOMBIA COM    KM    174     D6       AF
COMOROS COG    CG    178     TN8       AF         CONGO COK    CK    184     ZK1       OC
   COOK IS CRI    CR    188     TI       NA         COSTA RICA CUB    CU    192
T4/CO/CM  NA         CUBA CYP    CY    196     P3/ZC4    AS         CYPRUS
CSK    CS    200     OK/OL/OM  EU         CZECHOSLOVAKIA DNK    DK    208     OZ
EU         DENMARK DJI    DJ    262     J2       AF         DJIBOUTI DMA    DM    212
J7       NA         DOMINICANA DOM    DO    214     HI       NA         DOMINICAN REP
ATN    NQ    216           SA/AN     DRONNING MAUD LAND TMP    TP    626     YB
OC         EAST TIMOR ECU    EC    218     HC       SA         ECUADOR EGY    EG    818
SU       AF         EGYPT SLV    SV    222     YS       NA         EL SALVADOR
GNQ    GQ    226     3C       AF         EQUATORIAL GUINEA ETH    ET    230     ET
AF         ETHIOPIA FRO    FO    234     OY       EU         FAEROE IS FLK    FK    238
VP8       SA         FALKLAND IS FJI    FJ    242     3D       OC         FIJI
FIN    FI    246     OF/OG/OH  EU         FINLAND FRA    FR    250     F       EU
FRANCE GUF    GF    254     FY       SA         FR GUIANA PYF    PF    258     FO       OC
    FR POLYNESIA GAB    GA    266     TR       AF         GABON GMB    GM    270     C5
  AF         GAMBIA DDR    DD    278     Y2..       EU         GERMAN DEMOCRATIC
REP DEU    DE    280     DJ/DK/DL  EU         GERMANY GHA    GH    288     9G       AF
   GHANA GIB    GI    292     ZB2       EU         GIBRALTAR GRC    GR    300     SV
EU         GREECE GRL    GL    304     OX       NA         GREENLAND GRD    GD    308
J3       NA         GRENADA GLP    GP    312     FG       NA         GUADELOUPE
GUM    GU    316     KH2       OC         GUAM GTM    GT    320     TG       NA
GUATEMARA GIN    GN    324     3X       AF         GUINEA GNB    GW    624     J5       AF
    GUINEA-BISSAU GUY    GY    328     8R       NA         GUYANA HTI    HT    332
HH       NA         HAITI HMD    HM    334     VK0       AF         HEARD I
HND    HN    340     HR       NA         HONDURAS HKG    HK    344     VS6       AS
HONG KONG HUN    HU    348     HA/HG       EU         HUNGARY ISL    IS    352     TF
EU         ICELAND IND    IN    360     VU       AS         INDIA IDN    ID    360     YB
 OC         INDONESIA IRN    IR    364     EP       AS         IRAN IRQ    IQ    368
YI       AS         IRAQ IRL    IE    372     EI       EU         IRELAND ISR    IL    376
4X/4Z       AS         ISRAEL ITA    IT    380     I       EU         ITALY
CIV    CI    384     TU       AF         IVORY COAST JAM    JM    388     6Y5       NA
JAMAICA JPN    JP    392     J       AS         JAPAN JTN    JT    396     KH3       OC
 JOHNSTON I. JOR    JO    400     JY       AS         JORDAN KHN    KH    116     XU
AF         KAMPUCHEA(CAMBODIA) KEN    KE    404     5Z/5Y       AF         KENYA
KIR    KI    296     T3       OC         KIRIBATI PRK    KP    408     P5       AS
D.P.R. OF KOREA KOR    KR    410     HL/HM       AS         REP OF KOREA
KWT    KW    414     9K       AS         KUWAIT LAO    LA    418     XW       AS         LAOS
LBN    LB    422     OD       AS         LEBANON LSO    LS    426     7P       AF
LESOTHO LBR    LR    430     EL       AF         LIBERIA LBY    LY    434     5A       AF
   LIBYA LIE    LI    438     HE/HB0    EU         LIECHTENSTEIN LUX    LU    442
LX       EU         LUXEMBOURG MAC    MO    446     XX9       AS         MACAU
MDG    MG    450     5R8       AF         MADAGASCAR MWI    MW    454     7Q       AF
MALAWI MYS    MY    458     9M       AS         MALAYSIA MDV    MV    462     8Q       AF
   MALDIVES MLI    ML    466     TZ       AF         MALI MLT    MT    470     9H       EU
    MALTA MTQ    MQ    474     FM       NA         MARTINIQUE MRT    MR    478     5T
AF         MAURITANIA MUS    MU    480     3B8       AF         MAURITIUS
MEX    MX    484     XE/XF/4A  NA         MEXICO MID    MI    488     KH4       OC
MIDWAY MCO    MC    492     3A       EU         MONACO MNG    MN    496     JT       AS
 MONGOLIA MSR    MS    500     VP2M       NA         MONTSERRAT MAR    MA    504     CN
  AF         MOROCCO MOZ    MZ    508     C9       AF         MOZAMBIQUE
NAM    NA    516     ZS3       AF         NAMIBIA NRU    NR    520     C2       OC
NAURU NPL    NP    524     9N       AS         NEPAL NLD    NL    528     PA       EU
NETHERLAND ANT    AN    532     P4       SA         NETH. ANTILLES NTZ    NT    536
8Z4       AS         NEUTRAL ZONE NCL    NC    540     FK       OC         NEW
CALEDONIA NZL    NZ    554     ZL/ZM       OC         NEW ZEALAND NIC    NI    558
YN       NA         NICARAGUA NER    NE    562     5U       AF         NIGER
NGA    NG    566     5N       AF         NIGERIA NIU    NU    570     ZK2       OC
NIUE NFK    NF    574     VK9N       OC         NORFOLK I NOR    NO    578     LA       EU
    NORWAY OMN    OM    512     A4       AS         OMAN PCI    PC    582     KH0...
OC         MARIANA/PACIFIC IS PAK    PK    586     AP       AS         PAKISTAN
PAN    PA    590     HP       NA         PANAMA PNG    PG    598     P2       OC         PAPUA
NEW GUINEA PRY    PY    600     ZP       SA         PARAGUAY PER    PE    604     OA
SA         PERU PHL    PH    608     DU/DX       OC         PHILIPPINES
PCN    PN    612     VR6       OC         PITCAIRN I POL    PL    616     SP/SQ       EU
  POLAND PRT    PT    620     CT/CS       EU         PORTUGAL PRI    PR    630     KP4
 NA         PUERTO RICO QAT    QA    634     A7       AS         QATAR REU    RE    638
FR       AF         REUNION ROM    RO    642     YO       EU         ROMANIA
RWA    RW    646     9X       AF         RWANDA SHN    SH    654     ZD7       AF
ST.HELENA KNA    KN    658     VP2K/VP2E NA         ST.KITTS-ANGUILLA
LCA    LC    662     J6       NA         ST.LUCIA SPM    PM    666     FP       NA
ST.PIERRE/MIQUELON VCT    VC    670     J8       NA
ST.VINCENT/GRENADINES WSM    WS    882     5W       OC         SAMOA
SMR    SM    674     T7/M1       EU         SAN MARINO STP    ST    678     S9       AF
 SAO TOME AND PRINCIPE SAU    SA    682     HZ/7Z       AS         SAUDI ARABIA
SEN    SN    686     6W       AF         SENEGAL SYC    SC    690     S7       AF
SEYCHELLES SLE    SL    694     9L       AF         SIERRA LEONE SGP    SG    702
9V       AS         SINGAPORE SLB    SB    090     H4       OC         SOLOMON IS
SOM    SO    706     T5/6O       AF         SOMALIA ZAF    ZA    710     ZS/ZR       AF
 SOUTH AFRICA ESP    ES    724     EA       EU         SPAIN LKA    LK    144     4S7
AS         SRI LANKA SDN    SD    736     ST       AF         SUDAN SUR    SR    740
PZ       SA         SURINAME SJM    SJ    744     JX/JW       EU         SVALBARD/JAN
MAYEN SWZ    SZ    748     3D6       AF         SWAZILAND SWE    SE    752     SM/SL/SK
EU         SWEDEN CHE    CH    756     HB       EU         SWITZERLAND SYR    SY    760
YK       AS         SYRIA TWN    TW    158     BV       AS         TAIWAN TZA    TZ    834
5H       AF         TANZANIA THA    TH    764     HS       AS         THAILAND
TGO    TG    768     5V       AF         TOGO TKL    TK    722     ZM7       OC
TOKELAU TON    TO    776     A35       OC         TONGA TTO    TT    780     9Y       NA
  TRINIDAD AND TOBAGO TUN    TN    788     3V       AF         TUNISIA
TUR    TR    792     TA       AS/EU     TURKEY TCA    TC    796     VP5       NA
TURKS AND CAICOS IS TUV    TV    798     T2       OC         TUVALU UGA    UG    800
5X       AF         UGANDA UKR    UA    804     UB5       EU         UKRAINEAN SSR
ARE    AE    784     A6       AF         UNITED ARAB EMIRATES GBR    GB    826     G
EU         UNITED KINGDOM USA    US    840     W/K/N       NA         UNITED
STATES OF AMERICA PUS    PU    849     KH1,5..   OC         US MISCELLANEOUS
PAC IS VIR    VI    850     KP2       NA         US VIRGIN IS HVO    HV    854     XT2
 AF         UPPER VOLTA URY    UY    858     CX       SA         URUGAY
SUN    SU    810     UA...       EU/AS     U.S.S.R. VUT    VU    548     YJ       OC
 VANUATU VAT    VA    336     HV       EU         VATICAN CITY VEN    VE    862     YV
 SA         VENEZUELA VNM    VN    704     3W/XV       AS         VIETNAM
WAK    WK    872     KH9       OC         WAKE I WLF    WF    876     FW       OC
WALLIS AND FUTUNA IS ESH    EH    732     S0       AF         WESTERN SAHARA
YEM    YE    886     4W       AS         YEMEN YMD    YD    720     7O       AS         P.D.R.
OF YEMEN YUG    YU    890     YU/YT       EU         YUGOSLAVIA ZAR    ZR    180     9Q
  AF         ZAIRE ZMB    ZM    894     9J       AF         ZAMBIA ZWE    ZW    716     Z2
  AF         ZIMBABWE

  BY  JA1KSO/AH6HX  (C) NOB ITOH  --

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 7 Aug 91 21:43:00 GMT From:
haven.umd.edu!uvaarpa!murdoch![e-mail] Subject: 'NA'
country domain appears to be non-unique To: [e-mail]

In article <[e-mail]>
[e-mail] writes:

>         INTERNATIONAL ROUTING DESIGNATORS > >  Lew Jenkins, N6VV >
David B. Toth, M.D., VE3GYQ >  H. N. "Hank" Oredson, W0RLI > >
c/o Dr. D. B. Toth >  499 Bobbybrook Drive >  London, Ontario,
Canada >  N5X 1G8 > [ stuff deleted here ] > Starting today you
can begin using Continental and Country designators > for
international traffic destined for Asia and the Pacific. A
forward > file may be set up to support the following codes: >
>              ** Continental Designators ** > >  AF  - Africa >  AS
- Asia >  AU  - Australia >  EU  - Europe >  NA  - North America
>  OC  - Oceana >  SA  - South America

If these are not CHANGED to be different from all ISO standard 2
letter country codes then there will continue to be problems
caused by amateurs who don't make absolutely clear which
addresses are Amateur Packet Radio network addresses and which
are Internet addresses.

This practice of using ".NA", which is the ISO standard
two-letter country code for Namibia,  to mean North America is a
critical problem.

Simply moving to say 4 letter continent codes, or better yet not
using country codes and instead using a tiny lookup table (which
IS practical on a 256K 4 MHz PC) would completely prevent undue
anger against amateur radio operators by others in the
networking world. The current problems are caused by AMATEURS
who list their Packet Radio address in NON-PACKET-RADIO-BASED
EMAIL and NEWS postings and the above continent naming practice.

------------------------------

Date: 8 Aug 91 02:08:29 GMT From:
ucselx!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!qt.cs.utexa
s.edu!cs.utexas.edu!helios![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

>***  Well Marc,  we (the bbs authors) await your suggestions.
>***  What is it we should do?  How should we do that? >***
While doing that (whatever it is) keep in mind that we >***
wish to support only a small number of users (about 100,000)
>***  with only a small number of servers (about 10,000), and
that >***  those users will often have *NO* local processing
capability. >***  So post some useful ideas please, since it
sounds like you >***  know what the solutions are.   > >--  >
>Hank Oredson @ Mentor Graphics >Internet     :
[e-mail] >Amateur Radio: [e-mail]

Hank, There have been a couple of suggestions that I have not
seen you say why they should not be implemented, other than that
the small number of hosts running a compatible PBBS might have
to change. (1) Drop/change the continent specifier.  As you are
proud of pointing out, the country codes you use are from an ISO
standard.  But, as you sometimes admit, you picked/made up the
continent codes all on your own.  The new list you just posted
will, I think, cause even more conflicts. (2) Change the
character separator, ".", to something like ";" -- or whatever.
The '#' was added for parsing ease; why not change the period?

As far as "users" and processing power, the end stations
probably don't need any more.  And even a vanilla 512K PC can
store routing entries for ~130 countries.

Last, a minor flame.  There is only one (other) semi-major email
system I'm aware of that mimics (kinda) RFC822 addressing, but
is not the same and  causes much confusion among new users --
the British JANET.  Everyone else (even phone BBS's) uses a
clearly different syntax & that HELPS connectivity and user
education!

Willis Marti n5szf

ps rfc1036 is "in the (e)mail".

------------------------------

Date: 8 Aug 91 02:03:47 GMT From: [e-mail]
Subject: .NA and rapier wit To: [e-mail]

In response to the rapier wit of [e-mail], dated Aug 1,
wherein he slashes me to the quick with such lines as:

> Oh, crap, Dave.

Then he does go on to make some excellent points, and completely
misses others ...

> There *are* people working on the "service element". >
Somewhat slowly, since there's little point to providing
"services" >   on a network that doesn't work.  I can't get very
excited about providing >   21st century services on a network
that is currently firmly planted in >   the late 1960s.
Real-world "wired" networks move orders-of-magnitude >   more
mail/news/files with much higher reliability than the network
you >   hold up as a shining example.  That paradigm *can* be
moved into the >   packet-radio domain, but until we get more
buy-in from die-hard >   NETROM/PBBS/AX.25 addicts, progress is
going to be slow and tedious.

>   Until we "ivory tower types" can get a decent
highspeed/modern network in >   place, there is little point in
providing whizzo services.

My comment re purists/theorists/network purity/service elements
was a  tongue-in-cheek jab at Brian Kantor, which I knew he
would chortle at as he and I have had this discussion before - I
think one can concede that there is a place for theorists,
implementors, and the other fools who try to break everything.

Now Marcus, as to my holding up the packet bbs network "as a
shining example" - what a tight-ass you are ! I never held it up
as anything but another example as to how mail can be moved.

I think what is a little obvious by now is that: 1) there are
folks who do believe that there was no mail service/e-mail
before UNIX and the INTERNET - I refer you to previous messages
- and   this just ain't so, 2) some folks have mistaken RFC's
for STANDARDS - they are not - they are   Requests For Comments
- they may have become de facto "standards", but   they tend to
be limited to the INTERNET, 3) some folks believe that the only
way to do things is the INTERNET way,   and there are obviously
some big-hitters who disagree, or the ISO   would not have any
steam - (N.B. I claim no allegiance, I am just making   a
point), 4) some folks other than you will never do ANYTHING
until everything is   perfect - by then we won't need their
help. 5) some folks on the INTERNET really believe that the BBS
network wants   to push mail thru the INTERNET - this is not
particularly true - if it   works to everyone's mutual benefit,
and it is not a major problem, then   fine - but I doubt we will
instantly rearrange a system that is working,   despite it's
shortcomings.

I'm sure that points 6, etc. could follow, but that expresses
the view-points of a few folks who dropped me personal notes ...
they too are tired of hearing how the only way to do things is
the internet way.

Hey, I like the INTERNET, and I enjoy the services. It is a
wonderful accomplishment, and when I use it, I play by its
rules. But I also want to take my destiny in my own hands and be
part of something new and build a network - we are doing that.
And you are too, with the 56k stuff ... great.

And then the final hurtful slash ---

> It's very sad that an IP address coordinator has such narrow
vision.

I would suggest to you that perhaps it is YOU who have
tunnel-vision -you want to ignore what everyone else is doing,
and like some folks on here, you want to ridicule what you do
not use or do not undertand -- it does you no credit, as I know
you are quite competent.

> Marcus Leech, 4Y11             Bell-Northern Research
|opinions expressed > [e-mail]                  P.O. Box
3511, Stn. C   |are my own, and not > [e-mail]
    Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

Oh, congrats, I see you are employed again.

73, Dave VE3GYQ

ria.ccs.uwo.ca!toth!dave

------------------------------

Date: 7 Aug 91 17:29:25 GMT From:
mcsun!cernvax![e-mail] Subject: DSP Evalulation To:
[e-mail]

      What is this TAPR DSP board, how much does it cost and
where to get it ?

                Pawel Jalocha

            [e-mail]

                (Another guy interested in DSP modems)

------------------------------

Date: 7 Aug 91 15:27:44 GMT From: [e-mail]
Subject: Internet / packet gateway info To: [e-mail]

Are there any FTP-able files on the network somewhere with more
info about using internet <--> packet gateway access?  I have a
friend in Northern Va. who runs packet - it would be really nice
if we could send mail back and forth through such a gateway
until I can set up my own packet station.

Any info would be most appreciated!

'73...

--gary  KB4GCF

------------------------------

Date: 7 Aug 91 23:43:20 GMT From:
ucselx!sol.ctr.columbia.edu!spool.mu.edu!agate!darkstar!sequoia!d
[e-mail] Subject: Using packet radio to connect to work
To: [e-mail]

Hi.  I'd like to use packet radio to connect my workstation at
home to my workstation at the University.

I'd appreciate any pointers as to:

* What sort of license do I need (new code-free sounds nice)?

* How much does the equipment cost?

* How far can I go (I am moving about 17 miles and over a hill
from the campus)?

* Is there an existing TCP/IP implementation for packet radio
that will run on  my Sun?

* What's the first thing I should do to get started?

Many thanks, DL

------------------------------

Date: (null) From: (null) Why is it that you believe that
`bbsnet' should use an address syntax that works with internet?
I don't expect to be able to send a message to someone by using
their telephone number as the address. If I wanted to connect my
BBS in to another network, I'd expect to have to resolve any
addressing problems at the gateway. I wouldn't have thought it
would be too difficult for the bbsnet<->internet gateways to
understand the differences between the two networks and make
address changes as necessary.

>>3. There is no chance that the bbsnet will change it's address
grammar. >  > Thanks for your cooperation.  That's what makes
Amateur Radio great. > You're the one primarily responsible for
relegating amateur radio protocols > to the lowest possible
levels that a 512K PC-XT can support -- and be > damned with the
rest of the world.  Amateur radio does not stand alone, and >
you can not pretend that the decisions you make (e.g. re:
geographic > routing) are irrelevant to the outside world,
because users "should know" > the difference.

Here you use an important word - `amateur'. By far the majority
of people using packet radio ARE using cheap computers, often
far more basic than a 512K PC-XT. There are many reasons for
this, not least amongst them is that the equipment is cheap
(often all that they can afford). If we were to start dropping
AX-25 then we would be depriving a lot of people of a lot of
pleasure.

We owe a lot to Hank, and others like him, who have put a lot of
effort into coming up with an AMATEUR RADIO system that works.
Yes, with hindsight, a lot of things could have been done
better, but then again that could be said about everything.

Brian G1NNA

------------------------------

Date: 7 Aug 91 00:58:54 GMT From:
stanford.edu!neon.Stanford.EDU![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: 'NA' country
domain appears to be non-unique

[e-mail] (Hank Oredson) writes:

>1. Think you miss the point.

Actually, Hank, it is YOU who miss the point.  The problem is
NOT the gateway function, it is that bbsnet has deliberately
adopted an address syntax that will often "work" on internet,
albeit incorrectly.  This, coupled with naive users, can and
does lead to mail sent to, e.g. Namibia. Now, no one would give
a hoot about this except that it is costing the Namibians real
$$ money to receive and bounce (or ignore the mail).

>3. There is no chance that the bbsnet will change it's address
grammar.

Thanks for your cooperation.  That's what makes Amateur Radio
great. You're the one primarily responsible for relegating
amateur radio protocols to the lowest possible levels that a
512K PC-XT can support -- and be damned with the rest of the
world.  Amateur radio does not stand alone, and you can not
pretend that the decisions you make (e.g. re: geographic
routing) are irrelevant to the outside world, because users
"should know" the difference.

>So we have this problem ... users mostly don't understand much
of the >above.  My suggestion is the same as yours: education.
No matter >what we do with the software, users will make
mistakes.  I'm trying to >get more involved here on usenet
because I'll probably write more software ...

Well, just what are YOU going to do about educating YOUR users
to not use bbsnet addresses on Internet?

Marc Kaufman ([e-mail])

------------------------------

Date: 7 Aug 91 14:34:52 GMT From:
usc!cs.utexas.edu!helios!cs.tamu.edu![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: 'NA'
country domain appears to be non-unique

In article <[e-mail]>,
[e-mail] (Marc T. Kaufman) writes: |>
[e-mail] (Hank Oredson) writes: |>  |> >3. There is
no chance that the bbsnet will change it's address grammar. |>
|> Thanks for your cooperation.  That's what makes Amateur Radio
great. |> You're the one primarily responsible for relegating
amateur radio protocols |> to the lowest possible levels that a
512K PC-XT can support -- and be |> damned with the rest of the
world.  Amateur radio does not stand alone, and |> you can not
pretend that the decisions you make (e.g. re: geographic |>
routing) are irrelevant to the outside world, because users
"should know" |> the difference.

[Soapbox mode ON ]

  OK, by the same token, all other mail systems in the world, if
they want to gateway into the Internet, must change their
addressing scheme to match the Internet??  N.F.W.!!!!  As a
W0RLI BBS op for many years,  I can say that  traffic went very
well all over the globe, thank you, WITHOUT the "benefit" of the
Internet.  Hank did a damn fine job with his stuff.  It worked.
 To change the whole BBSnet to a "compatible" addressing scheme
would mean  that all of the BBSes, simultaneously, would have to
change to the new code. Get real!  It'll never happen.  And, why
should it?     What is needed is gateways that are intelligent
enough to do the address translation properly.  I suspect that
the reason the Nambians are getting  mail wrongly is NOT because
the BBSnet addressing scheme is "wrong", but  because some
gateway somewhere screwed up.

  Remember, most of the code in human-interactive programs deals
with error conditions.  Those poor bits of silicon are trying to
cope with us humans.

[Soapbox mode OFF ]

|>  |> >So we have this problem ... users mostly don't
understand much of the |> >above.  My suggestion is the same as
yours: education.  No matter |> >what we do with the software,
users will make mistakes.  I'm trying to |> >get more involved
here on usenet because I'll probably write more software ... |>
|> Well, just what are YOU going to do about educating YOUR
users to not use |> bbsnet addresses on Internet? |>  |> Marc
Kaufman ([e-mail])

  Make the gateways robust enough to tell the difference and the
problem will  dissolve.   At the least, they should err on the
safe side if they are not sure of the translation.  At the very
least, users should be able to do
[e-mail]....

  As to what Hank is doing:  He said he's getting more involved
, isn't he? Give the man a chance!  Illegitimi noncarborundum,
Hank!

--  Kurt Freiberger, wb5bbw      [e-mail]   409/847-8607
fax:[phone] Dept. of Computer Science, Texas A&M University
     DoD #264: BMW R80/7 pilot "We preserve our freedom using
three boxes: ballot, jury, and cartridge."      *** Not an
official document of Texas A&M University ***

------------------------------

Date: 7 Aug 91 18:00:54 GMT From:
usc!cs.utexas.edu!helios!cs.tamu.edu![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: 'NA'
country domain appears to be non-unique

  I was under the impression that the offending BBSNet addresses
got to the Internet via a brain-damaged gateway.  It seems that
this is not so.  If  the messages were sent by someone on the
Internet that didn't know better, the  BBSNet isn't at fault.
It's a learning process that will take time and unfortunately
money.  Sorry, Nambia, but you knew the job was dangerous when
you took it.--  Kurt Freiberger, wb5bbw      [e-mail]
409/847-8607  fax:[phone] Dept. of Computer Science, Texas
A&M University      DoD #264: BMW R80/7 pilot "We preserve our
freedom using three boxes: ballot, jury, and cartridge."
*** Not an official document of Texas A&M University ***

------------------------------

Date: 8 Aug 91 01:48:53 GMT From:
pa.dec.com!jrdzzz.jrd.dec.com![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail]> Reply-To :
[e-mail] Subject : Don't mix hostname with routings.

In article <[e-mail]>, [e-mail] (Brian Kantor)
writes: ]Please don't use ]    na.ampr.org ]nor ]    noam.ampr.org ]
]They are an abomination and should not be tolerated.  Don't mix
routing ]with hostnames!

100% agreed. The structure of domain naming system is totally
independent from physical topology. A domain can contain
multiple networks. (For example, in DEC, there are at least two
IP networks for external connection, and a huge internal DECnet
world, all named under the same domain "dec.com".).

-- Kenji

------------------------------

Date: 7 Aug 91 16:32:06 GMT From:
stanford.edu!neon.Stanford.EDU![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: 'NA' country domain
appears to be non-unique

First, let me apologize for the strident tone of my last
posting.  I really have nothing personal against Hank, and I am
even one to appreciate all he has done for the amateur BBS
community.

However, there are some folks out there who just do not
understand the issue. for example:

[e-mail] (Kurt Freiberger) writes:

>  OK, by the same token, all other mail systems in the world,
if they want to >gateway into the Internet, must change their
addressing scheme to match the >Internet??  N.F.W.!!!!  As a
W0RLI BBS op for many years,  I can say that  >traffic went very
well all over the globe, thank you, WITHOUT the "benefit" >of
the Internet.  Hank did a damn fine job with his stuff.  It
worked.   >To change the whole BBSnet to a "compatible"
addressing scheme would mean  >that all of the BBSes,
simultaneously, would have to change to the new code. >Get real!
 It'll never happen.  And, why should it?

I *DID NOT SAY* that the BBS adressing scheme should be
compatible with Internet.  In fact, what I *DID* say was that
the BBS addressing scheme should *NOT* be compatible with the
internet -- in the sense that a BBS address, if inadvertently
used to address a piece of mail on the Internet (by a confused
or naive user) should *NOT* accidently route to places like
Namibia, that cost real money to unsuspecting end users (in
Namibia) who have no desire to play amateur radio games.

Once again: this is *NOT* a gateway issue.  Gateways can do
(almost) anything. This is a *USER CONFUSION* issue, where a
user uses the wrong address for the network he is on.  It is
akin to the UK folks writing their addresses backwards.  No one
cares, in general, if a few pieces of mail get bounced. However,
this confusion is costing real people real money.

The BBS folks deliberately ignored the pleas of the Internet
folk to adopt a different address syntax when geographic
"routing hints" were first adopted.  Because of this, I think
the BBS folks have the primary responsibility to alleviate the
confusion.  If you don't, even the gateways will be denied to
you (cf: the Japanese FWD-NET).

Marc Kaufman ([e-mail])

------------------------------

End of Packet-Radio Digest V91 #200
****************************** Date: Fri,  9 Aug 91 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #201 To: packet-radio

Packet-Radio Digest         Fri,  9 Aug 91       Volume 91 :
Issue 201

Today's Topics:                            Administrivia
'NA' country domain appears to be non-unique (4 msgs)
              .NA and rapier wit                .NA and rapier
wit (longish) (2 msgs)                     Internet to Packet
Gateways?                     KA9Q and Turbo C++ (2 msgs)
             KA9Q copyright and question.

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: Thu, 8 Aug 91 09:58:57 -0700 From: brian (Brian Kantor)
Subject: Administrivia To: packet-radio-digest

The digest has gotten so popular that I've had to go to
size-based distribution.  That means that instead of one digest
being issued each day at 4 am, they'll be sent whenever the
accumulated digest size reaches 32K (before header stripping, so
the actual size is probably like 28K or so by the time it hits
your mailbox).

I hope this doesn't inconvenience anyone.

- Brian

------------------------------

Date: 8 Aug 91 09:25:15 GMT From:
mcsun!news.funet.fi!ousrvr.oulu.fi![e-mail] Subject:
'NA' country domain appears to be non-unique To:
[e-mail]

In article <[e-mail]> [e-mail] (Kurt
Freiberger) writes:

> gateway into the Internet, must change their addressing scheme
to match the > Internet??  N.F.W.!!!!  As a W0RLI BBS op for
many years,  I can say

Who said we should?

> To change the whole BBSnet to a "compatible" addressing scheme
would mean  > that all of the BBSes, simultaneously, would have
to change to the

It would not - were we going to switch to "compatible",
"incompatible", "impossible" or "impractical" addressing scheme,
doesn't make much of a difference. Have you ever heard of System
ID handshaking between BBS programs?

> Get real!  It'll never happen.  And, why should it?

Well, actually, why not? Even though I think this argument is
rather silly (and about silly users, not gateways), it wouldn't
require much patching to the existing software.  There are new
versions coming up all the time anyway.

A colon (:) as a routing separator would be fine. But, o' the
mighty BBS programmers, pleeeease do NOT get too inventive about
that. Leave out | and \ and other peculiarities that look a
whole lot different in here...

    Luru

    ///

o-o    Ham Radio Operators Do It In Higher Frequency

 o

------------------------------

Date: 8 Aug 91 12:22:52 GMT From:
sun-barr!lll-winken!iggy.GW.Vitalink.COM!widener!netnews.upenn.ed
u!uofs!vulture.cs.uofs.edu![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

In article <[e-mail]>, [e-mail] (Willis
Marti) writes: |> > |> (1) Drop/change the continent specifier.
As you are proud of pointing out, |> the country codes you use
are from an ISO standard.  But, as you sometimes |> admit, you
picked/made up the continent codes all on your own.  The new |>
list you just posted will, I think, cause even more conflicts.
|> (2) Change the character separator, ".", to something like
";" -- or |> whatever.  The '#' was added for parsing ease; why
not change the period? |>

Actually, (1) is all that is necessary.  This is not a routing
problem. It has nothing to do with gateways between PACKET <->
INTERNET.  It is simply a problem of having non-unique top level
domain.  Unless I am unusually blind this morning, it appears to
me that merely changing the 2 letter continent designators to
some 4 letter code would solve the whole problem AND make
routing/gatewaying easier by making the last part of the domain
easier to differentiate.

Carrying it one step further, you could even apply to ISO for
official recognition of the 4 letter continent designators you
choose.  Thus making it official.

bill   KB3YV--

     Bill Gunshannon          |        If this statement wasn't
here,     [e-mail]   |  This space would be left
intentionally blank     [e-mail]    |
#include <std.disclaimer.h>

------------------------------

Date: 8 Aug 91 15:00:39 GMT From:
mcsun!ukc!axion!kitkat![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

------------------------------

Date: 8 Aug 91 18:20:49 GMT From: telebit![e-mail]
Subject: 'NA' country domain appears to be non-unique To:
[e-mail]

For those of you out there who know me, there appears to be
another Brian Lloyd who is a ham and is participating in the
discussion. Please be sure you know who is who.  Please note
that I have my callsign as part of my signature.

--  Brian Lloyd, WB6RQN         Telebit Corporation        The
views expressed Network Systems Architect   1315 Chesapeake
Terrace    herein are my own and [e-mail]
Sunnyvale, CA 94089-1100   are not necessarily voice (408)
745-3103        FAX [phone]         my employer's.

------------------------------

Date: 8 Aug 91 13:37:33 GMT From:
swrinde!cs.utexas.edu!helios!cs.tamu.edu![e-mail]
Subject: .NA and rapier wit To: [e-mail]

In article <[e-mail]>, [e-mail] (David
B. Toth) writes: [much stuff directed to Marcus deleted] |> Now
Marcus, as to my holding up the packet bbs network "as a shining
|> example" - what a tight-ass you are ! I never held it up as
anything but |> another example as to how mail can be moved. |>
|> I think what is a little obvious by now is that:
       ^^^^^^^^^^^^^^ very little, and not so obvious...

|> 1) there are folks who do believe that there was no mail
service/e-mail |>    before UNIX and the INTERNET - I refer you
to previous messages - and |>    this just ain't so,

Ok, what are examples of intersystem and/or internetwork
electronic mail that predate those?

|> 2) some folks have mistaken RFC's for STANDARDS - they are
not - they are |>    Requests For Comments - they may have
become de facto "standards", but |>    they tend to be limited
to the INTERNET,

This is essentially completely wrong.  When the US (and some
non-US countries) specifies the RFCs in procurements, and many
major corporations plan or build to them, they're standards.  If
you don't know what the abbreviations IAB and IETF mean & their
relationship, they you don't understand the process enough to
make an intelligent comment.

|> 3) some folks believe that the only way to do things is the
INTERNET way, |>    and there are obviously some big-hitters who
disagree, or the ISO |>    would not have any steam - (N.B. I
claim no allegiance, I am just making |>    a point),

You're 1/2 right -- there are *lots* of ways (some even "good")
besides the methods given in the RFCs.  But the ISO protocols
are there as "the next step" in networking.  Some ISO protocols
are built to work with the TCP/IP suite. And many "Internet"
folk are integrating ISO ideas into Internet standards, instead
of claiming that the existing methods are "the best" and
resisting  change (like some here).

|> 4) some folks other than you will never do ANYTHING until
everything is |>    perfect - by then we won't need their help.
|> 5) some folks on the INTERNET really believe that the BBS
network wants |>    to push mail thru the INTERNET - this is not
particularly true - if it |>    works to everyone's mutual
benefit, and it is not a major problem, then |>    fine - but I
doubt we will instantly rearrange a system that is working, |>
 despite it's shortcomings.

The issue is not "instant" rearrangement. The issue is whether
BBS folk are interested in moving at all.

|>  |> I'm sure that points 6, etc. could follow, but that
expresses the view-points |> of a few folks who dropped me
personal notes ... they too are tired of hearing |> how the only
way to do things is the internet way.

And I'm tired of hearing that the current mail system is the
only way to work in amateur radio BBS mail.  The Internet
standards are not the only way to do things, but they have
connected more systems of more different types in actual working
environments than any other protocol suite.  And they deserve to
be considered, not rejected out-of-hand.

|>  |> Hey, I like the INTERNET, and I enjoy the services. It is
a wonderful |> accomplishment, and when I use it, I play by its
rules. But I also want to |> take my destiny in my own hands and
be part of something new and build a |> network - we are doing
that. And you are too, with the 56k stuff ... great. |>  |> And
then the final hurtful slash --|>  |> > It's very sad that an IP
address coordinator has such narrow vision. |>  |> I would
suggest to you that perhaps it is YOU who have tunnel-vision -|>
you want to ignore what everyone else is doing, and like some
folks on |> here, you want to ridicule what you do not use or do
not undertand

Though these comments were directed to Marcus, let me say that I
use the PBBS mail system, think I understand many salient points
-- and still think  the "tunnel vision" is exhibited by those
who go off on their own & ignore existing work.  No one has
ridiculed the W0RLI BBS code -- they've made comments that maybe
it should be changed.

Willis n5szf

------------------------------

Date: 8 Aug 91 14:22:20 GMT From:
swrinde!cs.utexas.edu!utgpu!nrcnet0!bnrgate!bwdls61!bnr.ca!mleech
@ucsd.edu Subject: .NA and rapier wit (longish) To:
[e-mail]

In article <[e-mail]>, [e-mail] (David
B. Toth) writes: |> 1) there are folks who do believe that there
was no mail service/e-mail |>    before UNIX and the INTERNET -
I refer you to previous messages - and |>    this just ain't so,
I'm certainly not one who believes that the INTERNET/UNIX are
the only  mail systems in existence.  The INTERNET has, however,
been around for  longer than the packet radio PBBS network.  If
you really knew me, you would  know that I've designed network
mail systems for non-homogeneous systems  that are distinctly
un-UNIX like.  I have no sentimental attachment to either the
INTERNET or UNIX.  I think they offer some powerful paradigms
that others   (e.g. the amateur packet radio community) have
been reluctant to accept  --simply because they want to do
something "different" and not necessarily  better. |> 2) some
folks have mistaken RFC's for STANDARDS - they are not - they
are |>    Requests For Comments - they may have become de facto
"standards", but |>    they tend to be limited to the INTERNET,
So to you, then, the only "real" standards are those that are
decided upon by  unwieldy committees of stuffed-shirt
politicians in Geneva? De facto  standards are a way of life in
the computing business.  Lots and lots  of really useful things
get done this way.  In fact, the only difference  between most
de facto standards and "real" ones, is that for "real" ones  you
have to pay ISO a lot of money to get a *paper* copy of the
standard.  A standard is, after all, simply a formal statement
of a technique or  procedure that a large number of people can
agree upon and use.  I'd say  that pretty much describes the RFC
process... |> 3) some folks believe that the only way to do
things is the INTERNET way, |>    and there are obviously some
big-hitters who disagree, or the ISO |>    would not have any
steam - (N.B. I claim no allegiance, I am just making |>    a
point), The ISO is an important organization.  It also
consistently makes mistakes.  It bothers me that they believe
that they are inventing something  something brand-new with OSI.
They have a long history of ignoring  "prior art" and inventing
something that is in large part inferior to its  predecessors.
|> 5) some folks on the INTERNET really believe that the BBS
network wants |>    to push mail thru the INTERNET - this is not
particularly true - if it |>    works to everyone's mutual
benefit, and it is not a major problem, then |>    fine - but I
doubt we will instantly rearrange a system that is working, |>
 despite it's shortcomings. |>  Some folks believe that until
INTERNET applications prompt with:

  VE3XXX:  A,B,C,D,E,F,G,H,I,J,K,L,N,R,S,T,U,V,W,Z,? > ,

there is no hope that they will be accepted by the amateur
community.

If that *is* true (which I don't believe) then I had better pack
up my toys  and go play somewhere else. |> |> take my destiny in
my own hands and be part of something new and build a |> network
- we are doing that. If you think that the PBBS network is
something new and wonderful, I think that  perhaps the sixties
were a bit too good to you ;-)  I think that the INTERNET  has a
very rich application set that we can use to good advantage on a
 totally-revamped amateur-packet-radio network.  It offers a
number of  appealing paradigms that can be made to work on the
(as yet non-existent)  high-speed amateur-packet-radio network
of the (near, I hope) future. |>  |> ... you want to ridicule
what you do not use or do not undertand -- it |> does you no
credit, as I know you are quite competent. Where, exactly, do
you get the notion that I don't use the PBBS network? I use it
frequently, which is why I want to replace it with something
better. I also understand its motivations, and many of the
decisions that were made  in its design.  See some of my initial
comments with regard to network-mail  system design... |> |> Oh,
congrats, I see you are employed again. |>  Uhhmmm. I'm not
exactly sure how to interpret that remark. I'll assume  you're
being pleasant and say thanks.  I'll also point out that it's
old (18 months) news.

--  Marcus Leech, 4Y11             Bell-Northern Research
|opinions expressed [e-mail]                  P.O. Box
3511, Stn. C   |are my own, and not [e-mail]
  Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

------------------------------

Date: 8 Aug 91 18:39:33 GMT From: telebit![e-mail]
Subject: .NA and rapier wit (longish) To: [e-mail]

Interesting thread.  Most interesting to see the same arguments
that have been going on for the better part of a decade (yes,
decade) with still no resolution.

I think that Phil Karn made a significant point back when there
were two camps arguing about X.25/ISO vs. IP.  Phil went off and
wrote his KA9Q package and a number of us played with it.
Gordon Beattie (sorry if I have misspelled your name Gordon) was
the driving force behind ROSE so it got done and people are
using it now.  The key here is DOING not ARGUING.

Now as for which is best?  I personally believe that the
amateurs have managed to mangle most of it (IP, BBS, NetROM,
ROSE, etc.).  It is amazing that any of it works so I would not
be holding ANY of it up as being "the way to do things."

So, don't argue; prove your point.  Implement something,
instrument it, and then document the results.  This eliminates
the arguments and is far more productive.

In the mean time I will go back to constructing fast, flexible,
inexpensive networks that move mail, files, and terminal QSOs --
using the telephone system.  With luck the FCC will allocate
spectrum for building commercial high-speed, reliable packet
radio networks and I can then include packet radio as part of my
network.

--  Brian Lloyd, WB6RQN         Telebit Corporation        The
views expressed Network Systems Architect   1315 Chesapeake
Terrace    herein are my own and [e-mail]
Sunnyvale, CA 94089-1100   are not necessarily voice (408)
745-3103        FAX [phone]         my employer's.

------------------------------

Date: 7 Aug 91 18:33:31 GMT From:
hpcc05!hpcuhb!hpindwa![e-mail] Subject: Internet
to Packet Gateways? To: [e-mail]

We'll this has got to be a frequently asked question, but....

What are some of the gateways to send e-mail from the internet
to the packet network?

Thanks for any responces!

Bob Joslin

[e-mail]

------------------------------

Date: 8 Aug 91 04:30:53 GMT From:
fernwood!portal!cup.portal.com![e-mail] Subject:
KA9Q and Turbo C++ To: [e-mail]

I have been trying to compile KA9Q with Turbo C++ (2.0) and the
executable seems to be larger than the one that is compiled with
Turbo C, not only that it doesn't work!   Does anyone know if
there is a patch for KA9Q for Turbo  C++....and how do I contact
Phil Karn?  Thanks, John

------------------------------

Date: 8 Aug 91 13:40:51 GMT From:
usc!cs.utexas.edu!helios!cs.tamu.edu![e-mail] Subject:
KA9Q and Turbo C++ To: [e-mail]

In article <[e-mail]>, [e-mail]
writes: |> I have been trying to compile KA9Q with Turbo C++
(2.0) and the executable |> seems to be larger than the one that
is compiled with Turbo C, not only that |> it doesn't work!
Does anyone know if there is a patch for KA9Q for Turbo  |>
C++....and how do I contact Phil Karn? |>   |> Thanks, |> John

Can't answer why it doesn't work -- I've done it with TC 2.0 &
TC++ 1.0. But a *major* part of the size difference is that Phil
runs PKLITE on the executable (which reduces it about in half).
If you have Internet access, you can ftp it from
wsmr.simtel20.army.mil (or a couple of other places).  Or check
your local phone BBS.

Willis n5szf

------------------------------

Date: 8 Aug 91 04:37:37 GMT From:
fernwood!portal!cup.portal.com![e-mail] Subject:
KA9Q copyright and question. To: [e-mail]

I'm planning to port KA9Q from PC-DOS to a multiuser OS.  My
questions is  what type of copyright will I be violate if I
modify the program? (estimate percent of change is around 40% to
60%).  I am interest in getting a  respond from the author and
anyone else on this subject.  John

------------------------------

Date: 8 Aug 91 15:57:39 GMT From:
mvb.saic.com!unogate!orion.oac.uci.edu!usc!elroy.jpl.nasa.gov!swr
inde!cs.utexas.edu!oakhill!nddsun1![e-mail] To:
[e-mail]

References <[e-mail]>, <[e-mail]>,
<[e-mail]>xas.e Subject : Re: Don't mix
hostname with routings.

In article <[e-mail]>
[e-mail] writes: }In article <[e-mail]>,
[e-mail] (Brian Kantor) writes: }]Please don't use
}]    na.ampr.org }]nor }]    noam.ampr.org }] }]They are an
abomination and should not be tolerated.  Don't mix routing
}]with hostnames! }100% agreed. The structure of domain naming
system is totally independent from }physical topology. A domain
can contain multiple networks. (For example, in }DEC, there are
at least two IP networks for external connection, and a huge
}internal DECnet world, all named under the same domain
"dec.com".).

I agree with your point, but then how SHOULD I send mail which
originates here ([e-mail]) to my amateur radio
packet address - [e-mail] - ?

It seems that we must first all agree on some scheme that works
both ways before anyone can even dream of implementing it in a
BBS!

--            *Mike Waters    AA4MW/7
[e-mail] * The one good thing about repeating
your mistakes is that you know when to cringe.

------------------------------

Date: 8 Aug 91 15:52:31 GMT From:
usc!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!oakhill!nddsun1!wate
[e-mail] To: [e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail]> Subject
: Re: 'NA' country domain appears to be non-unique

Hi, I am newly returned to packet radio so the
routing/addressing problems are new to me. I have, however,
spent 7 years working on standards definitions (EDIF, VHDL and a
couple of others) so I feel I have some insight to add here.

In article <[e-mail]>
[e-mail] (Bill Gunshannon) writes: }In article
<[e-mail]>, [e-mail] (Willis Marti)
writes: }|> (1) Drop/change the continent specifier.  As you are
proud of pointing out, }|> the country codes you use are from an
ISO standard.  But, as you sometimes }|> admit, you picked/made
up the continent codes all on your own.  The new }|> list you
just posted will, I think, cause even more conflicts. }|> (2)
Change the character separator, ".", to something like ";" -- or
}|> whatever.  The '#' was added for parsing ease; why not
change the period? }Actually, (1) is all that is necessary.
This is not a routing problem. It has }nothing to do with
gateways between PACKET <-> INTERNET.  It is simply }a problem
of having non-unique top level domain.  Unless I am unusually
}blind this morning, it appears to me that merely changing the 2
letter continent }designators to some 4 letter code would solve
the whole problem AND make }routing/gatewaying easier by making
the last part of the domain easier to }differentiate.

I urge EXTREME caution in making ANY changes here! It is simply
amazing the ramifications of seemingly simple changes in a
widely used format!

You are quite correct in using the ISO/ANSI standards wherever
they exist, not because they are standards or "approved", but
because the process of approval applies enough tests and trial
to weed out the traps. "Rolling your own" in something like this
is a sure way to disaster, even professional standards makers go
through an incredibly extensive review process to weed out the
"gotchas". Often very subtle ones like the zip code/district
conflict that has been pointed out already.

It seems to me that it is very desirable to minimize the
translation required to go from one network to another as much
as possible. Not just to reduce the size of the code required,
but to minimize the chance for screwups like the "NA" designator.

The advantage of the "Internet" addressing scheme is that it has
been tried and tested for many years in many many situations and
has been shown to work well. As a result it is VERY difficult to
get people to agree to change it. It would seem reasonable to
emulate that scheme as much as possible in the amateur network.

Ok how about some specifics.

First, I agree with the sentiment that questions the need for
the continent identifier. It is reasonable to assume that the
volume of traffic will correspond to the amateur population in
an area. Therefor one would expect the traffic volume to be
ordered something like this:

1) One's own country - "national" traffic 2) Japan 3) USA 4) UK
5) Germany 6) Canada 7) Australia

I am taking guesses at the relative populations here, but my
point is that the traffic volume is HEAVILY ordered by country
making a low overhead lookup very simple. I would suspect that
for any one station the first 5 entries would handle 99% of the
traffic and very likely handle everything that COULD be handled
by that particular station.

The 130/250 country list would only have to be used in very rare
situations. It is not unreasonable to expect some special
handling for a message to say Pitcairn Island.

All in all it would seem to be an extension of the problem
within the U.S. in which 50 state designators must be searched
with radically different routings for each state. I suspect that
even a European routing for Hawaii and Maine would be different.

Any comments? Am I simply stating the obvious or am I all wet?

}Carrying it one step further, you could even apply to ISO for
official recognition }of the 4 letter continent designators you
choose.  Thus making it official.

If you/we come up with a truly FOOLPROOF scheme then this will
likely happen very easily. The hard part is to find a foolproof
scheme.

--            *Mike Waters    AA4MW/7
[e-mail] * The one good thing about repeating
your mistakes is that you know when to cringe.

------------------------------

Date: (null) From: (null) $ -- Supports BIDs and F> A --
Authentication (Proposed by AA4RE -- No definition yet) B --
Compression (FBB) C -- Remote clock set (W0RLI) F -- Bulk mail
forwarding (FBB) H -- Hierarchical addressing M -- MID support P
-- Compression (G1NNA) R -- Reverse reverse forward (G1NNA &
G4YFB) R -- Improved response to BID S -- Improved send
(Proposed by AA4RE -- no definition yet) T -- Improved telephone
support (Proposed by AA4RE -- no definition yet) W -- WP Server
(Obsolete??)

Brian

Brian Lloyd Maintenance Section,             # e-mail :
[e-mail] Software Technology Division,        # Phone  :
[phone] SSTF Building, BTRL, Martlesham Heath,     # Fax
  : [phone] Ipswich, Suffolk. UK. IP5 7RE        # Packet :
G1NNA@GB7NNA.#31.GBR.EU

------------------------------

Date: 8 Aug 91 19:11:02 GMT From: timbuk![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: 'NA' country
domain appears to be non-unique

In article <[e-mail]>,
[e-mail] (Brian Lloyd) writes: > For those of you out
there who know me, there appears to be another > Brian Lloyd who
is a ham and is participating in the discussion. > Please be
sure you know who is who.  Please note that I have my > callsign
as part of my signature. >  >  > --  > Brian Lloyd, WB6RQN
  Telebit Corporation        The views expressed > Network
Systems Architect   1315 Chesapeake Terrace    herein are my own
and > [e-mail]           Sunnyvale, CA 94089-1100   are
not necessarily > voice [phone]        FAX [phone]
        my employer's.

Or maybe we could refer to you as #Brian Lloyd ?

:-) :-)

-andyw.    (W0/G1XRL)

[e-mail]    Andy Warner, Cray Research, Inc.    (612)
683-5835

------------------------------

Date: 8 Aug 91 15:48:12 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net To: [e-mail]

References <[e-mail]>,
<[e-mail]>, <20010@hel Subject :
Re: 'NA' country domain appears to be non-unique

In <[e-mail]> [e-mail] (Kurt
Freiberger) writes:

>  I was under the impression that the offending BBSNet
addresses got to the >Internet via a brain-damaged gateway.  It
seems that this is not so.  If  >the messages were sent by
someone on the Internet that didn't know better, the  >BBSNet
isn't at fault.  It's a learning process that will take time and
>unfortunately money.  Sorry, Nambia, but you knew the job was
dangerous >when you took it.

Very useful attitude! Does the FCC think so too?

Of course the BBSnet is at fault. You people were told that this
braindamaged adressing scheme was going to cause problems and
you people adopted basically the same attitude (`We don't care').

 regards, el--

Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

Date: 8 Aug 91 15:38:32 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net To: [e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: 'NA' country domain
appears to be non-unique

In <[e-mail]> [e-mail] (Kurt
Freiberger) writes:

>In article <[e-mail]>,
[e-mail] (Marc T. Kaufman) writes: >|>
[e-mail] (Hank Oredson) writes: >|>  >    >  What
is needed is gateways that are intelligent enough to do the
address >translation properly.  I suspect that the reason the
Nambians are getting  >mail wrongly is NOT because the BBSnet
addressing scheme is "wrong", but  >because some gateway
somewhere screwed up.

No this is not at all the case. It happens only because someone
put something like xxx.xxx.USA.NA into his signature and someone
else uses this to answer him. It has nothing at all to do with
any gateways (which may not even exist).

regards, el--

Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

Date: 8 Aug 91 15:41:52 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net To: [e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: 'NA'
country domain appears to be non-unique

In <[e-mail]>
[e-mail] (Marc T. Kaufman) writes:

>should *NOT* be compatible with the internet -- in the sense
that a BBS >address, if inadvertently used to address a piece of
mail on the Internet >(by a confused or naive user) should *NOT*
accidently route to places like >Namibia, that cost real money
to unsuspecting end users (in Namibia) who >have no desire to
play amateur radio games.

>Once again: this is *NOT* a gateway issue.  Gateways can do
(almost) anything. >This is a *USER CONFUSION* issue, where a
user uses the wrong address for >the network he is on.  It is
akin to the UK folks writing their addresses >backwards.  No one
cares, in general, if a few pieces of mail get bounced.
>However, this confusion is costing real people real money.

Matter of fact there are two hosts around there that should be
adressed as follows na.oxford.ac.UK, na.rl.ac.UK. Guess what
happens if somone forgets that they drive on the wrong side of
the road :-)-O? Again NAmibia pays :-)-O. (It is however sorted
out already)

regards, el--

Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

Date: 8 Aug 91 23:39:03 GMT From:
pa.dec.com!jrdzzz.jrd.dec.com![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]>se Reply-To : [e-mail]
Subject : Re: Don't mix hostname with routings.

In article <[e-mail]>,
[e-mail] (Mike Waters) writes: ]In article
<[e-mail]> [e-mail] writes:
]}100% agreed. The structure of domain naming system is totally
independent from ]}physical topology. A domain can contain
multiple networks. (For example, in ]}DEC, there are at least
two IP networks for external connection, and a huge ]}internal
DECnet world, all named under the same domain "dec.com".).

In fact, Digital DECnet user who has HOST::USERNAME form of
DECnet Phase IV address, can be addressed from Internet as
[e-mail]. (Please refer to
gatekeeper.dec.com:~ftp/gateway.doc for details) I thought this
sort of scheme could be applied on RLI/MSYS, such as
[e-mail].

]I agree with your point, but then how SHOULD I send mail which
]originates here ([e-mail]) to my amateur radio
packet ]address - [e-mail] - ?

I think you can't map two different naming systems on a same
naming space. You should compromise to add some "fake"
identifiers.

I have suggested here on rec.radio.amateur.packet to make a
"fake" domain for Internet addressing.  (Such as ".fwdnet" or
".pbbs.ampr.org" (Maybe Brian Cantor will say something
different, but I foresee no problems on mapping RLI/MSYS naming
scheme into ampr.org as a fake subdomain.)) I think the same
kind of thing can be applied on the RLI/MSYS side.

]It seems that we must first all agree on some scheme that works
both ]ways before anyone can even dream of implementing it in a
BBS!

Exactly.

]           *Mike Waters    AA4MW/7  [e-mail] *

-- Kenji, JJ1BDX, [e-mail]

------------------------------

End of Packet-Radio Digest V91 #201
****************************** Date: Sat, 10 Aug 91 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #202 To: packet-radio

Packet-Radio Digest         Sat, 10 Aug 91       Volume 91 :
Issue 202

Today's Topics:        'NA' country domain appears to be
non-unique (2 msgs)                   .NA and comment to Brian
Kantor                   AA4RE BBS test version available
               FTP sites for KA9Q code?
       help                Help with ka9q and mbuf data
structure                        Status reports on pmp?
          The great .NA controversy....                     What
RFCs are (one version)

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 9 Aug 91 01:03:26 GMT From:
cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!emory!wa4mei!
ke4zv![e-mail] Subject: 'NA' country domain
appears to be non-unique To: [e-mail]

In article <[e-mail]>
[e-mail] writes: > >***  Well Marc,  we (the bbs
authors) await your suggestions. >***  What is it we should do?
How should we do that? >***  While doing that (whatever it is)
keep in mind that we >***  wish to support only a small number
of users (about 100,000) >***  with only a small number of
servers (about 10,000), and that >***  those users will often
have *NO* local processing capability. >***  So post some useful
ideas please, since it sounds like you >***  know what the
solutions are.

I would suggest the obvious solution is scanning routing hints
right  to left. Posting software should always require a full
hierarchial  address. It may supply default continent and
country, even state and  local, designators if none are supplied
by the user. Then by scanning  right to left all ambiguities
caused by local names are resolved properly  at the appropriate
local level. Your forwarding software should certainly have a
forwarding solution for continental designators that it can fall
back on if a forwarding solution fails for countries. Similarly,
if a country solution is found, it can be fallen back on if a
state solution is missing. And so on down to local LAN names.
There is  never any uncertainty because *every* address would
start with the same top level field as it's rightmost element
and the software scans until it can resolve no further. There
should never be confusion between  a country code and a
continent code, or some very localized code as  scanning
descends the routing hierarchy. The only precaution needed to
prevent problems with other networks is to avoid using
conflicting top  level names. In the case of the BBSNET, there
are only seven to worry about. The major fault of current BBS
software, as I see it, is that it doesn't respect it's own self
imposed hierarchial nature, because it scans in the wrong
direction.

Gary KE4ZV

------------------------------

Date: 9 Aug 91 09:21:23 GMT From:
cis.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pi
tt!w2xo![e-mail] Subject: 'NA' country domain
appears to be non-unique To: [e-mail]

Gentlemen,

I , as a very minor bbs software author have had huge problems
in the past getting info about what is really going on in the
pbbs world.

I see W0RLI, AA4RE and VE3GYQ ,to name three, on here and
presenting more verbage than I've ever seen from them.

How about, if not a rec.radio.amateur.pbbs, at least a mailing
list for pbbs stuff? I know about several others like me who
have their own pbbs software ( because they wanted to do
something that the RLI/4RE/MBL stuff wasn't designed for, like
run in a unix environment) who would greatly benefit from
knowing what the latest "whiz-bang" feature is that's going to
make us incompatible with the pbbs network *this* week 8-) .

I guess we have to do more educating, like some suggest. One
facet of education is information, and there has been almost no
flow of same regarding the pbbs net. It seems that a lot of the
present confusion and flame-throwing were initially caused by
lack of education/information among internet folks who weren't
aware that packet radio addresses were different and should not
be used on internet !

To perhaps better summarize: 1. There is no flow of information
pbbsnet->internet. 2. There is no flow of information
internet->pbbsnet. 3. There is no flow of information concerning
pbbs software design.

Can we fix this?Jim, W2XO

------------------------------

Date: 9 Aug 91 18:32:33 GMT From: [e-mail]
Subject: .NA and comment to Brian Kantor To:
[e-mail]

Thanks Brian for the private reply re RFCs etc. Of course I
recognize that they have become standards and I was really not
trying to argue the point - but they are standards on the
INTERNET. They seem to have stood the test of time in many
cases, and that does give one cause to consider adopting  them
elsewhere - but it cannot be considered mandatory.

It strikes me that the problem has come up because: someone used
a gateway that does not provide proper encapsulation, or someone
posted someone else's message from the bbs network onto the
INTERNET without indicating such...

I agree, that would seem to be where the problem lies ... the
other point that folks seem to be ignoring is that by and large,
the BBS network IS NOT INTERESTED in using the INTERNET to pass
messages. That having been said, I think folks have to
understand why the BBS sysops feel frustrated at listening to
this debate.

Yes, an attempt will be made to help out ... but I think the
gateways will have to help as well.

And to the person who said that the continent codes were "made
up", I DON'T THINK SO  !!!

Wow, what a monster thread ... since I get this via the digest,
the thread  appears to be a little disjointed with respect to
response time.

Dave VE3GYQ

ria.ccs.uwo.ca!toth!dave

------------------------------

Date: 10 Aug 91 02:20:40 GMT From: [e-mail]
Subject: AA4RE BBS test version available To:
[e-mail]

A test version of my BBS program entitled 2.1Q is now available
via FTP from W3IWI's tomcat system.  This is a test version and
it has bugs.

Significant new features:  -- shared overlay file manager (no
more busy messages)  -- new full screen review command to allow
easy monitoring     of messages  -- direct interface to G8BPQ
node V4.03.  Eliminates need for     DEDHOST code.

Files are  BB21Q.ZIP -- Everything  BB21QU.ZIP -- All files
updated since BB2.11 (the current released
version).

Roy enge @ almaden.ibm.com

Please note the address change.  So many IBMers are on the
internet these days that we are having to divide the domain.

------------------------------

Date: 9 Aug 91 06:44:46 GMT From:
cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu
!spool.mu.edu!cs.umn.edu!kksys!edgar!brainiac![e-mail]
.edu Subject: FTP sites for KA9Q code? To: [e-mail]

In article <[e-mail]>
[e-mail] (Keith Thompson) writes: > >Hi, > >I
did a dumb thing and accidentally deleted my mail files with the
locations >of the FTP sites for KA9Q NOS code. >Could some kind
soul please either send me a list of these site or post them?

Phil Karn has relocated to San Diego, CA.  His latest work can
be found on ucsd.edu [128.54.16.1]

--     Jeffrey R. Comstock -- HOME [e-mail] -- WORK
[e-mail]

------------------------------

Date: 9 Aug 91 13:19:57 GMT From: [e-mail]
Subject: help To: [e-mail]

help

------------------------------

Date: 9 Aug 91 16:14:45 GMT From:
salt!sunrise![e-mail] Subject: Help with ka9q
and mbuf data structure To: [e-mail]

Hi, I'm not sure if this is the right newsgroup, but....

I am using an mbuf struct (file mbuf.c in net package), and I am
rewriting the contents of a TCP packet's body, and hence must
resize the thing by doing something like:

oldlen = len_p(bp); newlen = strlen(newdata); difference =
newlen - oldlen;

if (difference > 0)        bp=pushdown(bp,difference); else
  pullup(&bp,dum,oldlen-newlen); memcpy(bp->data,newdata,newlen);

Say the original mbuf length was longer than the new one, this
resulted in a pullup so that the new mbuf is the correct length
and the packet is sent as desired;  however, not the next
packet, but the subsequent packet after that contains the
"chopped off" stuff tacked onto the beginning of the data field
... I can't seem to be able to get rid of this extra segment
period.. I've also tried a call to trim_mbuf(), but the same
thing happens.

Does anyone know what I should do?

thanks in advance, cheers, tony

------------------------------

Date: 9 Aug 91 14:55:52 GMT From:
crayola.cs.umd.edu![e-mail] Subject: Status reports
on pmp? To: [e-mail]

A few weeks ago, there was a flurry of excitement about 73 Mag's
pmp project (Poor Man's Packet).  Have any of you put this
together?  How well does it work?

                    --Rick

                  N3JGF

------------------------------

Date: 10 Aug 91 00:32:21 GMT From: [e-mail]
Subject: The great .NA controversy.... To: [e-mail]

References: to numerous to mention.

Instead of trying to assign blame or point fingers, lets solve
the problem.  What is done is done.  As pointed out by several
people, the sheer inertia of the current AX25 BBS system
precludes any solution involving a radical change in address
format.

Here's my ideas:

  1) Internet users who refer to their BBS addresses in
signature     blocks should make it plain that these are AX25
packet BBS     addresses and not Internet addresses.

  2) Gateways that bridge AX25 packet BBS messages into the
internet     should alter the contents so that any return
address is clearly     marked as not being for Internet.

I think we can all agree on this?????

 Finally, we amateurs must answer the question:

     Do we want the TCP/IP network and the packet AX25 BBS
network     to be able to interoperate?

If not, you can disregard most of the rest of this message.

If so, should we plan on merging the TCP/IP domain naming
convention with the AX25 packet BBS address scheme?  I like the
idea of a top-level domain name / hierarchical address word that
indicates the rest of the information is the AX25 BBS address.
Several people have mentioned this previously but we continue to
yell at each other rather than trying to solve the problem.  I
will again reiterate my suggestion of things like:

     aa4re.#nocal.ca.usa.na.ax25bbs

This change will be transparent to most AX25 BBS programs.
Unfortunately, my BBS does not do the left to right parsing but
does worry about the whole name.  Luckily, one pass over the
control files will fix that.

Addresses that are used on the internet will go to a
non-existent domain or maybe someone will use them as gateway
indicators.

Amateur radio TCP/IPers could also use the high level domain
name to indicate that the message must go to an AX25 BBS system
for delivery. This might even relieve the necessity of coding
every amateur call into control files to indicate SMTP versus
AX25 BBS destination?

Am I all wet with this or does it make sense.  I am learning a
lot about TCP/IP these days and am not an expert but it looks
right to me.  Can we confine the discussion on this to technical
issues rather than political/religious flaming?

Roy, AA4RE

enge @ almaden.ibm.com

Please note the address change.  So many IBMers are on the
internet these days that we are having to divide the domain.

------------------------------

Date: 9 Aug 91 21:43:00 GMT From: [e-mail]
Subject: What RFCs are (one version) To: [e-mail]

In Packet Radio digest #200, ria.ccs.uwo.ca!toth!dave (Dave
VE3GYQ) wrote:

>2) some folks have mistaken RFC's for STANDARDS - they are not
- they are >   Requests For Comments - they may have become de
facto "standards", but >   they tend to be limited to the
INTERNET,

from Internetworking with TCP/IP (first edition) by Douglas
Comer, page 7, section 1.6:

"Reports of work, proposals for protocols, *AND* protocol
standards *ALL* appear in a series of technical reports called
Internet Request For Comments, or RFCs." (emphasis added)

If you look up the same page a little, you can be enlightened
(if not already) about the IAB etc.

This book was money well spent.  I need to get the second
edition(s).

Reid,  WB7CJO

------------------------------

Date: 9 Aug 91 14:45:21 GMT From:
borland.com![e-mail] To: [e-mail]

References <[e-mail]>,
<20010@hel, <[e-mail]> Subject : Re: 'NA'
country domain appears to be non-unique

If the problem is that mail to [e-mail] physically goes
to Namibia before being bounced, isn't there a solution
involving having domain name servers that are better connected
that handle the NA domain and know about the proper subdomains
there? I just checked how mail I send would go to lisse.na, and
I find MX records at m2xenix.psg.com and rain.psg.com. Looking
at the latter, I see MX entries for the default names that
address an apparently bogus host named
"no.such.host.in.namibia.na". It looks like it is supposed to
bounce mail to bogus NA addresses without it going there.

Dr. Lisse, I would suggest sending mail to
[e-mail] if this isn't working, and to the
postmasters at the other domain name servers that provide your
routing if it works, but is only installed over there. From
these discussions, it seems like you need a solution much
earlier than any change is going to occur in the amateur packet
systems.

 -- sidney markowitz <[e-mail]>

------------------------------

Date: 9 Aug 91 14:32:19 GMT From:
mvb.saic.com!unogate!orion.oac.uci.edu!usc!cs.utexas.edu!helios!c
s.tamu.edu![e-mail] To: [e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail]> Subject
: Re: 'NA' country domain appears to be non-unique

In article <[e-mail]>, [e-mail]
(Mike Lawrie) writes: |> In <[e-mail]>
[e-mail] (Kurt Freiberger) writes: |>  |> >  What
is needed is gateways that are intelligent enough to do the
address |> >translation properly.  I suspect that the reason the
Nambians are getting  |> >mail wrongly is NOT because the BBSnet
addressing scheme is "wrong", but  |> >because some gateway
somewhere screwed up. |>  |> You _really_ do not understand the
problem. The networks and their |> gateways are working 100%.
|>  |> When an ordinary user (not an expert, just an ordinary
user) sees |> in a signature "My packet address is
[e-mail]), that user |> simply mails to that very
address, and expects the mailer to know |> how to get to
some.where.in.NA. Now of course the mailer knows how |> to do
this, it sends the mail to Namibia, exactly as instructed. |>
|> Please think carefully now - where else can the mailer
deliver |> .NA mail to except to Namibia? That is where the mail
gateways |> will deliver it. |>  |> The problem is that the
ordinary user is misled into thinking that |> he simply uses
what looks like an ordinary FQDN address. Not a |> gateway
problem, not a munging problem, but a problem created by |> a
packet radio type saying "My address is in Namibia". What he |>
_means_ to say is "My address is in North America". |>

Just for grins, I checked out another amateur newsgroup, and
found the  following addresses in signatures.  I think many are
confusing....-Willis n5szf
=================================================================
====== Bob N3EMO [e-mail] [e-mail]

* PACKET - NP4AI@N0ARY.#NOCAL.CA.USA.NA *  "All things bright
and beautiful * *  UUCP  - [e-mail]         *   All
creatures great and small   *

Bill Hester, Ham Radio N0LAJ, Denver CO., USA | N0LAJ @
W0LJF.CO.USA.NA Please route replies to: [e-mail]
or uunet!nyx!whester

Andrew Scott Beals    [e-mail],
kc6sss@n6eeg.#nocal.ca.usa.na 147.300MHz+, 440.900MHz+ [ctcss
114.8Hz]

     EMail [e-mail]         AMPRNet
[e-mail]

--Disclaimer:-Tampere-a-place-in-Finland-where-everything-gets-ta
[e-mail]          why use a telephone when
you can mail me [e-mail]
Radioamat||ritekniikan seuran ohjelmapankki [e-mail]
                  Also Santa Claus sends packets ...

    Dennis S. Breckenridge VE7TCP@VE7TCP [44.135.160.59]
[e-mail]

Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws), 72277,1325
N8EMR @ N8JVY (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]

|> How much more simply must this problem be explained? |>  |>
My word, no wonder it is a problem.

------------------------------

Date: 9 Aug 91 22:52:42 GMT From:
sdd.hp.com!cs.utexas.edu!helios!cs.tamu.edu![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail].E Subject :
Re: 'NA' country domain appears to be non-unique

In article <[e-mail]>,
[e-mail] (Marc T. Kaufman) writes: |>  |> There
is no need to shoot the network.  However, BBSNet *CAN* be held
|> responsible for using an address format that can be
misinterpreted -|> especially when people have been telling them
over and over that the |> misinterpretation WILL occur, and
especially where there are real |> synonyms for the names (e.g.
if Continent designators are used).  If the |> Post Office tried
to assign addresses of the form: [phone], I think |> we
would be justified in complaining that the address FORMAT was
not |> unambiguous enough to prevent people from using the
address in an incorrect |> context (i.e. as a phone number).

OK, I'll go that far.  BBSNet can be held responsible for usng
an address format that can be misinterpreted.  But the fool that
uses the address  wrongly should be held responsible for causing
the grief!  You don't blame the tool, you blame the guy holding
it!

     Please provide names as to who told whom about these
problems.  I have  yet to see any documentation on this part.

     As to the Post Office part, remember that the Post Office
governs the  communications in other countries, 8-}, so they
could have very well done so.  |> -|> The problem is that the
ordinary user is misled into thinking that |> -|> he simply uses
what looks like an ordinary FQDN address. Not a |> -|> gateway
problem, not a munging problem, but a problem created by |> -|>
a packet radio type saying "My address is in Namibia". What he
|> -|> _means_ to say is "My address is in North America". |>
|> >     Is the "packet radio type" saying that his INTERNET
address is "My  |> >address is in Nambia" or his PACKET RADIO
address looks like an Internet |> >address in Nambia?  If the
former, correct him.  If the latter, sigh and  |> >reflect on
the ignorance of mankind, then proceed to educate the sender of
|> >the message.  Ours is not a perfect system.  I understand
the "symptoms"  |> >of the problem have been abated.  I'm glad
for that. |>  |> If I tell you to contact me at [phone], I
think you are justified in |> thinking this is a phone number,
for use on the telephone network, and not |> an address for use
with paper mail.  If I tell you to contact me at |>
[e-mail] it is not intrinsicly obvious that
this is a |> BBSNet address rather than an Internet address.

     It is to me, since I have a few brain cells to recognize
the address. Now if you are expecting the whole world to have
the power of a TRS-80, you should tell me Packet Radio: wb6ece@
wb6ece.something.NA, thus effecting a soluton to the problem.

|> The problem with the ham radio BBSNet folks (and I mean
specifically the ones |> who set the standards for the routing
designators) is that they just don't |> give a damn about how
their actions may affect non-hams.  As long as the |> address
format works on BBSNet, to hell with any ambiguities and
problems |> it may cause on Internet, or JANET, or BitNet, or
FidoNet...

     Since we, by FCC rules are not SUPPOSED to be directly
interconnected,  it wasn't supposed to happen anyway.
Third-party traffic, remember?  BBSNet addresses will work well
if one goes through a gateway, using proper address Hell, yes,
BBSNet addresses may go astray and cause problems.  But use them
 properly and it works.  |> Until these folks grow up and adopt
a world view, ham radio BBS operations |> will continue to be
looked down upon by others not in the hobby.  I hope |> you
noticed Dr. Lisse's comment re: the FCC.  It is not
inconceivable, in my |> mind, that the FCC would mandate a
non-conflicting address format if it got |> enough complaints
from other countries.

     Pardon me?  We've been transferring messages all over the
world for some time without the Internet, thank you.  I'd take
that as a world view.  I'm  sure that SNA bigots consider the
Internet as below their notice.  This whole thing boils down to
the fact that:      A. BBSNet address formats are similar enough
to cause problems if

 used on the Internet.      B. Some Internet folk think that
since this is a problem, the others          must change to
conform. Sounds very much like certain political viewpoints to
me....  It'd be quite illuminating to take a poll as regards gun
control.

      As far as the FCC is concerned, I rather think they'd
laugh in your face. The problem is not related to anything in
which they have jurisdiction.  The problem lies in incorrect
operation not in their province.

|> Hank: are you listening?

     I'm sure he is.  |> Marc Kaufman ([e-mail])

--  Kurt Freiberger, wb5bbw      [e-mail]   409/847-8607
fax:[phone] Dept. of Computer Science, Texas A&M University
     DoD #264: BMW R80/7 pilot "We preserve our freedom using
three boxes: ballot, jury, and cartridge."      *** Not an
official document of Texas A&M University ***

------------------------------

Date: 9 Aug 91 00:38:45 GMT From:
swrinde!sdd.hp.com!spool.mu.edu!munnari.oz.au!manuel!csc.canberra
.edu.au!echo![e-mail] To: [e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: 'NA'
country domain appears to be non-unique

In <[e-mail]>
[e-mail] (Ron Murray) writes:

>In article <[e-mail]>, I
foolishly said: >>    In case you missed it, if you enter 'sb
rhubarb@xxx', your bulletin goes >> to the Great Bit Bucket In
The Sky (at least it does on an MBL system: I assume >> the
others are no better). You have to enter 'sb rhubarb@xxx $' if
you expect >> it to leave your own BBS.

>   Several people have pointed out that this only happens with
MBL software. >They're probably right: my local BBS is an MBL
system (whose sysop hasn't

The latest release of MBL, 5.14 is now several years old and
doesn't support heirarchical addressing very well. (In fact all
it does is pass the addresses thru, it doesn't actually use them
at all. :-( )  MBL was actually quite nice, it's a pity Jeff
didn't continue with it.

>somebody gets a bright idea for his/her BBS program, doesn't
think it through, >(and ABOVE ALL doesn't discuss it with some
of the other BBS authors), then >we get stuck with the results
for a couple of years till it all blows away. >Surely we can do
better than this? We are, after all, supposed to be in the
>communications business.

Even with communication there are problems, remember the header
lines argument and the heirarchical debate.  We ended up with
different authors going different ways AND they were talking
(well, yelling actually) at each other. :-(

>   Currently the problem is that packet radio addresses look
like Internet >addresses, and I wouldn't blame some poor sod who
didn't know the difference

>I think I'd agree with the poster who suggested that changing
the separator >from '.' to something else would be a good start.

It's a good idea, however there is a tremendous amount of
inertia in the packet BBS community.  If we did decide to change
the separator then we'd end up with two different ways of
specifying an address.  Just look at all the people still
running early versions of BBS code, some even that don't support
heriarchical addressing and so on.  I doubt whether we could
convert most sysops at all.  Remember, most Amateurs are totally
ignorant of other networks and so are very parochial and, often,
antagonistic when confronted with change.  (example, the CW
debate)

What the above waffle means is that I don't think changing the
separator is practical.

Perhaps what gateways should be doing is appending .ampr.org on
everything originating from the packet network?

> Ron Murray (VK6ZJM) > Internet: [e-mail] >
  "The world is a pork chop" -- #44 in a series of profound
sayings

Carl, [e-mail] (urk that's long. :-( )
[e-mail] 3:620/243.14 eh? Disclaimer?

------------------------------

Date: 9 Aug 91 16:10:32 GMT From:
mvb.saic.com!unogate!orion.oac.uci.edu!usc!zaphod.mps.ohio-state.
edu!swrinde!cs.utexas.edu!helios!cs.tamu.edu![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail]> Subject
: Re: 'NA' country domain appears to be non-unique

In article <[e-mail]>, [e-mail]
(Mike Lawrie) writes:  |> You _really_ do not understand the
problem. The networks and their |> gateways are working 100%.

     Can you say that with 100% accuracy?  I posted, correcting
myself.  See that message.  But it remains:  BBSNet canNOT be
held responsible for someone who uses an address wrongly.  The
individual user is to blame.  If he uses my telephone number or
address and it goes astray, should I have my postal system
change?  Granted, some folks post their packet address in their
.sig and this may lure the unwary astray.  User education,
again, NOT that a whole network should be taken out and shot.

|> When an ordinary user (not an expert, just an ordinary user)
sees |> in a signature "My packet address is
[e-mail]), that user |> simply mails to that very
address, and expects the mailer to know |> how to get to
some.where.in.NA. Now of course the mailer knows how |> to do
this, it sends the mail to Namibia, exactly as instructed.

     Unfortunately, true.  However, I'd bet you a six-pack that
mail goes astray all over the Internet all the time because of a
bad address.  This  happens to be a rather glaring case.  |>
Please think carefully now - where else can the mailer deliver
|> .NA mail to except to Namibia? That is where the mail
gateways |> will deliver it. |>  |> The problem is that the
ordinary user is misled into thinking that |> he simply uses
what looks like an ordinary FQDN address. Not a |> gateway
problem, not a munging problem, but a problem created by |> a
packet radio type saying "My address is in Namibia". What he |>
_means_ to say is "My address is in North America".

     Is the "packet radio type" saying that his INTERNET address
is "My  address is in Nambia" or his PACKET RADIO address looks
like an Internet address in Nambia?  If the former, correct him.
 If the latter, sigh and  reflect on the ignorance of mankind,
then proceed to educate the sender of  the message.  Ours is not
a perfect system.  I understand the "symptoms"  of the problem
have been abated.  I'm glad for that.

|> How much more simply must this problem be explained?

Indeed. --  Kurt Freiberger, wb5bbw      [e-mail]
409/847-8607  fax:[phone] Dept. of Computer Science, Texas
A&M University      DoD #264: BMW R80/7 pilot "We preserve our
freedom using three boxes: ballot, jury, and cartridge."
*** Not an official document of Texas A&M University ***

------------------------------

Date: 9 Aug 91 19:42:40 GMT From:
ucselx!sol.ctr.columbia.edu!samsung!think.com!snorkelwacker.mit.e
du!stanford.edu!neon.Stanford.EDU![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail].E Subject :
Re: 'NA' country domain appears to be non-unique

[e-mail] (Kurt Freiberger) writes:

>     Can you say that with 100% accuracy?  I posted, correcting
myself.  See >that message.  But it remains:  BBSNet canNOT be
held responsible for someone >who uses an address wrongly.  The
individual user is to blame.  If he uses >my telephone number or
address and it goes astray, should I have my postal >system
change?  Granted, some folks post their packet address in their
.sig and >this may lure the unwary astray.  User education,
again, NOT that a whole >network should be taken out and shot.

There is no need to shoot the network.  However, BBSNet *CAN* be
held responsible for using an address format that can be
misinterpreted -especially when people have been telling them
over and over that the misinterpretation WILL occur, and
especially where there are real synonyms for the names (e.g. if
Continent designators are used).  If the Post Office tried to
assign addresses of the form: [phone], I think we would
be justified in complaining that the address FORMAT was not
unambiguous enough to prevent people from using the address in
an incorrect context (i.e. as a phone number).

-|> The problem is that the ordinary user is misled into
thinking that|> he simply uses what looks like an ordinary FQDN
address. Not a|> gateway problem, not a munging problem, but a
problem created by|> a packet radio type saying "My address is
in Namibia". What he|> _means_ to say is "My address is in North
America".

>     Is the "packet radio type" saying that his INTERNET
address is "My  >address is in Nambia" or his PACKET RADIO
address looks like an Internet >address in Nambia?  If the
former, correct him.  If the latter, sigh and  >reflect on the
ignorance of mankind, then proceed to educate the sender of
>the message.  Ours is not a perfect system.  I understand the
"symptoms"  >of the problem have been abated.  I'm glad for that.

If I tell you to contact me at [phone], I think you are
justified in thinking this is a phone number, for use on the
telephone network, and not an address for use with paper mail.
If I tell you to contact me at [e-mail] it is
not intrinsicly obvious that this is a BBSNet address rather
than an Internet address.

The problem with the ham radio BBSNet folks (and I mean
specifically the ones who set the standards for the routing
designators) is that they just don't give a damn about how their
actions may affect non-hams.  As long as the address format
works on BBSNet, to hell with any ambiguities and problems it
may cause on Internet, or JANET, or BitNet, or FidoNet...

Until these folks grow up and adopt a world view, ham radio BBS
operations will continue to be looked down upon by others not in
the hobby.  I hope you noticed Dr. Lisse's comment re: the FCC.
It is not inconceivable, in my mind, that the FCC would mandate
a non-conflicting address format if it got enough complaints
from other countries.

Hank: are you listening?

Marc Kaufman ([e-mail])

------------------------------

Date: 8 Aug 91 20:00:07 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!ccml@uune
t.uu.net To: [e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: 'NA' country domain
appears to be non-unique

In <[e-mail]> [e-mail] (Kurt
Freiberger) writes:

>  What is needed is gateways that are intelligent enough to do
the address >translation properly.  I suspect that the reason
the Nambians are getting  >mail wrongly is NOT because the
BBSnet addressing scheme is "wrong", but  >because some gateway
somewhere screwed up.

You _really_ do not understand the problem. The networks and
their gateways are working 100%.

When an ordinary user (not an expert, just an ordinary user)
sees in a signature "My packet address is
[e-mail]), that user simply mails to that very
address, and expects the mailer to know how to get to
some.where.in.NA. Now of course the mailer knows how to do this,
it sends the mail to Namibia, exactly as instructed.

Please think carefully now - where else can the mailer deliver
.NA mail to except to Namibia? That is where the mail gateways
will deliver it.

The problem is that the ordinary user is misled into thinking
that he simply uses what looks like an ordinary FQDN address.
Not a gateway problem, not a munging problem, but a problem
created by a packet radio type saying "My address is in
Namibia". What he _means_ to say is "My address is in North
America".

How much more simply must this problem be explained?

My word, no wonder it is a problem.

Mike--

Mike Lawrie Director Computing Services, Rhodes University,
South Africa
.....................<[e-mail]>.......................
... Rhodes University condemns racism and racial segregation

------------------------------

End of Packet-Radio Digest V91 #202
****************************** Date: Sun, 11 Aug 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #203 To: packet-radio

Packet-Radio Digest         Sun, 11 Aug 91       Volume 91 :
Issue 203

Today's Topics:        'NA' country domain appears to be
non-unique (2 msgs)                   Adding a name to the mail
server                            BPQ Node V4.04
             Continent                                Hello
               KA9Q copyright and question.                Using
packet radio to connect to work

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 10 Aug 91 15:23:32 GMT From:
usc!samsung!umich!umeecs!msi.umn.edu!noc.MR.NET!uc!apctrc!voyager
![e-mail] Subject: 'NA' country domain appears to be
non-unique To: [e-mail]

I've been watching this one on and off, and seeing as how this
nonsense is *** STILL *** going on, I have to ask a few
questions....

then, I'm going to ask/suggest something that may very well help
(and it may not).

none of this is meant as a flame --- please do not interpret it
as such.

In article <[e-mail]>
[e-mail]  writes:

> Well Marc,  we (the bbs authors) await your suggestions. >
What is it we should do?  How should we do that?

as has already been said at least a hundred-thousand times,
follow the accepted standards.  the argument that it doesn't
work is false.  I can see why this screwup might have happened
in the first place --- the bbs software was written in a vacuum.
 at the time, perhaps this was considered ok, since it was
intended to be used that way as well.  now, however, that
assessment is turning out to be wrong.  fine.  you know what
they say, do it right the first time....or you have to spend
twice as much time fixing it later.  guess what.......

> While doing that (whatever it is) keep in mind that we > wish
to support only a small number of users (about 100,000) > with
only a small number of servers (about 10,000), and that > those
users will often have *NO* local processing capability.

first, WHO CARES if the users themselves have '*NO* local
processing capability' --- granted, right now, I'm using a pc to
pretend that it's a dumb terminal...but it basically has no say
in the operations of the UNIX machine I'm working from.  does
that prevent me from sending e-mail and posting articles?  no.
it has nothing to do with it.

my dumb pc keeps sending bits to a far-away land.  it knows
nothing of what will happen to those bits, nor does it care.

now, as far as BBSs not having the smarts to do global
routing....WHO CARES? my UNIX machine here (well, there....
:-)) knows nothing about routing mail beyond Amoco computers.
in fact, it sometimes has problems with that (or did, at least).
 it doesn't matter.  when my machine has mail to send that it
doesn't know how to handle, does it just go off into a corner
and sulk? no.  it passes it along to another machine who has
more mail routing information...like how to access non-Amoco
machines.

after my machine sends the mail on to its server machine, that
machine will then look at where the mail is headed, and if it
leaves Amoco, it will pass it along to our Internet mail
gateway, which.......  you get the idea.

so even the local BBSs don't have to know how to route to
everywhere in the world.  all they need to know is where to send
it if they don't know what else to do with it.

> So post some useful ideas please, since it sounds like you >
know what the solutions are.

ok.  here's my final question, which can also be taken as a
suggestion. if I want to send mail, for example, to friends back
in Aggieland on a machine that is on BITNET from Internet, I
would address it to [e-mail] --- notice the
.bitnet?  (yeah, I know....VENUS is also on the Internet...but
it's habit now.)

so, why can't we simply register something like '.packet' with
the NIC, and put all this nonsense to bed?  then, make sure
people know that if they want to mis-use .NA and call it North
America, they must also use the .packet to let the system know
it is for a foreign network.  now, I must admit that mail is not
my strongest area --- sendmail.cf still scares the sh_t out of
me, but it seems obvious that this is a solution to this, and
will help in any attempts to interconnect the lot.

my packet address might then look like
[e-mail] or something like that.  the gateway
machines (if there are any) could then say ``hmmmm....he's a
.packet, and is in ill. --- he must therefore be in
.usa.na.earth.western_spiral_arm.milky_way.universe'' or
whatever it wants.  who cares --- from that point, it would be
leaving the Internet machines alone.  but while on the Internet,
it would conform to standards. the gateway machine has the
smarts.

likewise, if I sent mail (mind you, this all assumes that such a
gateway exists) from packet to an Internet address in
Nambia,.....

while on packet: >From:
[e-mail]_spiral_arm.milky_way.uni
verse >To: [e-mail]

once on the Internet: >From: [e-mail] >To:
[e-mail]

so what's the problem?

oh, people would have to be sure that their .signature clearly
points out that their address is in .packet.

   --jim

Standard disclaimer....These thoughts are mine, not my
employer's.

-----------------------------------------------------------------
------------Share and Enjoy!  (Sirius Cybernetics Corporation,
complaints division) 73, de n5ial

Internet:  [e-mail]  (- or -)  [e-mail]
Amateur Radio:   TCP/IP:    [e-mail] (44.72.47.193)
Packet:    n5ial@wb9yae    (Chicago, IL,
US)--------------------------------------------------------------
----------------

------------------------------

Date: 11 Aug 91 07:10:31 GMT From:
uhccux!uhunix1.uhcc.Hawaii.Edu![e-mail] Subject: 'NA'
country domain appears to be non-unique To: [e-mail]

Some folks use .NOAM instead of .NA as the continent designator.
 Why not  switch to .NOAM?  No sense in reinventing the wheel
here.  You can even  register that with the NIC if they'll let
you.  This will solve one part of  the problem.  Educating the
user population about the differences between PBBS addresses and
Internet addresses is something else :-)

As a gateway operator, I've taken steps to intercept addresses
of the form *.<ISO country code>.NA so that they are forced to
the PBBS world instead of the Internet.  Unfortunately, this
means an additional 46 lines in the NOS rewrite file.  Those 46
extra lines take all the wind out of a basic tenet  behind
hierarchal addressing - simplification of routing.  The sooner
we get away from .NA, the better.

For those of you who are still debating the merits of using the
Internet to route PBBS mail, be advised that isn't the only
reason the gateways exist.  The gateways also provide mail paths
between Internet hams and packet hams.  They provide access to
Usenet news for Hams on packet.  They provide packet access  to
the callsign servers.  The gateway operators wouldn't have set
these systems up if there wasn't a desire or perceived need for
them.  The gateways haven't been around for very long but they
will continue to exist and grow in number.

It is a general nature of networks (PBBS and Internet included
of course) to grow and become interconnected with other
networks.  That is the reality we must deal with now.
Finger-pointing isn't going to help us deal with that
reality...--

Antonio Querubin   [e-mail] / [e-mail]
/ [e-mail]

------------------------------

Date: 11 Aug 91 03:11:25 GMT From: [e-mail]
Subject: Adding a name to the mail server To:
[e-mail]

I would appreciate a quick note on how to add my name  to the
mail server that sends out the packet radio digest  from
ucsd.edu.

For expediency, please mail to:

[e-mail]

Thanks in advance to anyone willing to take the time.

Ed Geiger KD4AB

------------------------------

Date: 11 Aug 91 02:39:11 GMT From: [e-mail]
Subject: BPQ Node V4.04 To: [e-mail]

I have uploaded BPQ Node V4.04 to both ucsd.edu and tomcat FTP
servers.

Roy, AA4RE

------------------------------

Date: 10 Aug 91 12:56:38 GMT From:
swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.
ohio-state.edu!linac!att!cbnewsj![e-mail] Subject:
Continent To: [e-mail]

Some people have misunderstood what I was saying so let me
explain...

On the packet RADIO network I see no need for the continent
identifier. The reason being is that the percentage of PBBS that
send mail to other countries is small compared to all PBBS in a
country. So the average PBBS would route all his/her mail for
not their country i.e. not USA to the same down stream station.
Only the big international gateways need to have the
intellegence and extensive routing for each country. Yes the
list would be long. But it would be putting the workload where
it should be on the PBBS that is routing international traffic
and not make everybody carrying the continent id around. Of
course the 3 letter ISO country code should be used so everybody
is using a  "standard".

Just my 2 cents. It's your nickel now. 73 Tom, KB2GLO.

--  Tom Kenny, KB2GLO uucp: att!mtuxo!tek
internet: [e-mail] packet radio:
kb2glo@n2kzh.#cnj.nj.usa  ampr: [e-mail] [44.64.0.10]

------------------------------

Date: 11 Aug 91 11:51:07 GMT From: [e-mail]
Subject: Hello To: [e-mail]

Hello, Yes, I know that this is taboo.  Could someone please
email me the proper address for getting this mailing list?
Thanks Gary Clark II "waiting on my call N5xxx"
[e-mail]

------------------------------

Date: 9 Aug 91 13:53:44 GMT From:
nosc!dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!qt.cs.utexas.
edu!yale.edu!think.com!spool.mu.edu!cs.umn.edu!kksys!edgar!braini
ac!moron![e-mail] Subject: KA9Q copyright and question.
To: [e-mail]

[e-mail] writes:

> I'm planning to port KA9Q from PC-DOS to a multiuser OS.  My
questions is  > what type of copyright will I be violate if I
modify the program? (estimate > percent of change is around 40%
to 60%).  I am interest in getting a  > respond from the author
and anyone else on this subject. >   > John >

John,

You won't be violating any copyrights unless you try to SELL the
ported code  AND/OR you are going to use it for purposes other
than Amateur Radio or  within an educational establishment (i.e.
a colleg - internal corporate  training departments don't count
:-) ).  In a nutshell, the code may not be  used within a
commercial environment, UNLESS it is for your personal Amateur
Radio pursuits.

This copyright information is imbedded within the source code
modules, which  were written by a number of different people,
the most noteworthy being Phil  Karn, KA9Q himself.

73

     73's     Chris Cox  W0/G4JEC

     EMail [e-mail]         AMPRNet
[e-mail]


------------------------------

Date: 9 Aug 91 18:24:25 GMT From:
ucselx!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!wupost!kuhu
b.cc.ukans.edu!zeus.unomaha.edu![e-mail] Subject: Using
packet radio to connect to work To: [e-mail]

In article <[e-mail]>, [e-mail]
(Darrell Long) writes: > Article-I.D.: darkstar.19188 > Lines:
18 >  >  > Hi.  I'd like to use packet radio to connect my
workstation at home to my > workstation at the University.

Oh boy!

Your posting touches on many of the frequently asked questions
that are asked about our hobby, including packet radio.

Rather than answer them here (and have everyone followup,
debate, flame, counterflame) perhaps some assigned reading would
be in order.

There is an excellent set of informational documents prepared
that are available via anonymous FTP (ftp.cs.buffalo.edu under
/pub/ham-radio).

They include:

1.  A list of general amateur radio frequently asked questions
with consensus answers written by Diana Syriac, KC1SP.

2.  A similar list specifically dealing with packet radio
written by Steve Schallehn, KB0AGD.

3.  A list of mentors (called "Elmers") to refer to for specific
questions via E-mail written by me.

To answer your question about whether you can use packet radio
to connect to your University computer, well, yes and no.

The amateur radio service is allocated by the FCC for individual
experimenters with specific prohibitions against furthering
business of any party (directly or indirectly, profit or
non-profit) and against non-licensed individuals initiating
communications via amateur radio allocations.

If you have any more specific questions not answered by the
above, please don't hesitate to write me E-mail.

Good luck!

73, Paul, KD3FU

[e-mail]

------------------------------

End of Packet-Radio Digest V91 #203
****************************** Date: Mon, 12 Aug 91 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #204 To: packet-radio

Packet-Radio Digest         Mon, 12 Aug 91       Volume 91 :
Issue 204

Today's Topics:             'NA' country domain appears to be
non-unique           2 memberships to Chicon (WorldCon-91) for
sale.            Standards activity on Radio WANs in US, Japan
             The great .NA controversy.... (2 msgs)
  Using packet radio to connect to work

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 11 Aug 91 14:02:08 GMT From:
swrinde!zaphod.mps.ohio-state.edu!wupost!emory!wa4mei!nanovx!glos
ter![e-mail] Subject: 'NA' country domain appears to be
non-unique To: [e-mail]

[e-mail] (Dr. Eberhard W. Lisse) writes:

> No this is not at all the case. It happens only because
someone put > something like xxx.xxx.USA.NA into his signature
and someone else uses > this to answer him. It has nothing at
all to do with any gateways > (which may not even exist). >  >
> regards, el > -> Dr. Eberhard W. Lisse    \          /
         ([e-mail]) > Katatura State Hospital   \
   |     ([e-mail] works for small files) > Private Bag 13215
         \ *    / ([e-mail] in September) >
Windhoek, Namibia           ;____/      (no FTP yet. [This is
Africa :-)-O])

Forgive a pragmatic response to a technical problem, But I have
observed the above signature quite a number of times. This has
raised a question for me. Considering the bandwidth of this
discussion, and presuming that Dr. Lisse is getting our side of
this  discussion also, and allowing his own above remark that
the problem is not  gateways but users forgetting which network
they are on and mis-addressing;   Then surely there is more
discussion than mis-addressed mail. If that is the case,  could
it be we have a straw dog? I am not saying that  the addressing
problems do not need to be rectified, but this discussion and
its "wheel-spinning" are more of a problem than the problem.

Thank you for your patience,                        Chris  N4VTE

-----------------------------------------------------------------
[e-mail] (chris)     All jobs are easy
                             to the person who
                  doesn't have to do them.
                        Holt's law

------------------------------

Date: 12 Aug 91 08:03:33 GMT From:
casbah.acns.nwu.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.ed
u!spool.mu.edu!olivea!tardis![e-mail] Subject:
2 memberships to Chicon (WorldCon-91) for sale. To:
[e-mail]

A friend of mine has two memberships to Chicon-V (the 49th World
Science Fiction Convention) for sale.  The Con is 29-Aug through
2-Sep-91 at the Hyatt Regency in Chicago.

The current price for membership is $150.  Michael Rightor is
asking $125 each for two Attending Memberships.  Call him at
[phone]; leave a message on the machine.

------------------------------

Date: 12 Aug 91 09:49:56 GMT From:
mcsun!ukc!educ-isis![e-mail] Subject: Standards activity
on Radio WANs in US, Japan To: [e-mail]

I AM POSTING THIS ON BEHALF OF A FRIEND WITH NO CURRENT NETWORK
ACCESS

What is happening - if anything - in the standardisation of
protocols for Wide Area Radio-based packet networks for data
transmission (i.e. Aloha and its descendants)?

I need references to papers, reports of progress, and contacts
with which to discuss any US or Japanese activity and to
exchange information on what is happening in Europe. Any related
activity -

  - Circuit-swicthed radio data nets if data provision is more
 than just an add-on to digitised voice

  - Packet-switched radio LANs, but only if the technology is
thought    to be adaptable to wide area use

- is also of interest.

Any archives which contain information about current
standardisation  might also be useful.

All contributions gratefully received! Will summarise to net if
sufficient interest.

Thanks.

--  JANET: [e-mail]            | Lindsay Wakeman EARN/BITNET:
[e-mail]    | Institute of Education
INTERNET:[e-mail]    | 20 Bedford Way
London WC1H OAL UUCP: !mcsun!ukc!educ-isis!law            | VOICE +44 71
636 1500 ext.512

------------------------------

Date: 11 Aug 91 20:37:46 GMT From:
usc!samsung!umich!umeecs!msi.umn.edu!noc.MR.NET!uc!apctrc!voyager
![e-mail] Subject: The great .NA controversy.... To:
[e-mail]

all this discussion on mail, and thinking about it last night,
has brought up some other questions I should have asked
yesterday.....  :-)  some of this isn't directly related to the
flaming/discussing going on, but they're all mail questions, and
most are at least indirectly related.

In article <[e-mail]> [e-mail]
(Roy Engehausen) writes:

>Finally, we amateurs must answer the question: > >     Do we
want the TCP/IP network and the packet AX25 BBS network >     to
be able to interoperate?

of course we do.  there is absolutely no reason why they should
not be able to interoperate.  I have a (sort-of) BBS running
here --- it's my hacked version of G1EMM's hack of KA9Q's TCP/IP
code (I've added some power it lacked, and took out
memory-wasting stuff I didn't need).  I would like very much to
tell the AX25 BBSs that my home BBS is n5ial.ampr.org --- then I
could check that mail locally, just like I do other mail.  I'd
also be able to just send mail to someone from a file (like
mailing someone src code in a sh archive, uuencoded ZIP files,
etc.)

considering the fact that the AX25 BBS I currently check into
(WB9YAE) is running TCP/IP, I don't see why this should be a
problem.  (Note, he isn't running nos --- he's running MSYS,
which is one I'm not familiar with.)  I can telnet to him or
connect to him...same results.

now, another question.  someone who isn't running TCP/IP wants
to send me e-mail via ax.25, but to my TCP/IP address --- how
should they do the addressing on their end?

now, the opposite in reverse --- from TCP/IP, I want to send
mail back to their ax.25 address.  how do I address that?

oh, btw, "why would you want to do that?" isn't much of an
answer....please don't bother with that one...I *** DO *** want
to do that.  I'm looking for real answers on how to use whatever
gateways there are between these.

third --- TCP/IP on both sides....  if I want to send mail to
anywhere in the US (or out of it, for that matter), are there
smart mailers setup somewhere that know about every address in
.ampr.org?  can I just send it, confident in knowing that some
mailer will know how to get it there, just like on the Internet?

>Can we confine the discussion on this to technical issues
>rather than political/religious flaming?

well..........  :-)

   --jim

Standard disclaimer....These thoughts are mine, not my
employer's.

-----------------------------------------------------------------
------------Share and Enjoy!  (Sirius Cybernetics Corporation,
complaints division) 73, de n5ial

Internet:  [e-mail]  (- or -)  [e-mail]
Amateur Radio:   TCP/IP:    [e-mail] (44.72.47.193)
Packet:    n5ial@wb9yae    (Chicago, IL,
US)--------------------------------------------------------------
----------------

------------------------------

Date: 12 Aug 91 09:37:05 GMT From:
elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!utgpu!nrcnet0!bnrgate!bm
erh409!bmerh287![e-mail] Subject: The great .NA
controversy.... To: [e-mail]

Roy, AA4RE writes:

>If so, should we plan on merging the TCP/IP domain naming
convention >with the AX25 packet BBS address scheme?  I like the
idea of a >top-level domain name / hierarchical address word
that indicates the >rest of the information is the AX25 BBS
address.  Several people have >mentioned this previously but we
continue to yell at each other rather >than trying to solve the
problem.  I will again reiterate my suggestion >of things like:
> >     aa4re.#nocal.ca.usa.na.ax25bbs > >This change will be
transparent to most AX25 BBS programs.

This idea makes sense.  If you look at the way that several
other  networks (uucp, bitnet) gateway with Internet, this is
exactly what they do.  For example, if I want to send mail from
my node (on Internet) to uunet which lives on the uucp network,
I would address my mail to: [e-mail]   Similarly, if I
want to send mail to someone at the University of Ottawa, which
lives on bitnet, I would address it to:  [e-mail]
The ".ax25bbs" (".bitnet", ".uucp") implies the existance of an
Internet domain of that name, which is used to route the message
to the appropriate gateway.

Now, I'll admit that there are other addresses which I could use
to get the mail to the sames places (eg: ulaval.bitnet is the
same as vm1.ulaval.ca -- routing will take care of things, since
Laval has a node on each network), but you get the point.

I think one of the main things here is that we are gatewaying
into an existing network.  As such, the gateways MUST play by
the rules of both networks, and must be given the "smarts" to
differentiate between the two networks.  If messages are going
from a network (Say, A) out to a point on another network (Say,
B), then back to A for final delivery, then something is wrong.
This is true whether amateur radio is involved or not.

Here's another solution.  Let's say that I'm on a network (OK,
let's say it's BBSNet), and I want to send something to a node
on  Internet.  So, I add ".internet" (or something) to the end
of the address.  This explicitly tells the gateway, to forward
the message (stripping the ".internet") via Internet to the
appropriate node. If I don't put the ".internet" on the address,
then the gateway will NEVER forward it to Internet.  The message
will be assumed to be destined for a node on the local network
and if it cannot be delivered, then there is an error in the
address.  Again, this is how most networks work.

Please note that I've tried to steer clear of the arguing that
is  going on regarding this topic (Since it really doesn't seem
to be leading to anything).  The above comments are true for
almost all networks which want to interact.


+----------------------------------------------------------------
+      |  Paul Totten  (VE3SPT)                 S.I.R. Tools
       |      |  [e-mail]                         Bell
Northern Research  |      |  "Don't do today what your computer
can do for you tonight"    |
+----------------------------------------------------------------
+      |  Note: The opinions here don't necessarily reflect
those of    |      |        my employer, or any of its other
employees.             |
+----------------------------------------------------------------
+

------------------------------

Date: 11 Aug 91 16:41:00 GMT From:
swrinde!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.i
astate.edu!sharkey!lopez![e-mail] Subject: Using packet
radio to connect to work To: [e-mail]

In <[e-mail]> [e-mail] (Darrell
Long) writes:

>Hi.  I'd like to use packet radio to connect my workstation at
home to my >workstation at the University.

>I'd appreciate any pointers as to:

>* What sort of license do I need (new code-free sounds nice)?

You can do packet with the code free license.

>* How much does the equipment cost?

couple hundred for a tnc, and about a hundred for a used rig

>* How far can I go (I am moving about 17 miles and over a hill
from the campus)?

Packet can go forever.  simplex can do 40-60 miles with a good
antenna (or more) and over digipeaters, you can go hundreds if
not thousands of miles.

>* Is there an existing TCP/IP implementation for packet radio
that will run on >  my Sun?

Ah.  BUT.  packet is slow.  and the application you are talking
about is probably not technically legal.  If you have ANY
graphics on your terminal forget it.  I have seen it take 10 to
30 seconds between linefeeds on a packet system when it is busy.

This is why I have never gotten all worked up over packet.  I
like the immediacy of my net connection.  Of course, being the
sysadmin, and having the hardware in my home sort of does spoil
a person.

Reasons it may not be legal to connect to your work site:

  1.  Prohibitions against anything REMOTELY commercial.  You
can not      legally call up the boss over the repeater
autopatch and tell him      you are gonna be late for work.  You
can not order a pizza (I think      that was the concensus here,
wasn't it?) and you could certainly      NOT do any work related
duties over packet   2.  There are very strict prohibitions
against third party messages      and they must be approved by a
licensed operator before being      transmitted.  So don't count
on reading the net over packet.      also the net frequently
finds itself peppered with nasty words.      this is a NO NO on
ham radio.

  ZZ

>* What's the first thing I should do to get started?

>Many thanks, DL--

=Marquette MI: It's Not the END of the world, but you can see it
from here= ==  Gary Bourgois flash@lopez
(rutgers!sharkey!lopez!flash)  GWN UPLink  == ==  3.950
Nationwide Amateur Radio Nightly after 0200z=Learning Channel ==
=============== WB8EOH = The Eccentric Old Hippie = WB8EOH
================

------------------------------

End of Packet-Radio Digest V91 #204
****************************** Date: Tue, 13 Aug 91 04:30:17 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #205 To: packet-radio

Packet-Radio Digest         Tue, 13 Aug 91       Volume 91 :
Issue 205

Today's Topics:        'NA' country domain appears to be
non-unique (7 msgs)           2 memberships to Chicon
(WorldCon-91) for sale.                          KA9Q and Turbo
C++                    The great .NA controversy....

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 12 Aug 91 17:25:50 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

Again ... sorry for not following the 'proper forms for
response' but I don't have the 'proper' news posting software,
so just do this in the simplest way ...

My comments with '***'

   ...  Hank

Date: 9 Aug 91 01:03:26 GMT From:
cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!emory!wa4mei!
ke4zv![e-mail] Subject: 'NA' country domain
appears to be non-unique

In article <[e-mail]>
[e-mail] writes: > >***  Well Marc,  we (the bbs
authors) await your suggestions. >***  What is it we should do?
How should we do that? >***  While doing that (whatever it is)
keep in mind that we >***  wish to support only a small number
of users (about 100,000) >***  with only a small number of
servers (about 10,000), and that >***  those users will often
have *NO* local processing capability. >***  So post some useful
ideas please, since it sounds like you >***  know what the
solutions are.

I would suggest the obvious solution is scanning routing hints
right  to left. Posting software should always require a full
hierarchial  address. It may supply default continent and
country, even state and  local, designators if none are supplied
by the user. Then by scanning  right to left all ambiguities
caused by local names are resolved properly  at the appropriate
local level. Your forwarding software should certainly have a
forwarding solution for continental designators that it can fall
back on if a forwarding solution fails for countries. Similarly,
if a country solution is found, it can be fallen back on if a
state solution is missing. And so on down to local LAN names.
There is  never any uncertainty because *every* address would
start with the same top level field as it's rightmost element
and the software scans until it can resolve no further. There
should never be confusion between  a country code and a
continent code, or some very localized code as  scanning
descends the routing hierarchy. The only precaution needed to
prevent problems with other networks is to avoid using
conflicting top  level names. In the case of the BBSNET, there
are only seven to worry about. The major fault of current BBS
software, as I see it, is that it doesn't respect it's own self
imposed hierarchial nature, because it scans in the wrong
direction.

Gary KE4ZV

***  I'd sure like to clear this up ... ***    IT DOESN'T SCAN
LEFT TO RIGHT ***  Have posted this fact to the bbs net many
many times, ***  but someone out there keeps claiming it does
... ***  If you really do have a solution, please post details,
can implement ***  solution rather quickly, if you have one.
Please describe how the ***  various tables would look for some
example cases.  i.e.  I'm not going ***  to do  *ALL*  the work
myself ... include samples of init.mb, fwd.mb, ***  and
config.mb  ... I assume you know my code well, since you claim
***  to understand how it operates.

Date: 9 Aug 91 09:21:23 GMT From:
cis.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pi
tt!w2xo![e-mail] Subject: 'NA' country domain
appears to be non-unique To: [e-mail]

Gentlemen,

I , as a very minor bbs software author have had huge problems
in the past getting info about what is really going on in the
pbbs world.

I see W0RLI, AA4RE and VE3GYQ ,to name three, on here and
presenting more verbage than I've ever seen from them.

How about, if not a rec.radio.amateur.pbbs, at least a mailing
list for pbbs stuff? I know about several others like me who
have their own pbbs software ( because they wanted to do
something that the RLI/4RE/MBL stuff wasn't designed for, like
run in a unix environment) who would greatly benefit from
knowing what the latest "whiz-bang" feature is that's going to
make us incompatible with the pbbs network *this* week 8-) .

I guess we have to do more educating, like some suggest. One
facet of education is information, and there has been almost no
flow of same regarding the pbbs net. It seems that a lot of the
present confusion and flame-throwing were initially caused by
lack of education/information among internet folks who weren't
aware that packet radio addresses were different and should not
be used on internet !

To perhaps better summarize: 1. There is no flow of information
pbbsnet->internet. 2. There is no flow of information
internet->pbbsnet. 3. There is no flow of information concerning
pbbs software design.

Can we fix this?Jim, W2XO

***  Let's do it on the bbs net.  I don't usually have time at
work to ***  play ham radio, and can only read/post now and
then, when workload ***  is a bit slack.

|> Hank: are you listening?

     I'm sure he is.  |> Marc Kaufman ([e-mail])

***  Yup!  Listening ... most of the time ... just not talking
***  very often (see above).

ok.  here's my final question, which can also be taken as a
suggestion. if I want to send mail, for example, to friends back
in Aggieland on a machine that is on BITNET from Internet, I
would address it to [e-mail] --- notice the
.bitnet?  (yeah, I know....VENUS is also on the Internet...but
it's habit now.)

so, why can't we simply register something like '.packet' with
the NIC, and put all this nonsense to bed?  then, make sure
people know that if they want to mis-use .NA and call it North
America, they must also use the .packet to let the system know
it is for a foreign network.  now, I must admit that mail is not
my strongest area --- sendmail.cf still scares the sh_t out of
me, but it seems obvious that this is a solution to this, and
will help in any attempts to interconnect the lot.

my packet address might then look like
[e-mail] or something like that.  the gateway
machines (if there are any) could then say ``hmmmm....he's a
.packet, and is in ill. --- he must therefore be in
.usa.na.earth.western_spiral_arm.milky_way.universe'' or
whatever it wants.  who cares --- from that point, it would be
leaving the Internet machines alone.  but while on the Internet,
it would conform to standards. the gateway machine has the
smarts.

likewise, if I sent mail (mind you, this all assumes that such a
gateway exists) from packet to an Internet address in
Nambia,.....

while on packet: >From:
[e-mail]_spiral_arm.milky_way.uni
verse >To: [e-mail]

once on the Internet: >From: [e-mail] >To:
[e-mail]

so what's the problem?

oh, people would have to be sure that their .signature clearly
points out that their address is in .packet.

   --jim

Standard disclaimer....These thoughts are mine, not my
employer's.

-----------------------------------------------------------------
------------Share and Enjoy!  (Sirius Cybernetics Corporation,
complaints division) 73, de n5ial

Internet:  [e-mail]  (- or -)  [e-mail]
Amateur Radio:   TCP/IP:    [e-mail] (44.72.47.193)
Packet:    n5ial@wb9yae    (Chicago, IL, US)

***  This looks like it makes a lot of sense. ***  We already
have ".ampr.org" ...  ***  The gateways could take care of the
details automatically ... ***  perhaps without much difficulty.

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 12 Aug 91 22:34:29 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

Rather than let this drop, lets take irony in hand and explore a
bit:

Ok ... now everyone has had a chance to hack at this topic, I
have this one kinda strange question ... how come internet has
no top level geographic domain specification?  If internet
addresses were things like mumble.NA.AF then the problem would
not have occured ... seems to me the problem occurs because
internet has fewer layers in it's domain hierarchy than the bbs
net.                                                 In fact, if
internet were to simply add that top level (continental) domain
name, then the problem would never occur, since Namibia would be
mumble.NA.AF on the internet, and mumble.NAM.AF on bbs net.
This would be much simpler than making a similar change in the
bbs net, as the internet has standards and an organization to
disseminate them.  The bbs net has neither.

Of course, if both networks chose the SAME standards, then there
would never be a problem ... or would there ?

It sure has been nice to see the educational information posted
to rec.radio.amateur.* and other appropriate places ... oh wait
... time warp .. those postings have not occured yet !

Come  *ON*   someone!  Plenty of folks to complain about the
problem ... but nobody to explain the solution ?

And ... suddenly I get the digest as well as the originals. I
did  *NOT*  sign up to get the digest.  I get the whole thing
already. Whoever signed me up, please un-sign-me-up forthwith.
It's wasting bandwidth.

   ...  Hank--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 13 Aug 91 00:55:46 GMT From:
agate!stanford.edu!neon.Stanford.EDU![e-mail]
Subject: 'NA' country domain appears to be non-unique To:
[e-mail]

[e-mail] writes:

>Rather than let this drop, lets take irony in hand and explore
a bit:

>Ok ... now everyone has had a chance to hack at this topic, I
have this >one kinda strange question ... how come internet has
no top level geographic >domain specification?  If internet
addresses were things like mumble.NA.AF >then the problem would
not have occured ... seems to me the problem occurs >because
internet has fewer layers in it's domain hierarchy than the bbs
net.

All together now, in chorus: in the Internet, NAMES ARE NOT
ROUTES. Names are names, that's all.  Domains are administrative
units, NOT geographic units.  ".edu" generally means a
university, WHEREVER it may be.  ".com" generally means a
commercial enterprise.  There are servers that can tell you how
to route to any name.

Country codes as domains usually occur only for very small
countries, where everyone in the country (using that domain)
uses a common server for routing information.  There is no
reason in particular why some .com or .edu addresses could not
exist in Namibia.
 >In fact, if internet were to simply add that top level
(continental) domain >name, then the problem would never occur,
since Namibia would be mumble.NA.AF >on the internet, and
mumble.NAM.AF on bbs net.  This would be much simpler >than
making a similar change in the bbs net, as the internet has
standards >and an organization to disseminate them.  The bbs net
has neither.

The only reason to add a domain of the form ".AF", would be if
someone wanted to coordinate addresses and routing for all of
Africa, which I doubt. If the bbs net does not have standards,
how come everyone uses ".USA.NA" in the continental US?

>Of course, if both networks chose the SAME standards, then
there would never >be a problem ... or would there ?

There might be less problem.  Now, since bbsnet has maybe 10K
nodes and 100K users worldwide, perhaps it should be the one to
adopt the Internet standards, since there are 100'sK nodes
worldwide, and established gateways to other networks of
comparable size.

>It sure has been nice to see the educational information posted
to >rec.radio.amateur.* and other appropriate places ... oh wait
... time warp .. >those postings have not occured yet !

Au contraire.  You just haven't been reading the groups long
enough.

>Come  *ON*   someone!  Plenty of folks to complain about the
problem ... >but nobody to explain the solution ?

Repeat after me: NAMES ARE NOT ROUTES.

>   ...  Hank >Hank Oredson @ Mentor Graphics >Internet     :
[e-mail] >Amateur Radio: [e-mail]

If I accidently fire your AR address on the Internet, the
mailers will say: Gee, I don't know how to route that, lets ask
the domain server for the ".NA" domain.  It would be preferable
for your address to be something like: W0RLI@W0RLI:OR:USA:NA, so
an Internet mailer would say:  Gee, that's not an Internet
address.  Let's tell the user rather than send it somewhere
strange.

Even adding ".ax25" would be an improvement, as long as you
ALWAYS advertised your address as: [e-mail]25 so
that Internet mailers would never be able to match the last
component as a valid domain name.

The name spaces should be disjoint.  Names are not routes.

Marc Kaufman, WB6ECE, ([e-mail]) Names are not
routes.

------------------------------

Date: 13 Aug 91 02:17:56 GMT From:
munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!avari
ce.teaching.cs.adelaide.edu.au![e-mail] Subject:
'NA' country domain appears to be non-unique To:
[e-mail]

There has been quite a number of suggestions as to what to do
about  this problem. Suggestions seen have included,

1.  Adding a "Domain" or "Network" or whatever you like to call
it name     to the existing Amateur BBS addresses. (suggestions
seen include    BBSNET, FWDNET, AX25BBS, AMPR.ORG).

2.  Getting the BBS Net to change its addresses to the 4 Letter
continent    designators and have these registered with the
Internet (On this point    could some kind soul post the 4
letter proposal to the network or at    least EMail me a copy?)
A question I have here is, what is involved    with registering
these 4 letter designators? Are there any costs?

3.  Getting the BBS addresses to change the separator from a "."
to a ":"

4.  Educate the users not to use addresses incorrectly.

5.  Develop accepted Gateway practices to handle the differences
between    the two networks.

All seem quite good ideas, of these I tend to favour 2, 4 and 5
collectively but am still undecided.

Someone noted that addresses like  *.UUCP and *.BITNET are not
actually domains. But they appear to be effective, why not
implement something like  that? Or use the 4 letter designators.
In some ways the 4 letter scheme could work better as although
the Internet is Domian and name based I cant see why a location
couldnt be specified and have internet mailers direct the
various 4 letter designators to respective mail gateways in
respective areas. As far as the Internet would be concerned
wouldnt they just be considered as domain indicators that just
have a relevent network attached  in one particular part of the
Internet? Here in Australia we have the top  level domain of AU
on the Internet (AARNet), mail for *.AU doesnt get  sent to
Europe, it gets sent to Australia, similarly if things like
NOAM,  CEAM and the other ones which I havent seen could
indicate which region of the globe to point the particular
gatewayed mail wouldnt that help the problem (and make gatewayed
mail simpler so that say gatewayed mail didnt get dropped to the
BBS net in the Middle of the US somewhere that was destined for
Europe or Australia)?

(I just noticed that if the original BBS Addresses for Australia
of  state.AUS.AU had been implemented that the problem of
Namibia would have cropped up a lot sooner (without the cost
problem though) as *.AU is the top level domain here!, instead
we actually use state.AUS.OC (OC= Oceania, South Pacific , New
Zealand, Australia).)

Anyway I guess the bottom line is while we are arguing about
this nothing is actually being done. I personally havent decided
what I think would be the best way to go, I would like to see
the proposal for the 4 letter designators and then take it from
there.

Constructive Comments/Critisim welcome... flames > /dev/null

Cheers de Grant VK5ZWI--

Grant Willis (VK5ZWI), Electronic Engineering Student. |
Adelaide University AARNet/Internet1:
[e-mail]        | South AUSTRALIA
AARNet/Internet2: [e-mail] | My
views are my own, AmPRNET: VK5ZWI@VK5TTY.#SA.AUS.OC
[44.136.171.11]     | not the Uni's!

------------------------------

Date: 13 Aug 91 02:28:46 GMT From:
pa.dec.com!jrdzzz.jrd.dec.com![e-mail] Subject:
'NA' country domain appears to be non-unique To:
[e-mail]

>All together now, in chorus: in the Internet, NAMES ARE NOT
ROUTES. >Names are names, that's all.

Names are not routes nor networks. Multiple networks can reside
in a same domain.

>There is no reason in particular why some .com or .edu
>addresses could not exist in Namibia.

And there is no reason in particular why some .jp domain
addresses should not exist in the USA or Namibia or anywhere
outside Japan, as long as the name is legitimately (i.e.
registered in Internet DNS) resolvable.
                       >Repeat after me: NAMES ARE NOT ROUTES.

And names are not networks.

>Even adding ".ax25" would be an improvement, as long as you
ALWAYS advertised >your address as: [e-mail]25
so that Internet mailers would >never be able to match the last
component as a valid domain name.

I propose to add a pseudo top domain (like .BITNET for BITNET).
.AX25 is not bad, although I don't like it because it is a
protocol name, not a network name.

>The name spaces should be disjoint.  Names are not routes.--

Kenji Rikitake // Views expressed in this message are solely of
my own. Office: [e-mail] / Home:
[e-mail]

------------------------------

Date: 13 Aug 91 03:02:10 GMT From:
uhccux!uhunix1.uhcc.Hawaii.Edu![e-mail] Subject: 'NA'
country domain appears to be non-unique To: [e-mail]

In article <[e-mail]>
[e-mail] writes: >Ok ... now everyone has had a
chance to hack at this topic, I have this >one kinda strange
question ... how come internet has no top level geographic
>domain specification?  If internet addresses were things like
mumble.NA.AF >then the problem would not have occured ... seems
to me the problem occurs >because internet has fewer layers in
it's domain hierarchy than the bbs net.

Haven't we been through this before?  Internet host addresses
are not tied to routes.  They are related to organizational
structures.  Sometimes those organizational structures happen to
coincide with geographical boundaries and  the top level domain
names are chosen to match the geographical area.

-Antonio Querubin   [e-mail] /
[e-mail] / [e-mail]

------------------------------

Date: 13 Aug 91 04:25:54 GMT From: [e-mail] Subject: 'NA'
country domain appears to be non-unique To: [e-mail]

In article <[e-mail]>
[e-mail] (Grant Willis VK5ZWI) writes:
>There has [sic] been quite a number of suggestions as to what
to do about  >this problem. Suggestions seen have included,

>1.  Adding a "Domain" or "Network" or whatever you like to call
it name  >    to the existing Amateur BBS addresses.
(suggestions seen include >    BBSNET, FWDNET, AX25BBS,
AMPR.ORG).

The addresses on the packet radio network are already too long
and already contain redundant information.  No need to make them
longer. Certainly you don't want to add an internet domain name
to a geographical route.

>2.  Getting the BBS Net to change its addresses to the 4 Letter
continent >    designators and have these registered with the
Internet (On this point >    could some kind soul post the 4
letter proposal to the network or at >    least EMail me a
copy?) A question I have here is, what is involved >    with
registering these 4 letter designators? Are there any costs?

I sincerely doubt that the internet would be willing to register
a geographical routing hint as a top-level domain, since names
are not routes.

But wait!  You'll have to change the bbs software!  After all,
it understands '.NA' now, not '.NOAM' or '.MOON'.

>3.  Getting the BBS addresses to change the separator from a
"." to a ":"

Hmm.  You'd have to change the software for this one too.  It
would be a nice clean change, though.

>4.  Educate the users not to use addresses incorrectly.

Hah.  Good one.  Easier to herd cats.

>5.  Develop accepted Gateway practices to handle the
differences between >    the two networks.

Gateways don't matter here; it's user misuse.  The gatewaying
problem is already solved, should we care to ever do it.

- Brian

------------------------------

Date: 13 Aug 91 00:10:01 GMT From:
olivea!tardis![e-mail] Subject: 2 memberships to Chicon
(WorldCon-91) for sale. To: [e-mail]

A friend of mine has two memberships to Chicon-V (the 49th World
Science Fiction Convention) for sale.  The Con is 29-Aug through
2-Sep-91 at the Hyatt Regency in Chicago.

The current price for membership is $150.  Michael Rightor is
asking $125 each for two Attending Memberships.  Call him at
[phone]; leave a message on the machine. [If you think
you've seen this message before, you have.  I had to repost with
the correct area-code for Michael's phone number.]

--  Joe Smith [phone] | SMTP: [e-mail] or
[e-mail] BT Tymnet Tech Services | UUCP:
...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C51
  | BIX: smithjoe | CA license plate: "POPJ P," (PDP-10) San
Jose, CA 95161-9019 | humorous disclaimer: "My Amiga 3000 speaks
for me."

------------------------------

Date: 12 Aug 91 19:26:12 GMT From:
orion.oac.uci.edu!ucivax!jarthur!nntp-server.caltech.edu!gmc@ucsd
.edu Subject: KA9Q and Turbo C++ To: [e-mail]

In <[e-mail]> [e-mail] writes:

>I have been trying to compile KA9Q with Turbo C++ (2.0) and the
executable >seems to be larger than the one that is compiled
with Turbo C, not only that >it doesn't work!   Does anyone know
if there is a patch for KA9Q for Turbo  >C++....and how do I
contact Phil Karn? >  >Thanks, >John

I have recently discovered that there is indeed a bug involving
switch statements in Borland C++ 2.0.  Use compiler option -G-
or #pragma option -G-  on modules that have switch statements.

Greg

------------------------------

Date: 12 Aug 91 16:11:27 GMT From:
sdd.hp.com!think.com!news![e-mail] Subject: The great .NA
controversy.... To: [e-mail]

In article <[e-mail]>
[e-mail] (Paul W. Totten) writes:

   This idea makes sense.  If you look at the way that several
other    networks (uucp, bitnet) gateway with Internet, this is
exactly   what they do.  For example, if I want to send mail
from my node   (on Internet) to uunet which lives on the uucp
network, I would   address my mail to: [e-mail]
Similarly, if I want to   send mail to someone at the University
of Ottawa, which lives on   bitnet, I would address it to:
[e-mail]   The ".ax25bbs" (".bitnet", ".uucp")
implies the existance of an    Internet domain of that name,
which is used to route the message   to the appropriate gateway.

Actually it doesn't.  There is no UUCP or BITNET domain; your
site probably has it's mailer hacked up to fake it (I did the
same with ours).  There was a very large amount of discussion
about this back when the domain system was starting up.  Domains
are explicitly not supposed to be topologically or
geographically based, they are administratively based.  In other
words, there must be a responsible party for the things in the
domain.  There is no such entity for UUCP, and I would guess
there isn't for BITNET.

There is a NET domain (seemed to be a kludge, but it lives) for
network organizations themselves.  E.g., UU.NET, NSF.NET,
CS.NET, NEAR.NET, .... There is the domain UU.NET for the UUNET
organization.  These domains are used for the network
facilities, not the "member organizations" attached to the
network.  For example, we are on NEARNET, but that doesn't put
us in the "NEAR.NET" domain; we are commercial, so we are in the
COM domain. However, the gateway box we have on-site here is in
the NEAR.NET domain. Again, domains names are not based on
routing.

The hard part is how to gather up the many individuals and give
them a domain.  The current thought is to do it by
country/state/town, since our government is the closest thing to
"administrative control" we can come up with.  Unfortunately,
that means that one's personal domainname would change when one
moves, but the alternative would be a *huge* flat namespace
under "US" or whatever.

   Now, I'll admit that there are other addresses which I could
use   to get the mail to the sames places (eg: ulaval.bitnet is
the same   as vm1.ulaval.ca -- routing will take care of things,
since Laval   has a node on each network), but you get the point.

VM1.ULAVAL.CA is a domain name.  ULAVAL.BITNET isn't; it is
routing advice (which happens to look like a domain) you are
giving your mailer.

---Bruce Walker  Thinking Machines Corp., Cambridge, MA
[e-mail]; [phone]; WT1M

------------------------------

Date: 12 Aug 91 12:10:29 GMT From:
usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upe
nn.edu!uofs!vulture.cs.uofs.edu![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>, <skcm.681698325@ise>
Subject : Re: 'NA' country domain appears to be non-unique

Let me try this one more time as I didn't see any real comments
the last time.

I agree that changing the separator in the name/routing
designator is a bad idea.

I think the easiest and most effective solution would be to
change the Continent designators to 4 letters.  To the best of
my knowledge, there are currently no 4 letter top level domains
in the Internet so uniqueness should be gauranteed. Requesting
ISO and INTERNET sanction for these should gaurantee that they
will remain unique in the future.

Can anyone give me a real good reason why this can't/shouldn't
be done??

I believe that even though it appears to be impossible now, at
some time in  the future, when political factions begin to
realize that this isn't the 1920's, the Amateur Packet System
will be connected to the rest of the world.  We can't keep our
heads in the sand forever.

bill   KB3YV--

     Bill Gunshannon          |        If this statement wasn't
here,     [e-mail]   |  This space would be left
intentionally blank     [e-mail]    |
#include <std.disclaimer.h>

------------------------------

Date: 12 Aug 91 22:24:15 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!ccml@uune
t.uu.net To: [e-mail]

References <[e-mail]>,
<skcm.681698325@ise>, <[e-mail]> Subject :
Re: 'NA' country domain appears to be non-unique

In <[e-mail]> [e-mail] (Bill
Gunshannon) writes:

>Let me try this one more time as I didn't see any real comments
the last time.

>I agree that changing the separator in the name/routing
designator is a bad idea.

>I think the easiest and most effective solution would be to
change the Continent >designators to 4 letters.  To the best of
my knowledge, there are currently no >4 letter top level domains
in the Internet so uniqueness should be gauranteed. >Requesting
ISO and INTERNET sanction for these should gaurantee that they
>will remain unique in the future.

>Can anyone give me a real good reason why this can't/shouldn't
be done??

No reason at all, except that of a sceptic like me who says that
this solution is so obvious that it will fall by the wayside.
Problem is, folk are looking at deep technical gateway theories,
and have not had the clarity to see the problem as you do.

If .NOAM is used, and gets registered as top level domain, and
the .NA nameserver gives a CNAME for *.USA.NA -> *.USA.NOAM,
then hopefully things will sort themselves out over time.

Mike--

Mike Lawrie Director Computing Services, Rhodes University,
South Africa
.....................<[e-mail]>.......................
... Rhodes University condemns racism and racial segregation

------------------------------

End of Packet-Radio Digest V91 #205
****************************** Date: Wed, 14 Aug 91 04:30:06 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #206 To: packet-radio

Packet-Radio Digest         Wed, 14 Aug 91       Volume 91 :
Issue 206

Today's Topics:        'NA' country domain appears to be
non-unique (11 msgs)                               16550AFN
                  AX.25 Protocol Specs.              Help
Locating Ver. 3.5 of MBBIOS (2 msgs)                       help
with ka9q - again..                  Poor Man's Packet Update:
PMP 1.1                Possible solutions for the .NA problem
                   Reception-Manhattan, NYC

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 13 Aug 91 15:03:58 GMT From: timbuk![e-mail]
Subject: 'NA' country domain appears to be non-unique To:
[e-mail]

In article <[e-mail]>,
[e-mail] writes: > [...] > ***  Let's do it on
the bbs net.  I don't usually have time at work to > ***  play
ham radio, and can only read/post now and then, when workload >
***  is a bit slack. > [...]

This should slow the whole controversy down - make it more of a
test of patience :-) :-)

            ^^^^^^^

-andyw.    (W0/G1XRL)

[e-mail]    Andy Warner, Cray Research, Inc.    (612)
683-5835

------------------------------

Date: 13 Aug 91 16:50:16 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

My comments with ***

   ...  Hank

From: [e-mail] (Bill Gunshannon) Newsgroups:
rec.radio.amateur.packet Subject: Re: 'NA' country domain
appears to be non-unique Message-ID:
<[e-mail]> Date: 12 Aug 91 12:10:29 GMT

Let me try this one more time as I didn't see any real comments
the last time.

I agree that changing the separator in the name/routing
designator is a bad idea.

I think the easiest and most effective solution would be to
change the Continent designators to 4 letters.  To the best of
my knowledge, there are currently no 4 letter top level domains
in the Internet so uniqueness should be gauranteed. Requesting
ISO and INTERNET sanction for these should gaurantee that they
will remain unique in the future.

Can anyone give me a real good reason why this can't/shouldn't
be done??

I believe that even though it appears to be impossible now, at
some time in  the future, when political factions begin to
realize that this isn't the 1920's, the Amateur Packet System
will be connected to the rest of the world.  We can't keep our
heads in the sand forever.

bill   KB3YV--

     Bill Gunshannon          |        If this statement wasn't
here,     [e-mail]   |  This space would be left
intentionally blank     [e-mail]    |
#include <std.disclaimer.h>

***  Thank you very much, Bill, we need volunteers to handle
things like this. ***  Please let us (bbs authors) and them
(packet bbs sysops) and the others ***  (packet bbs users) know
what the new list of continent designators is. ***  Once you
have submitted them and obtained sanction for them, the whole
***  problem should then go away. *** ***  Of course it will
take a little time for the packet bbs network to adopt ***  the
new designators, but that's the way life is ...

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 13 Aug 91 18:42:33 GMT From:
mvb.saic.com!unogate!orion.oac.uci.edu!usc!cs.utexas.edu!helios!c
s.tamu.edu![e-mail] Subject: 'NA' country domain appears to
be non-unique To: [e-mail]

In article <[e-mail]>, [e-mail] (Brian Kantor)
writes: |>  |> But wait!  You'll have to change the bbs
software!  After all, it |> understands '.NA' now, not '.NOAM'
or '.MOON'.

     Actually, no, that is data driven.

|> >3.  Getting the BBS addresses to change the separator from a
"." to a ":" |>  |> Hmm.  You'd have to change the software for
this one too.  It would be a |> nice clean change, though.

  No, then some idiot would use the address on banyanmail or
VAXmail and  we'd have the same problem.  or does Nambia have
the good taste not to use  VAXen? 8-} --  Kurt Freiberger,
wb5bbw      [e-mail]   409/847-8607  fax:[phone] Dept.
of Computer Science, Texas A&M University      DoD #264: BMW
R80/7 pilot "We preserve our freedom using three boxes: ballot,
jury, and cartridge."      *** Not an official document of Texas
A&M University ***

------------------------------

Date: 13 Aug 91 18:46:12 GMT From:
mvb.saic.com!unogate!orion.oac.uci.edu!usc!cs.utexas.edu!helios!c
s.tamu.edu![e-mail] Subject: 'NA' country domain appears to
be non-unique To: [e-mail]

In article <[e-mail]>, [e-mail]
(Andy Warner) writes: |>  |> In article
<[e-mail]>,
[e-mail] writes: |> > [...] |> > ***  Let's do
it on the bbs net.  I don't usually have time at work to |> >
***  play ham radio, and can only read/post now and then, when
workload |> > ***  is a bit slack. |> > [...] |>  |> This should
slow the whole controversy down - make it more of a test |> of
patience :-) :-) |>

    "The ox is slow, but the earth is patient."

            - Unknown Tibetan monk,

                "High Road to China"

    8-}

--  Kurt Freiberger, wb5bbw      [e-mail]   409/847-8607
fax:[phone] Dept. of Computer Science, Texas A&M University
     DoD #264: BMW R80/7 pilot "We preserve our freedom using
three boxes: ballot, jury, and cartridge."      *** Not an
official document of Texas A&M University ***

------------------------------

Date: 13 Aug 91 17:26:36 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

My comments with *** Some excellent ideas ... Just a couple nits
to pick ...

   ...  Hank

From: [e-mail] (Brian Kantor) Newsgroups:
rec.radio.amateur.packet Subject: Re: 'NA' country domain
appears to be non-unique Message-ID: <[e-mail]> Date: 13
Aug 91 04:25:54 GMT References:
<[e-mail]> Organization: The Avant-Garde
of the Now, Ltd.

In article <[e-mail]>
[e-mail] (Grant Willis VK5ZWI) writes:
>There has [sic] been quite a number of suggestions as to what
to do about  >this problem. Suggestions seen have included,

>1.  Adding a "Domain" or "Network" or whatever you like to call
it name  >    to the existing Amateur BBS addresses.
(suggestions seen include >    BBSNET, FWDNET, AX25BBS,
AMPR.ORG).

The addresses on the packet radio network are already too long
and already contain redundant information.  No need to make them
longer. Certainly you don't want to add an internet domain name
to a geographical route.

***  Agree.  Small nit: it's a hierarchical LOCATION, not a
ROUTE. ***  That is, it describes where the server is located,
but does not ***  describe how to get there.  That is why I've
called it "routing ***  hints" as opposed to "routing" ...

>2.  Getting the BBS Net to change its addresses to the 4 Letter
continent >    designators and have these registered with the
Internet (On this point >    could some kind soul post the 4
letter proposal to the network or at >    least EMail me a
copy?) A question I have here is, what is involved >    with
registering these 4 letter designators? Are there any costs?

I sincerely doubt that the internet would be willing to register
a geographical routing hint as a top-level domain, since names
are not routes.

But wait!  You'll have to change the bbs software!  After all,
it understands '.NA' now, not '.NOAM' or '.MOON'.

***  No, the software does not understand any particular set of
characters. ***  This is totally configurable.  Nothing to
change except some entries ***  in a runtime configuration file.
***  However ... see 4. below.  We would still have to "herd the
cats".

>3.  Getting the BBS addresses to change the separator from a
"." to a ":"

Hmm.  You'd have to change the software for this one too.  It
would be a nice clean change, though.

***  Yes, the software would have to change, and also be
backward compatible. ***  Not a big problem, were it desirable.

>4.  Educate the users not to use addresses incorrectly.

Hah.  Good one.  Easier to herd cats.

***  Yup.  MUCH easier.

>5.  Develop accepted Gateway practices to handle the
differences between >    the two networks.

Gateways don't matter here; it's user misuse.  The gatewaying
problem is already solved, should we care to ever do it.

- Brian

***  I'm not convinced the gateways are really ok, but have not
seen ***  problems that are obvoius "gateway problems" ...

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 13 Aug 91 17:35:53 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

My comments with *** Some more good ideas. A few nits to pick
...                        ...  Hank

From: [e-mail] (Ran Atkinson) Newsgroups:
rec.radio.amateur.packet Subject: Possible solutions for the .NA
problem Message-ID:
<[e-mail]> Date: 13 Aug
91 12:52:46 GMT References:
<[e-mail]> Sender:
[e-mail]

In article <[e-mail]>
[e-mail] writes: >how come internet has no top
level geographic domain specification?

It does.  The ISO two-letter country codes.  No additional
information is needed for routing because a tiny lookup table
(one that will easily fit with the other software on a 256K 4
MHz PC) is sufficient for routing.

  Also, their routing isn't really geographically based.  For
example, GE sites in Europe have a US GE site as their gateway
-- even if the original traffic originates at a non-GE site in
for example the UK it must go to the US before being sent to the
recipient European GE site.

>This would be much simpler than making a similar change in the
bbs net...

Not hardly.

  There are probably 100 times more sites on the Internet than
on the bbs net (making the scale of the change a whole lot
larger) and there is no mechanism to enforce Internet standards
on the Internet so there would be no possible way of making a
smooth transition.  Additionally, they don't need any such
change.

***  I still think it would be simpler.  There are mechanisms in
place ***  to notify sys admins of the changes, to disseminate
information ***  about the changes, etc.  This mechanism is not
yet in place in ***  the bbs net ...

>It sure has been nice to see the educational information posted
to >rec.radio.amateur.* and other appropriate places ... oh wait
... time warp .. >those postings have not occured yet !

This is really harsh.

  I emailed you how to get the full set of Internet standards
and received an email reply from you which confirmed that you
got my informative email.  The whole text of all Internet
standards is far too large to post to the net under the USENET
rules.

***  And I thank you.  Have attempted to retrieve one, to see if
***  the system works.  Have no response yet. ***  It was not
intended to be harsh, just sarcastic.  It was not ***  pointed
at any particular person.  There has been lots of ***
discussion of the 'probolem', but as of yet, little educational
***  material distributed to the PDU.

>but nobody to explain the solution ?

I have repeatedly explained at least a couple of solutions and
others have as well.

  Drop continents and add a tiny routing lookup table OR replace
them with 4 country codes.

***  But who have you explained them to?  Please please send
this kind ***  of information out into the bbs net ! ***  Not a
"tiny" lookup table.  LOTS more than the (typical) ***  order of
2-3 k bytes currently required. ***  Nothing required of the
code though, it already would handle ***  things this way if
people chose to.

  Also, get Amateurs participating in the PBBSnet to clearly
mark the difference between their Internet address and their
Amateur Radio PBBS address in their .signature files in postings
and in email sent over the Internet.  Such a suggestion could
easily be placed in future releases of the PBBS software and
prevent future problems.

***  Ok ... send me the file, I'll include it in future releases
of my code.

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 13 Aug 91 17:18:06 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

My comments with ***

The idea of making the name spaces disjoint is a good one. We
thought we had.  Internet broke what we had done. Nobody
volunteered to coordinate with internet, thus the coordination
was not done.

   ...  Hank

Newsgroups: rec.radio.amateur.packet From:
[e-mail] (Marc T. Kaufman) Subject: Re: 'NA'
country domain appears to be non-unique Message-ID:
<[e-mail]> Organization: Computer
Science Department, Stanford University, Ca , USA References:
<[e-mail]>

>Rather than let this drop, lets take irony in hand and explore
a bit:

>Ok ... now everyone has had a chance to hack at this topic, I
have this >one kinda strange question ... how come internet has
no top level geographic >domain specification?  If internet
addresses were things like mumble.NA.AF >then the problem would
not have occured ... seems to me the problem occurs >because
internet has fewer layers in it's domain hierarchy than the bbs
net.

All together now, in chorus: in the Internet, NAMES ARE NOT
ROUTES. Names are names, that's all.  Domains are administrative
units, NOT geographic units.  ".edu" generally means a
university, WHEREVER it may be.  ".com" generally means a
commercial enterprise.  There are servers that can tell you how
to route to any name.

***  Names are not routes, routes are not locations, et al. ***
Domains are not "administrative units" in all (or even the most
***  common) cases.  Perhaps something else unique to internet.
***  Yeah, we all know this.  However (and there is always a
however), ***  names are frequently chosen in some mnemonic
manner to make it ***  simple for humans to deal with them.
e.g. "STANFORD.EDU" and ***  "kaufman" for example.  Ditto the
bbs net hierarchical location ***  identifiers.  They look like
a location for a reason ...

Country codes as domains usually occur only for very small
countries, where everyone in the country (using that domain)
uses a common server for routing information.  There is no
reason in particular why some .com or .edu addresses could not
exist in Namibia.

***  "usually" ... you mean "usual, in the internet"? ***  In
two other common examples (telephone and post office) they ***
occur at any time the information must cross a geopolitcal
boundary.                                                 >In
fact, if internet were to simply add that top level
(continental) domain >name, then the problem would never occur,
since Namibia would be mumble.NA.AF >on the internet, and
mumble.NAM.AF on bbs net.  This would be much simpler >than
making a similar change in the bbs net, as the internet has
standards >and an organization to disseminate them.  The bbs net
has neither.

The only reason to add a domain of the form ".AF", would be if
someone wanted to coordinate addresses and routing for all of
Africa, which I doubt. If the bbs net does not have standards,
how come everyone uses ".USA.NA" in the continental US?

>Of course, if both networks chose the SAME standards, then
there would never >be a problem ... or would there ?

There might be less problem.  Now, since bbsnet has maybe 10K
nodes and 100K users worldwide, perhaps it should be the one to
adopt the Internet standards, since there are 100'sK nodes
worldwide, and established gateways to other networks of
comparable size.

***  I suspect there would be a great deal MORE problem ... ***
Think it through carefully ...

>It sure has been nice to see the educational information posted
to >rec.radio.amateur.* and other appropriate places ... oh wait
... time warp .. >those postings have not occured yet !

Au contraire.  You just haven't been reading the groups long
enough.

***  When did this information appear? ***  I've been reading
for about 10 years ... but have only recently ***  acquired the
ability to post (new job, new location, better ***  internet
access).

>Come  *ON*   someone!  Plenty of folks to complain about the
problem ... >but nobody to explain the solution ?

Repeat after me: NAMES ARE NOT ROUTES.

***  Lessee now ... WHO are you quoting here? ***  Might be most
interesting to discover the attribution. ***  The actual quote
is (approx, it was a long time ago) ***  "A location is not a
route." ***  and one could add "... and a name is neither".

>   ...  Hank >Hank Oredson @ Mentor Graphics >Internet     :
[e-mail] >Amateur Radio: [e-mail]

If I accidently fire your AR address on the Internet, the
mailers will say: Gee, I don't know how to route that, lets ask
the domain server for the ".NA" domain.  It would be preferable
for your address to be something like: W0RLI@W0RLI:OR:USA:NA, so
an Internet mailer would say:  Gee, that's not an Internet
address.  Let's tell the user rather than send it somewhere
strange.

Even adding ".ax25" would be an improvement, as long as you
ALWAYS advertised your address as: [e-mail]25 so
that Internet mailers would never be able to match the last
component as a valid domain name.

The name spaces should be disjoint.  Names are not routes.

***  Standard set of comments thanking you for volunteering to
administer ***  (or to consult with appropriate bodies which
administer) the name ***  spaces ...

Marc Kaufman, WB6ECE, ([e-mail]) Names are not
routes.

***  Gee Marc ... glad you understand that names are not routes.
 Hope ***  you also understand that they are not locations, etc.
etc. ***  Also hope you understand that names are often USED to
REPRESENT ***  routes or locations or affiliations or domains or
... ***  This is the way it is ...

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 13 Aug 91 17:01:31 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

My comments with ***

(Grab flame thrower from closet ...)

   ...  Hank

From: [e-mail] (Jim Graham) Newsgroups:
rec.radio.amateur.packet Subject: Re: 'NA' country domain
appears to be non-unique Message-ID:
<[e-mail]> Date: 10 Aug 91 15:23:32
GMT References: <[e-mail]>
<[e-mail]>

I've been watching this one on and off, and seeing as how this
nonsense is *** STILL *** going on, I have to ask a few
questions....

then, I'm going to ask/suggest something that may very well help
(and it may not).

none of this is meant as a flame --- please do not interpret it
as such.

In article <[e-mail]>
[e-mail]  writes:

> Well Marc,  we (the bbs authors) await your suggestions. >
What is it we should do?  How should we do that?

as has already been said at least a hundred-thousand times,
follow the accepted standards.  the argument that it doesn't
work is false.  I can see why this screwup might have happened
in the first place --- the bbs software was written in a vacuum.
 at the time, perhaps this was considered ok, since it was
intended to be used that way as well.  now, however, that
assessment is turning out to be wrong.  fine.  you know what
they say, do it right the first time....or you have to spend
twice as much time fixing it later.  guess what.......

*** Ok, sounds good to me. *** So   *WHAT ARE THOSE SUGGESTIONS*
 ? *** " ... follow existing standards ..."  doesn't tell me
squat. *** Please be just a tad more specific, and then  *SEND
ME THOSE STANDARDS* *** Also, send the recommendations on how to
USE those standards within *** the bbs net ...

> While doing that (whatever it is) keep in mind that we > wish
to support only a small number of users (about 100,000) > with
only a small number of servers (about 10,000), and that > those
users will often have *NO* local processing capability.

first, WHO CARES if the users themselves have '*NO* local
processing capability' --- granted, right now, I'm using a pc to
pretend that it's a dumb terminal...but it basically has no say
in the operations of the UNIX machine I'm working from.  does
that prevent me from sending e-mail and posting articles?  no.
it has nothing to do with it.

my dumb pc keeps sending bits to a far-away land.  it knows
nothing of what will happen to those bits, nor does it care.

now, as far as BBSs not having the smarts to do global
routing....WHO CARES? my UNIX machine here (well, there....
:-)) knows nothing about routing mail beyond Amoco computers.
in fact, it sometimes has problems with that (or did, at least).
 it doesn't matter.  when my machine has mail to send that it
doesn't know how to handle, does it just go off into a corner
and sulk? no.  it passes it along to another machine who has
more mail routing information...like how to access non-Amoco
machines.

after my machine sends the mail on to its server machine, that
machine will then look at where the mail is headed, and if it
leaves Amoco, it will pass it along to our Internet mail
gateway, which.......  you get the idea.

so even the local BBSs don't have to know how to route to
everywhere in the world.  all they need to know is where to send
it if they don't know what else to do with it.

> So post some useful ideas please, since it sounds like you >
know what the solutions are.

ok.  here's my final question, which can also be taken as a
suggestion. if I want to send mail, for example, to friends back
in Aggieland on a machine that is on BITNET from Internet, I
would address it to [e-mail] --- notice the
.bitnet?  (yeah, I know....VENUS is also on the Internet...but
it's habit now.)

so, why can't we simply register something like '.packet' with
the NIC, and put all this nonsense to bed?  then, make sure
people know that if they want to mis-use .NA and call it North
America, they must also use the .packet to let the system know
it is for a foreign network.  now, I must admit that mail is not
my strongest area --- sendmail.cf still scares the sh_t out of
me, but it seems obvious that this is a solution to this, and
will help in any attempts to interconnect the lot.

***  Thank you for volunteering to register the "packet" domain
with the ***  NIC (whatever that is ...), we need volunteers
like you to handle ***  these details.  Please let us all know
when that registration has ***  been accomplished, and what the
"top level network domain name" is.

my packet address might then look like
[e-mail] or something like that.  the gateway
machines (if there are any) could then say ``hmmmm....he's a
.packet, and is in ill. --- he must therefore be in
.usa.na.earth.western_spiral_arm.milky_way.universe'' or
whatever it wants.  who cares --- from that point, it would be
leaving the Internet machines alone.  but while on the Internet,
it would conform to standards. the gateway machine has the
smarts.

likewise, if I sent mail (mind you, this all assumes that such a
gateway exists) from packet to an Internet address in
Nambia,.....

while on packet: >From:
[e-mail]_spiral_arm.milky_way.uni
verse >To: [e-mail]

once on the Internet: >From: [e-mail] >To:
[e-mail]

so what's the problem?

***  Thank you for volunteering to author the user documentation
that could ***  be distributed within the internet and the bbs
net to help educate ***  users on these addressing matters.  We
need volunteers like you to ***  create and disseminate this
information !

oh, people would have to be sure that their .signature clearly
points out that their address is in .packet.

***  Thank you for making some suggestions on how people might
structure ***  their signature to help users avoid confusion.
Thank you also for ***  posting this useful information to all
the pertinent news groups !

   --jim

Standard disclaimer....These thoughts are mine, not my
employer's.

-----------------------------------------------------------------
------------Share and Enjoy!  (Sirius Cybernetics Corporation,
complaints division) 73, de n5ial

Internet:  [e-mail]  (- or -)  [e-mail]
Amateur Radio:   TCP/IP:    [e-mail] (44.72.47.193)
Packet:    n5ial@wb9yae    (Chicago, IL,
US)--------------------------------------------------------------
----------------

***  Um ... I'm on tcp/ip here ... of course it's local to this
building ... ***  and that "mumble.ampr.org" didn't work very
well.  Can you give more ***  clues where it might be a useful
address ? ***  (Stuff flame thrower back into closet ...)

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 13 Aug 91 22:16:42 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

Well ... guess this needs explaining again. A location is not a
route. An address is not a location. A name is not an address,
location, or route, although it may be USED as any of them, or
may be mnemonically  related to any of them. Each end user
exists in many (possibly disjoint) domains. e-mail addresses
tend to make use of one or more of those domains.

My comments with ***

  ...  Hank

From: [e-mail] (Antonio Querubin)
Newsgroups: rec.radio.amateur.packet Subject: Re: 'NA' country
domain appears to be non-unique Message-ID:
<[e-mail]> Date: 13 Aug 91 03:02:10 GMT
References: <[e-mail]>
Organization: University of Hawaii

In article <[e-mail]>
[e-mail] writes: >Ok ... now everyone has had a
chance to hack at this topic, I have this >one kinda strange
question ... how come internet has no top level geographic
>domain specification?  If internet addresses were things like
mumble.NA.AF >then the problem would not have occured ... seems
to me the problem occurs >because internet has fewer layers in
it's domain hierarchy than the bbs net.

Haven't we been through this before?  Internet host addresses
are not tied to routes.  They are related to organizational
structures.  Sometimes those organizational structures happen to
coincide with geographical boundaries and  the top level domain
names are chosen to match the geographical area.

***  And why not add a top level domain to those addresses? ***
One example might be ".internet" ... to keep it clear ***
within what domain the name might be interpreted as an ***
e-mail address ...

-Antonio Querubin   [e-mail] /
[e-mail] / [e-mail]

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 13 Aug 91 23:26:32 GMT From:
uvaarpa!murdoch![e-mail] Subject: 'NA' country domain
appears to be non-unique To: [e-mail]

In article <[e-mail]>
[e-mail] writes:

>***  I still think it would be simpler [to change the
Internet].   >***  There are mechanisms in place to notify sys
admins of the changes,  >***  to disseminate information about
the changes, etc.   >*** This mechanism is not yet in place in
the bbs net ...

Experience has shown that Internet changes are EXTREMELY
difficult.

  This is partly due to the size and the autonomous nature of
administration of hosts and subnetworks.  The Internet is a
couple of orders of magnitude larger than the PBBS network in
hosts, nets, and users.

  For example, one part of the Internet is the MILNET and they
still don't use "nameservers" to do address translations or mail
routing lookups despite a conversion plan that "mandated" using
that method by some YEARS AGO.

  It definitely would be easier to change PBBSnet to use either
4 letter continent codes or simply drop continent codes
completely. It couldn't happen overnight, but a phased
transition would be entirely practical.

>  Drop continents and add a tiny routing lookup table OR
replace them >with 4 country codes.  > >***  But who have you
explained them to?  Please please send this kind >***  of
information out into the bbs net !

I've posted 5-6 times here and don't have ready access to post
directly to the PBBSnet myself.

>***  Not a "tiny" lookup table.  LOTS more than the (typical)
>***  order of 2-3 k bytes currently required. >***  Nothing
required of the code though, it already would handle >***
things this way if people chose to.

Not true.

  It can be done in order 3K in C on a PC using Turbo C.
Moreover, it will easily fit within a 256K PC which is
sufficient for it to be widely adopted.  There just aren't that
many countries and continents.

Example text to be added to future PBBS software releases
follows (edit it as it needs to be):

"NOTE:  Internet mail addresses and Amateur Radio PBBSnet
addresses        appear similar to many people.  To avoid
confusion, either        don't show your Internet address on
PBBS traffic and don't        show your PBBSnet address on
Internet traffic OR make it        very clear which is which if
you show both.  This actually        will also help Amateur
Radio folks be good neighbors with        the rest of the world.
 Please note that most computer networks        use packet
technology so just saying "Packet" won't make it
sufficiently clear.

        An example of very clear follows:

            Internet:  [e-mail]

    Amateur Radio:

        PBBSnet: [e-mail]

        AX.25:   (whatever format AX.25 uses here)

"

------------------------------

Date: 13 Aug 91 22:05:40 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

Sounds pretty reasonable to me. I tend to agree that points
2,4,5 would not be hard to implement. My comments with ***

   ...  Hank

From: [e-mail] (Grant Willis VK5ZWI)
Newsgroups: rec.radio.amateur.packet Subject: Re: 'NA' country
domain appears to be non-unique Message-ID:
<[e-mail]> Date: 13 Aug 91 02:17:56 GMT
Organization: The University of Adelaide, South AUSTRALIA There
has been quite a number of suggestions as to what to do about
this problem. Suggestions seen have included,

1.  Adding a "Domain" or "Network" or whatever you like to call
it name     to the existing Amateur BBS addresses. (suggestions
seen include    BBSNET, FWDNET, AX25BBS, AMPR.ORG).

***  I think this might be viable, but hard to convince the
users.

2.  Getting the BBS Net to change its addresses to the 4 Letter
continent    designators and have these registered with the
Internet (On this point    could some kind soul post the 4
letter proposal to the network or at    least EMail me a copy?)
A question I have here is, what is involved    with registering
these 4 letter designators? Are there any costs?

***  The only problem here is supporting the two naming systems
for ***  the transition period, and getting the word out.

3.  Getting the BBS addresses to change the separator from a "."
to a ":"

***  I don't think this really helps, and might be a huge
education problem.

4.  Educate the users not to use addresses incorrectly.

***  Amen !

5.  Develop accepted Gateway practices to handle the differences
between    the two networks.

***  Hello out there gateway folks !  Are you reading this?

All seem quite good ideas, of these I tend to favour 2, 4 and 5
collectively but am still undecided.

Someone noted that addresses like  *.UUCP and *.BITNET are not
actually domains. But they appear to be effective, why not
implement something like  that? Or use the 4 letter designators.
In some ways the 4 letter scheme could work better as although
the Internet is Domian and name based I cant see why a location
couldnt be specified and have internet mailers direct the
various 4 letter designators to respective mail gateways in
respective areas. As far as the Internet would be concerned
wouldnt they just be considered as domain indicators that just
have a relevent network attached  in one particular part of the
Internet? Here in Australia we have the top  level domain of AU
on the Internet (AARNet), mail for *.AU doesnt get  sent to
Europe, it gets sent to Australia, similarly if things like
NOAM,  CEAM and the other ones which I havent seen could
indicate which region of the globe to point the particular
gatewayed mail wouldnt that help the problem (and make gatewayed
mail simpler so that say gatewayed mail didnt get dropped to the
BBS net in the Middle of the US somewhere that was destined for
Europe or Australia)?

(I just noticed that if the original BBS Addresses for Australia
of  state.AUS.AU had been implemented that the problem of
Namibia would have cropped up a lot sooner (without the cost
problem though) as *.AU is the top level domain here!, instead
we actually use state.AUS.OC (OC= Oceania, South Pacific , New
Zealand, Australia).)

Anyway I guess the bottom line is while we are arguing about
this nothing is actually being done. I personally havent decided
what I think would be the best way to go, I would like to see
the proposal for the 4 letter designators and then take it from
there.

***  Second the opinion. ***  Where are those proposals for
continent names? ***  Is there a standard we can refer to?

Constructive Comments/Critisim welcome... flames > /dev/null

Cheers de Grant VK5ZWI--

Grant Willis (VK5ZWI), Electronic Engineering Student. |
Adelaide University AARNet/Internet1:
[e-mail]        | South AUSTRALIA
AARNet/Internet2: [e-mail] | My
views are my own, AmPRNET: VK5ZWI@VK5TTY.#SA.AUS.OC
[44.136.171.11]     | not the Uni's!

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 13 Aug 91 20:57:14 GMT From:
europa.asd.contel.com!noc.sura.net!haven.umd.edu!uvaarpa!cube!new
[e-mail] Subject: 16550AFN To: [e-mail]

Does anyone know of a good, CHEAP source of the 16550AFN uart
chips?  I just   had a lightening strike that took out ALL my
rs232 stuff (I think the EMP got   them) and the best price on
the '550s so far has been $30!  I need at least 4.

Thanks, Jim WA4ONG

------------------------------

Date: 14 Aug 91 05:57:12 GMT From:
stanford.edu!leland.Stanford.EDU![e-mail] Subject:
AX.25 Protocol Specs. To: [e-mail]

Would some kind soul please send me a copy of the AX.25 protocol
 specifications if they exist in electronic form.

I tried using the ax25.tar.Z file found on ucsd.edu, but it
seemed corrupted and has been removed from the ftp directory.

I would greatly appreciate the effort.

73 de KA0TGN,

-Freeman

-Freeman P. Pascal IV       John 3:16 -    For the Lord so loved the
world that [e-mail]        He sent his only begotten
Son, that KA0TGN                    whoever believes in Him should not Jesus is
my LORD.            perish but have everlasting life.

------------------------------

Date: 13 Aug 91 23:22:07 GMT From: [e-mail]
Subject: Help Locating Ver. 3.5 of MBBIOS To:
[e-mail]

1.  A friend has requested my help in locating an anonymous ftp
site for version 3.5 of MBBIOS, a program for managing serial
ports on DOS machines.

Doug MacDonald  W4FH [e-mail]

------------------------------

Date: 14 Aug 91 02:45:34 GMT From: [e-mail]
Subject: Help Locating Ver. 3.5 of MBBIOS To:
[e-mail]

Try tomcat.gsfc.nasa.gov or ucsd.edu.  I think I put it on both.

Roy, AA4RE

------------------------------

Date: 13 Aug 91 15:12:19 GMT From:
walter!salt!sunrise![e-mail] Subject: help
with ka9q - again.. To: [e-mail]

This problem is in conjunction with my previous posting:  I am
intercepting packets and changing some of the information in the
bodies; however, most of the time, the new data packet is
different in length than the original, so at someone's
suggestion, I do a

 ntohtcp... . . . bp=pushdown(bp,newlen); memcpy(bp->data,
newdata, newlen); trim_data(&bp,newlen); bp=htontcp(tcph,bp,&ph);

the packet looks good up till the call to htontcp().  However,
when htontcp calls pushdown() to push down the TCPLEN, the bp
that is returned is incorrect the original data in the bp
becomes junk...  this has something to do with ambufw() I
suspect.  does anyone have any idea why?

as I said, this is in conjunction to an earlier problem - that
of getting the extra cut off segment at the beginning of the
next or subsequent packet bodies.  if I do a
pullup(&bp,NULLCHAR,oldlen) right before the memcpy, I get this
problem

thanks in advance, any help would be appreciated

Tony

------------------------------

Date: 13 Aug 91 22:26:37 GMT From:
theory.TC.Cornell.EDU![e-mail] Subject: Poor
Man's Packet Update:  PMP 1.1 To: [e-mail]

I've made some minor updates to Poor Man's Packet and have
released version 1.1.  If you are happy with 1.0, it is probably
not worth snagging, but here's a summary of changes:

    - bug fixes:  autowrap, machine crashing when left monitoring

  for extended periods of time

- documentation:  all .CFG commands are now documented in
PMP.DOC,

  misc. edits and updates

- source:  misc. cleanup, removed most of the obsolete debugging

  code

PMP 1.1 is available via anonymous FTP from
helios.tn.cornell.edu in /pub:

        pmp11.zip

    pmpsrc11.zip

If you have questions or problems, drop me e-mail.

--  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
=  =  =  =  =  =  = Andrew C. Payne, N8KEI        UUCP:
...!cornell!batcomputer!payne                          INTERNET:
 [e-mail]

------------------------------

Date: 13 Aug 91 12:52:46 GMT From:
uvaarpa!murdoch![e-mail] Subject: Possible solutions for
the .NA problem To: [e-mail]

In article <[e-mail]>
[e-mail] writes: >how come internet has no top
level geographic domain specification?

It does.  The ISO two-letter country codes.  No additional
information is needed for routing because a tiny lookup table
(one that will easily fit with the other software on a 256K 4
MHz PC) is sufficient for routing.

  Also, their routing isn't really geographically based.  For
example, GE sites in Europe have a US GE site as their gateway
-- even if the original traffic originates at a non-GE site in
for example the UK it must go to the US before being sent to the
recipient European GE site.

>This would be much simpler than making a similar change in the
bbs net...

Not hardly.

  There are probably 100 times more sites on the Internet than
on the bbs net (making the scale of the change a whole lot
larger) and there is no mechanism to enforce Internet standards
on the Internet so there would be no possible way of making a
smooth transition.  Additionally, they don't need any such
change.

>It sure has been nice to see the educational information posted
to >rec.radio.amateur.* and other appropriate places ... oh wait
... time warp .. >those postings have not occured yet !

This is really harsh.

  I emailed you how to get the full set of Internet standards
and received an email reply from you which confirmed that you
got my informative email.  The whole text of all Internet
standards is far too large to post to the net under the USENET
rules.

>but nobody to explain the solution ?

I have repeatedly explained at least a couple of solutions and
others have as well.

  Drop continents and add a tiny routing lookup table OR replace
them with 4 country codes.

  Also, get Amateurs participating in the PBBSnet to clearly
mark the difference between their Internet address and their
Amateur Radio PBBS address in their .signature files in postings
and in email sent over the Internet.  Such a suggestion could
easily be placed in future releases of the PBBS software and
prevent future problems.

------------------------------

Date: 13 Aug 91 05:23:08 GMT From:
cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.na
sa.gov!lll-winken!iggy.GW.Vitalink.COM!psinntp!uupsi!dorsaidm!emj
[e-mail] Subject: Reception-Manhattan, NYC To:
[e-mail]

After reading about packet, I have found it interesting, but
wonder whether my location permits adequate reception. I live in
lower Manhattan, Greenwich Village, in New York City, low-rise
building. Any NYC people can give me an idea of reception in
this area?- - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - Michael J. Lavery, Esq.       "The only drawback
to our public CIS:  70416,1110              school system is
unsolicited cake." GEnie:  EMJAY America Online:  EMJAY2
            John Mortimer Domain:  [e-mail]
  A Voyage Round My Father INTERNET:  ....uupsi!dorsai!emjay
       :-? GayCom:  1/0 (THE BACKROOM) - GAY LAW

------------------------------

End of Packet-Radio Digest V91 #206
****************************** Date: Thu, 15 Aug 91 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #207 To: packet-radio

Packet-Radio Digest         Thu, 15 Aug 91       Volume 91 :
Issue 207

Today's Topics:        'NA' country domain appears to be
non-unique (8 msgs)                amateur <=> internet gateways
(2 msgs)                   Books on demod algorithms wanted
                     Followup on PMP                HELP! with
MBL514c and G8BPQ! (2 msgs)                   Help Locating Ver.
3.5 of MBBIOS Looking for info on establishing a ampr/internet
gateway in n. Fla.                      NA not unique etc etc
etc                  Packet activities in Houston,TX ?
                U5MIR / U5MIR-1

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 14 Aug 91 07:19:56 GMT From:
news.hawaii.edu!uhccux!uhunix1.uhcc.Hawaii.Edu![e-mail]
 Subject: 'NA' country domain appears to be non-unique To:
[e-mail]

In article <[e-mail]>
[e-mail] writes: >Well ... guess this needs
explaining again. >A location is not a route. >An address is not
a location. >A name is not an address, location, or route,
although >it may be USED as any of them, or may be mnemonically
>related to any of them. >Each end user exists in many (possibly
disjoint) domains. >e-mail addresses tend to make use of one or
more of those domains.

Right, but what's your point?  Aren't we discussing how those
names are being misused in a PARTICULAR environment?

>***  And why not add a top level domain to those addresses?
>***  One example might be ".internet" ... to keep it clear >***
 within what domain the name might be interpreted as an >***
e-mail address ...

Several people including myself have already proposed a switch
to .NOAM.  I've even gone so far as to implement that at our
local gateway.  The problems we're discussing occur not because
your hierarchal addresses don't have a top-level domain (love
those double-negatives...).  They occur because a particular
continent routing designator conflicts with an existing Internet
domain. I fail to see how adding a top-level domain on top of
the hierarchal route will make things SIGNIFICANTLY simpler than
just changing the .NA or using a different separator character.

I run a gateway, and I'm NOT convinced...--

Antonio Querubin   [e-mail] / [e-mail]
/ [e-mail]

------------------------------

Date: 14 Aug 91 06:07:18 GMT From:
olivea!spool.mu.edu!mips!zaphod.mps.ohio-state.edu!unix.cis.pitt.
edu!pitt!w2xo![e-mail] Subject: 'NA' country domain
appears to be non-unique To: [e-mail]

Hank , W0RLI, has several times requested some suggestions for a
solution to the bbs addressing problems. Here is my suggestion..

Go to a domain-style addressing scheme using the domain name
"ampr.org". This has the advantage of being already in use by
the ham tcp/ip community and also being compatable with internet
addressing standards. A complete address would then be
"[e-mail]". Calls are guaranteed unique. Ampr.org is
unique. The fact that this is also a tcp/ip "name" does not
matter, as the nameserver scheme that I am about to suggest will
be an *ax25* service mapping to an *ax25* address.

In answer to the problem of computing power needed to have a
name-server based addressing scheme, it is not necessary to have
serious computing power *at each site*. Establish in each region
a "nameserver" or "hub" bbs. Only these bbses would have to
employ enough processing power to do name look-up. Simple,
"local" bbses could now use less complicated software that need
only make one type of routing decision: Is this for this bbs or
for another? If the mail is not local, it gets sent to the "hub"
bbs, which, with it's greater processing power, can do a table
look-uo and send the mail to the appropriate "hub" bbs for the
destination of the message. Perhaps the "hubs" could use the
Internet for a backbone initially until 56K links really start
to be a reality.

Something else that suggests itself is that, with greater
control of how mail and bulletins flow on the "network", and a
guaranteed "serious" processor at the hub bbses, it should be
possible to keep lists of bulletins at the hubs, eliminating
BIDs and that complexity from the local bbses. If there is only
one way in or out to the network, you can exercise a lot of
control that you don't have in a "free for all" situation.

Updates to the nameserver lists would have to be sent on a
regular basis. However, these would only need to be sent among
the "hubs", reducing the bandwidth needed to send updates.

I had originally suggested placing a high order name like
"axbbs" on the present packet addresses. I have become convinced
that this is really just a band-aid. What we end up with is a
scheme that is partially source-routed and partially
domain-style. I don't think this is good.

Anyway, this is my suggestion. If you break the thing down to
where most bbses can run 4.77 mhz XTs or Color Computers or C64s
and you need only one '386 or Sun or whatever in each region,
then domain-style addressing certainly could be made to work on
ham radio. A large portion of the networking world uses this
style of addressing. I am afraid that ham radio will certainly
be left out in the cold unless we "get with the program".

Certainly, this scheme would have to be implemented in parallel
with the existing bbsnet. We can't just shut down and change it
all over. What I'm suggesting would be an entirely new network
that would develop alongside the present network.

-Jim, W2XO

------------------------------

Date: 14 Aug 91 01:00:33 GMT From:
timbuk!shamash!uc!apctrc!voyager![e-mail] Subject:
'NA' country domain appears to be non-unique To:
[e-mail]

In article <[e-mail]>
[e-mail]  writes:

>My comments with *** > >(Grab flame thrower from closet ...)

I almost stopped here...but I'm glad I didn't --- I found some
of the  attempted humor in here almost amusing.  good thing I
didn't follow my normal practice, and automatically filter
anything with the word 'flame' to /dev/null.  I might have
missed a laugh or two.....

>*** So   *WHAT ARE THOSE SUGGESTIONS*  ?

you didn't read much, did you?

>*** Please be just a tad more specific, and then  *SEND ME
THOSE STANDARDS* >*** Also, send the recommendations on how to
USE those standards within >*** the bbs net ...

well, I could, but it occurs to me that you are quite capable of
getting them yourself via anonymous ftp.  ftp to one of the
sites that maintains up-to-date listings of RFCs, grab the index
first, and look for the RFCs that describe the info you're
looking for.  then, ftp the appropriate RFCs themselves.

I trust you know what ftp means?  do you know how to use it?

>***  Thank you for volunteering to register the "packet" domain
with the >***  NIC (whatever that is ...) [remainder of
form-note deleted]

whatever that is?  if you don't know what the NIC is, you are
certainly not among the group of people writing BBS/e-mail
software, so why worry about it?

oh, and I don't recall volunteering.  did anyone else read that
in my post? or is this just a load of random typing on someone's
part that ends up almost looking like a news post?  (odd format,
though)

>***  Thank you for  [more dribble deleted]

>Internet:  [e-mail]  (- or -)
[e-mail] >Amateur Radio: >   TCP/IP:
[e-mail] (44.72.47.193) >   Packet:    n5ial@wb9yae
(Chicago, IL, US)

>***  Um ... I'm on tcp/ip here ... of course it's local to this
building ... [more dribble deleted]

did anyone else read my .signature, which specified 2 Amateur
Radio addresses, and just automatically assume that they could
be used in any type of network, regardless of anything else at
all?  hmmm.... I wonder....  my computer here can run TCP/IP ---
I wonder if I can ftp direct to labrea.stanford.edu and grab the
latest TeX src, without even having a physical, radio, or other
connection to it?

>***  (Stuff flame thrower back into closet ...)

oh, I'm sorry, did you ever take it out?  I must have missed
something. but then, it wasn't too easy to sort out what was
yours vs. mine, when you didn't insert the > characters in front
of my text....  most editors should be capable of doing this,
whether your news software does it for you or not.

   --jim

Standard disclaimer....These thoughts started out as mine, but
my cat did  most of the typing, while I was off reading a book.
her paws are a bit large for they keyboard, not to mention the
possible errors in translation. They are certainly not my
employer's thoughts.....

-----------------------------------------------------------------
------------Share and Enjoy!  (Sirius Cybernetics Corporation,
complaints division) 73, de n5ial

Internet:  [e-mail]  (- or -)  [e-mail]
Amateur Radio:   TCP/IP:    [e-mail] (44.72.47.193)
Packet:    n5ial@wb9yae    (Chicago, IL,
US)--------------------------------------------------------------
----------------

ok.....now, let's all try and connect to an amateur radio TCP/IP
address from our local ethernets at work....and we can take a
poll as to how many of them work....  my guess is that nobody
would ever seriously try.

------------------------------

Date: 14 Aug 91 01:07:07 GMT From:
timbuk!shamash!uc!apctrc!voyager![e-mail] Subject:
'NA' country domain appears to be non-unique To:
[e-mail]

my apologies if this somehow gets posted twice....our server
zapped out of existence for a minute, and this APPEARS to have
aborted.

In article <[e-mail]>
[e-mail]  writes:

>My comments with *** > >(Grab flame thrower from closet ...)

I almost stopped here...but I'm glad I didn't --- I found some
of the  attempted humor in here almost amusing.  good thing I
didn't follow my normal practice, and automatically filter
anything with the word 'flame' to /dev/null.  I might have
missed a laugh or two.....

>*** So   *WHAT ARE THOSE SUGGESTIONS*  ?

you didn't read much, did you?

>*** Please be just a tad more specific, and then  *SEND ME
THOSE STANDARDS* >*** Also, send the recommendations on how to
USE those standards within >*** the bbs net ...

well, I could, but it occurs to me that you are quite capable of
getting them yourself via anonymous ftp.  ftp to one of the
sites that maintains up-to-date listings of RFCs, grab the index
first, and look for the RFCs that describe the info you're
looking for.  then, ftp the appropriate RFCs themselves.

I trust you know what ftp means?  do you know how to use it?

>***  Thank you for volunteering to register the "packet" domain
with the >***  NIC (whatever that is ...) [remainder of
form-note deleted]

whatever that is?  if you don't know what the NIC is, you are
certainly not among the group of people writing BBS/e-mail
software, so why worry about it?

oh, and I don't recall volunteering.  did anyone else read that
in my post? or is this just a load of random typing on someone's
part that ends up almost looking like a news post?  (odd format,
though)

>***  Thank you for  [more dribble deleted]

>Internet:  [e-mail]  (- or -)
[e-mail] >Amateur Radio: >   TCP/IP:
[e-mail] (44.72.47.193) >   Packet:    n5ial@wb9yae
(Chicago, IL, US)

>***  Um ... I'm on tcp/ip here ... of course it's local to this
building ... [more dribble deleted]

did anyone else read my .signature, which specified 2 Amateur
Radio addresses, and just automatically assume that they could
be used in any type of network, regardless of anything else at
all?  hmmm.... I wonder....  my computer here can run TCP/IP ---
I wonder if I can ftp direct to labrea.stanford.edu and grab the
latest TeX src, without even having a physical, radio, or other
connection to it?

>***  (Stuff flame thrower back into closet ...)

oh, I'm sorry, did you ever take it out?  I must have missed
something. but then, it wasn't too easy to sort out what was
yours vs. mine, when you didn't insert the > characters in front
of my text....  most editors should be capable of doing this,
whether your news software does it for you or not.

   --jim

Standard disclaimer....These thoughts started out as mine, but
my cat did  most of the typing, while I was off reading a book.
her paws are a bit large for they keyboard, not to mention the
possible errors in translation. They are certainly not my
employer's thoughts.....

-----------------------------------------------------------------
------------Share and Enjoy!  (Sirius Cybernetics Corporation,
complaints division) 73, de n5ial

Internet:  [e-mail]  (- or -)  [e-mail]
Amateur Radio:   TCP/IP:    [e-mail] (44.72.47.193)
Packet:    n5ial@wb9yae    (Chicago, IL,
US)--------------------------------------------------------------
----------------

ok.....now, let's all try and connect to an amateur radio TCP/IP
address from our local ethernets at work....and we can take a
poll as to how many of them work....  my guess is that nobody
would ever seriously try.

------------------------------

Date: 13 Aug 91 15:50:38 GMT From:
ucselx!sol.ctr.columbia.edu!spool.mu.edu!cs.umn.edu!kksys!edgar!b
rainiac!moron![e-mail] Subject: 'NA' country domain
appears to be non-unique To: [e-mail]

If it is decided to make the PBBSNet a zone within the ampr.org
sub-domain,  I think we will need to actually give it it's own
zone.  The question that  this poses though is, should ucsd.edu
be the primary DNS for that zone, or  should there be other
primary DNS's for that zone, given that the PBBSNet is  (sort
of) administered geographically. e.g. All PBBSNet machines fall
into the pbbsnet.ampr.org zone,     All American BBS's fall into
the na.pbbsnet.ampr.org zone,     All British BBS's fall into
the gbr.pbbsnet.ampr.org zone,     and so on.

That way, the existing (and usually faster) mail systems would
handle the  bulk of the mail DESTINED for the PBBSNet FROM the
Internet, and vice versa.  Also, it would be easier to maintain
the pbbsnet sub-domain with regional  primary zone servers.

Anyhow, I think we need to differentiate between Tcp/Ip ampr.org
(i.e.  existing) hosts, and those which MUST pass through an
SMTP<-->PBBSNet  gateway.  Naturally, a NOS or MSYS host could
perform as that gateway, and  therefore _could_ belong to more
than one network.

Comments?

73

     73's     Chris Cox  W0/G4JEC

     EMail [e-mail]         AMPRNet
[e-mail]


------------------------------

Date: 13 Aug 91 16:00:59 GMT From:
ucselx!sol.ctr.columbia.edu!spool.mu.edu!cs.umn.edu!kksys!edgar!b
rainiac!moron![e-mail] Subject: 'NA' country domain
appears to be non-unique To: [e-mail]

[e-mail] (Chris Cox W0/G4JEC) writes:

> e.g. All PBBSNet machines fall into the pbbsnet.ampr.org zone,
>      All American BBS's fall into the na.pbbsnet.ampr.org
zone, >      All British BBS's fall into the
gbr.pbbsnet.ampr.org zone, >      and so on. >  Whoops! - That
should have read:-       All American BBS's fall into the
usa.pbbsnet.ampr.org zone, and not na.pbbsnet...

As has been said previously, the use of a continent designator
is redundant.  Someone suggested that it lowers the overhead on
the individual BBS's from  having to determine which continent
is the next hop in a path, but surely  the continent information
can be stored locally on each BBS and some hashing  algorithm
(if you wanted to be fancy :-)) used to look up the countries
continent if you feel it _must_ be determined.

What noone has yet mentioned (at least I haven't seen them
mention) is just  how much extra bandwidth is consumed in
virtually EVERY message passed  between PBBS's because of the
continent designator.  Surely, that extra  time saved by NOT
sending the continent in each message would more than  makeup
for the time taken to do the lookup...

Oh well, I'm ready to duck :-) :-)  Fire away!

     73's     Chris Cox  W0/G4JEC

     EMail [e-mail]         AMPRNet
[e-mail]


------------------------------

Date: 14 Aug 91 17:40:48 GMT From: [e-mail] Subject: 'NA'
country domain appears to be non-unique To: [e-mail]

------------------------------

Date: 15 Aug 91 00:34:59 GMT From:
swrinde!zaphod.mps.ohio-state.edu!think.com!news.bbn.com!bbn.com!
[e-mail] Subject: 'NA' country domain appears to be
non-unique To: [e-mail]

I've tried to remain silent on this, but I think it's time to
inject my comments.

First, my credentials:  I ran W0RLI MailBoxes (Hank didn't want
to call them BBSes) in the early days.  I started when Hank and
I lived 15 miles apart and the platform was the Xerox 820.
There were chunks of my code in both the Z80 and PC C-compiler
versions, maybe still are.  My PBBS was the major NTS node for
New England.  (I stopped running a PBBS some years ago.)  I have
also been involved in Arpanet/Internet mail since the days when
there were only about 6 nodes on the Arpanet and TENEX was the
dominant operating system on the net. (I wrote the first FTP on
the ARPAnet, which carried the mail before SMTP was invented.)

The basic problem is this:   The "bbsnet" chose to implement an
addressing scheme that LOOKS EXACTLY LIKE, but IS NOT, the
Internet domain name system.

As soon as this mistake was made, those of us on the Internet
yelled and screamed that it was a mistake.  I personally yelled
at Hank, and offered to give him whatever examples and standards
and documentation he might want, to show him why it was a
mistake. He seems to have forgotten this, (Sorry, Hank, but I
did.  We all forget things, me NOT excepted).  At the time, he
said, as he says now, that the two systems were different and
therefore the similarity was unimportant.  I was unable to
convince him that it would be a problem.

The point was then, and is now, that two very different things
look just the same.  People (and programs, but mainly people)
are SURE to occasionally get them confused.  This COULD and
SHOULD have been avoided by not making them look the same.

Changing the top-level domain (rightmost field) might
temporarily eliminate the current conflicts, but it is again
sure to not solve the problem.  Name conflicts will appear in
the future between these completely different, separately
administered, yet identical-looking systems.

The correct fix is still the one that was suggested at day one:
Make them LOOK different because they ARE different.

The most straightforward way to do this appears to be to have
the "bbsnet" operators and authors switch to a different
separator, such as ":" instead of "." between fields of the
name/routing-hint elements.  Hank even said this would not be a
hard change, though he thinks it won't help.  I believe it WILL
help a great deal, and in fact will solve the problem.  The only
other colon-separated thing I know of that looks at all the same
is the Ethernet hardware address, and in that case all the
fields are two-digit hex numbers.  Not much chance of confusion.

Change the PBBS software to DISPLAY addresses (hints) as
":"-separated, even if they arrive "."-separated, and to accept
(for a while) "."-separated addresses (hints), but immediately
change them to ":"-separated strings.  Users WILL change, even
though they will grumble.

All the suggestions about ".ampr.org" and ".packet" are red
herrings. Even if they were adopted, they are still incorrect.
The resulting strings are NOT host names, as all the
PBBS-authors agree.  So they shouldn't look like them.

The basic point, at the risk of repeating myself too often, is
that it was a serious mistake to make two things which are very
different look as though they are the same.  The correct fix is
to make them look different.  I believe it is much easier to
change the "bbsnet" addresses-cum-routing-hints than the
Internet's domain name system (consider all the commercial
vendors and turnkey systems).

I ask Hank and the other authors to PLEASE do this.

73, Bob Clements, K1BC, [e-mail]

------------------------------

Date: 14 Aug 91 15:36:10 GMT From:
usc!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!aramis.rutg
ers.edu!remus.rutgers.edu!outlaws.rutgers.edu![e-mail]
Subject: amateur <=> internet gateways To: [e-mail]

Not to try and change the ".NA" arguments that I am getting
tired of but:

I am interested in setting up a internet <-> amateur radio
TCP/IP gateway. My question is: what are the legal issues
involved? I assume that any amateur could legaly send data to
internet (ie mail) so long as another person on internet was not
responding back. What mmust be done to go the other way? Does a
person have to check all the internet> amateur mail? What about
telnet type sessions where there is a virtual circut?

I know these gateways (for mail at least) exist at now. Can any
of you how operate these tell me how you feel about the legal
questions? Any laywers who deal with part 97 please joing in as
well.

For replies either mail or posting to the net will do. If I get
good responses I will compile a article of the most usefull and
post it to the net.

-Tim N2KBG ( packet *RADIO* [e-mail] or
[44.64.0.153])--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~ | Tim Hayes                      | No beast so
fierce but knows some touch  | | Rutgers College of Engineering
| of pity, but I know none and therefore   | |
[e-mail]       | am no beast.
         | | [phone] [leave a msg]    |
                      |
_________________________________________________________________
____________ Subject: amateur <=> internet gateways Newsgroups:
rec.radio.amateur.packet Distribution: na Keywords: legal
question

Not to try and change the ".NA" arguments that I am getting
tired of but:

I am interested in setting up a internet <-> amateur radio
TCP/IP gateway. My question is: what are the legal issues
involved? I assume that any amateur could legaly send data to
internet (ie mail) so long as another person on internet was not
responding back. What mmust be done to go the other way? Does a
person have to check all the internet> amateur mail? What about
telnet type sessions where there is a virtual circut?

I know these gateways (for mail at least) exist at now. Can any
of you how operate these tell me how you feel about the legal
questions? Any laywers who deal with part 97 please joing in as
well.

For replies either mail or posting to the net will do. If I get
good responses I will compile a article of the most usefull and
post it to the net.

-Tim N2KBG ( packet *RADIO* [e-mail] or
[44.64.0.153])

------------------------------

Date: 14 Aug 91 19:52:39 GMT From:
hpl-opus!hpnmdla![e-mail] Subject: amateur <=>
internet gateways To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (Tim
Hayes) writes:

>I am interested in setting up a internet <-> amateur radio
TCP/IP >gateway. My question is: what are the legal issues
involved? I assume >that any amateur could legaly send data to
internet (ie mail) so long >as another person on internet was
not responding back. What mmust be >done to go the other way?
Does a person have to check all the internet >-> amateur mail?
What about telnet type sessions where there is a >virtual circut?

Despite what others are likely to tell you here on the net, it
seems clear that no messages should ever be transmitted on
amateur radio without being checked first by the amateur
operator who first transmits them.

"97.109 Station Control ... (b) When a station is being locally
controlled, the control operator must    be at the control
point... (c) When a station is being remotely controlled, the
control operator must    be at the control point... (d) When a
station is being automatically controlled, the control operator
  need not be at the control point... (e) No station may be
automatically controlled while transmitting    third-party
communications, except a station retransmitting digital packet
 radio communications on the 6m and shorter wavelength bands...
  The retransmitted messages must originate at a station that is
being    locally or remotely controlled.

...

97.115 Third party communications.

(a) An amateur station may transmit messages for a third party
to:    (1) Any station within the jurisdiction of the United
States.    (2) [Countries with a third-party agreement with the
U.S.] (b) The third party may participate in stating the message
where:    (1) The control operator is present at the control
point and is        continuously monitoring and supervising the
third party's        participation...

97.3 Definitions ... (38) Third party communications.  A message
from the control operator     (first party) of an amateur
station to another amateur station     control operator (second
party) on behalf of another person     (third party)."

Note:  The "third party" may be a licensed amateur, if he is not
one of the control operators.

AL N1AL

------------------------------

Date: 14 Aug 91 21:14:25 GMT From:
morrow.stanford.edu!neon.Stanford.EDU![e-mail] Subject:
Books on demod algorithms wanted To: [e-mail]

Does anyone have book suggestions for writing DSP Costas loops
and other useful algorithms?  I already have enough books on how
to write decent filters...

--=Paul Flaherty, N9FZX        | "Is this really Butte,
Montana,>[e-mail]   |  or just Existential
Blues?" -- T-Bone Stankus

------------------------------

Date: 13 Aug 91 21:15:32 GMT From: intran![e-mail]
Subject: Followup on PMP To: [e-mail]

I got all the stuff (complete kit) from the folks yesterday.
(actually it came  last week while I was on vacation).  Went
flying for a couple hours, then started on assembling it.  I got
it all together in about an hour.  Started the test procedures
as recommended in the article.  Found I put the 5V reg in
backwards.  Took it out, turned it around and prayed.  Measured
the voltage, and the meter ssaid about 8V (darn I blew it up),
well looking around I remembered the board isn't plated thru the
holes, and I forgot to solder the top.  Now the meter is saying
over (on the 20V scale) couple other checks, and the meter is
diagnosed as flakey.  200V scale, reads 5.1 volts (whew).

Tuned it up according to the instructions, and I am getting all
the good RX indications and everything looks good.  Just not
getting any text to show up. It was pretty late and I was really
tired (recovering from vacation and all).

Hints.  Be careful, follow the instructions.  I had the
regulator in backwards, and If the modem chip were installed, I
would have to wait a couple days for a replacement. Use a
longish cable for connecting the modem to the radio.  I have a
3" cable on the  recieve side, and I am forever knocking the
radio about.

The software looks great!  I am really impressed, they really
put a lot of trouble into making the PMP program easy to use.
The screen looks scary, but ALT-H provides all the answers.

I'll keep you informed

Tom Brusehaver WD0EIB@wb0gdb uunet!intran!tom

------------------------------

Date: 14 Aug 91 15:23:16 GMT From: uvaarpa!cube![e-mail]
Subject: HELP! with MBL514c and G8BPQ! To: [e-mail]

I ran just such a BBS for years, here, but a lightening strike
wiped it out. Now that I'm starting over, I have a problem
between MBL and BPQ that's driving   me batty!  Either MBL isn't
sending a break, or BPQ isn't obeying it.  The   symptom is that
when a user connects, he gets: *** connected to WA4ONG conok off
mon off [MBL whatever] ..etc

The TNC commands are being sent to the connector, instead of the
TNC! The same problem exists on forwarding, the BBS does a C
SWITCH, then sends a   TRAN to the node, which calls it an
unknown command!  Then the BBS goes on   forwarding, but in
non-transparent mode, i.e. one line per packet!

I MUST have something set up wrong!

(I've tried bpq 4.03a and 4.04, both act the same!)

Jim De Arras, WA4ONG

------------------------------

Date: 14 Aug 91 18:08:18 GMT From:
haven.umd.edu!uvaarpa!cube![e-mail] Subject: HELP! with
MBL514c and G8BPQ! To: [e-mail]

In article <[e-mail]>
[e-mail]   (Jim De Arras) writes: > I ran just such
a BBS for years, here, but a lightening strike wiped it out. >
Now that I'm starting over, I have a problem between MBL and BPQ
that's   driving   > me batty!  Either MBL isn't sending a
break, or BPQ isn't obeying it.  The   > symptom is that when a
user connects, he gets: > *** connected to WA4ONG > conok off >
mon off > [MBL whatever] > ...etc >  > The TNC commands are
being sent to the connector, instead of the TNC! > The same
problem exists on forwarding, the BBS does a C SWITCH, then
sends a   > TRAN to the node, which calls it an unknown command!
 Then the BBS goes on   > forwarding, but in non-transparent
mode, i.e. one line per packet! >  > I MUST have something set
up wrong! >  > (I've tried bpq 4.03a and 4.04, both act the
same!) >  > Jim De Arras, WA4ONG >

And yes, I DID have something set up wrong!  I lacked 'nomode
on' in the TNC   init section of MBL's config file!  So now it's
working!  I hadn't bothered   with that stuff in YEARS!

73 Jim WA4ONG

------------------------------

Date: 14 Aug 91 10:22:06 GMT From:
usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!uakari.p
rimate.wisc.edu!aplcen!wb3ffv![e-mail] Subject: Help
Locating Ver. 3.5 of MBBIOS To: [e-mail]

[e-mail] (Douglas MacDonald) writes: > 1.  A
friend has requested my help in locating an anonymous ftp site >
for version 3.5 of MBBIOS, a program for managing serial ports
on DOS > machines.

   Hello,

As far as FTP, you can find it on tomcat.gsfc.nasa.gov in the
directory of bbs/aa4re under the file name of mbbios35.zip.  If
you don't have FTP access you can get it from my telephone BBS
at any of the numbers listed below, and it will be in the
ham/aa4re directory under the same file name as listed above.
Here are the telephone numbers, and the BBS is open to all.


************************************************************
     *   ===========> The AMATEUR RADIO BBS <===========
*          *
     *               *        Welcome to the WB3FFV Multiuser
System            *          *        Running under UNIX System
V Release 3.2           *          *        The CPU is an ABS
80486/25  (25mhz)               *          *        Supported
by: Advanced Business Solutions         *          *        24
hrs a day / 7 days a week / 365 days           *          *
                                                    *          *
   301-625-0817 - 1200/2400/4800/9600/19200/38400        *
   *                   (MNP2-5, V.32, V.42bis)                *
        *
  *          *    301-625-9482 -
1200/2400/4800/9600/14400/19200/38400  *          *
     (MNP2-5, V.32, V.32bis, V.42bis, HST)  *          *
                                                 *          *
301-625-9663 - 1200/2400 (MNP2-5), 9600/19200         *
*                   (9600/19200 Telebit PEP ONLY)          *
     *
*          *    301-244-8790 - FAX Machine
     *          *
          *          *    301-576-8635 - VOICE ONLY !!!
               *
************************************************************

-----------------------------------------------------------------
-------------Internet  : [e-mail]    |    Howard D.
Leadmon UUCP      : wb3ffv!howardl        |    Advanced Business
Solutions TELEX     : 152252474             |    210 E. Lombard St -
Suite 410 FAX       : [phone]              |
Baltimore, MD 21202  PACKET    : WB3FFV @ WB3FFV.MD.USA.NA   |
    Phone: [phone]

------------------------------

Date: 15 Aug 91 03:20:42 GMT From:
stanford.edu!leland.Stanford.EDU![e-mail] Subject:
Looking for info on establishing a ampr/internet gateway in n.
Fla. To: [e-mail]

Could someone point a finger to where I can get any information
on the local packet radio situation down in Mary Ester, Fla.
(just outside of Fort Walton Beach)?  I hope to be leaving my
current assignment here at Clark AB, Philippines (the home of
Mt. Pinatobo (sp)) soon and moving onto my next assigment at
Hurbert Field, Fla.

I need to find out who the local packet coordinator is and what
equipment and software would be of use to best intergrate into
the local packet net.

I have an ISI V24WS running 4.3 BSD and a Sun 2/50 running SunOS
4.0.3 with nearly 1.8 Gb of disk space between them.  With these
two machines I'd like to establish a AMPRNet/Internet gateway in
northern Fla.  I'd like to offer to supply the combined services
of a public UNIX system  and packet BBS to the hams in that part
of the country if they would like to support it.

Some of the services I'd like to offer are telnet, ftp, smtp,
nntp, callsign server, PBBS, home logins for interested hams.
Some more interesting services I had in mind are is a satelite
monitoring  station to pull down files from any of the microsats
using the AMSAT broadcast protocol (I'll make thes files
available), or how about a MUD or multi-player combat simulator
(you could have players from both sides of the gateway playing)?

I know that many would be very happy to see such a resource
become  available to the ham community.  But, I need to know the
above info before I can start to budget for TNCs and rigs (I
already have the computing power :-)).

Also, if anyone would be interested seeing such a system and/or
would like to take part in the design of such an implementation
please contact me.

73 de KA0TGN (hm. looks like I'll have to get a new callsign)

-Freeman



-Freeman P. Pascal IV       John 3:16 -    For the Lord so loved the
world that [e-mail]        He sent his only begotten
Son, that KA0TGN                    whoever believes in Him should not Jesus is
my LORD.            perish but have everlasting life.

------------------------------

Date: 15 Aug 91 05:21:04 GMT From:
munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!greed
.teaching.cs.adelaide.edu.au![e-mail] Subject: NA
not unique etc etc etc To: [e-mail]

Hank and a couple of others want to move this discussion  to the
BBS network.

Two problems with this,

1. It will be painfully slow!

2. How do you propose to get the coverage of the entire world?
Here in Australia it is quite unusual to see ANY bulletins out
of the USA. We do see lots from Europe via AsiaNet BUT that can
be upto a month old.

Before moving the current world wide discussion to the BBS net
can we  agree to implement a bulletin designator that covers the
whole world? At  least at the SysOp level? WW is used in Europe
I noticed but WW doesnt  make it past the Europe><AsiaNet
Gateways, and as I mentioned practically  nothing except AMSAT
stuff makes it outside of the US.

Cheers de Grant VK5ZWI--

Grant Willis (VK5ZWI), Electronic Engineering Student. |
Adelaide University AARNet/Internet1:
[e-mail]        | South AUSTRALIA
AARNet/Internet2: [e-mail] | My
views are my own, AmPRNET: VK5ZWI@VK5TTY.#SA.AUS.OC
[44.136.171.11]     | not the Uni's!

------------------------------

Date: 14 Aug 91 18:46:15 GMT From: [e-mail]
Subject: Packet activities in Houston,TX ? To:
[e-mail]

From:    HUTIN@PSI%EPSX25@MRGATE@SNDRTR
To:    "[e-mail]"@M_INTERNET@MRGATE@SNDRTR

 I'll move very soon to Houston Tx and i am looking to some
information on packet activities in the area. My basic questions
are the following:

What are the major BBS in west Houston or in Sugarland. Have
they 9600 Bds access? Who is the TCPIP coordinator for the area?
How is the forwarding between Houston and France (or Europe ,or
Quebec)?

73s Remi FE6CNB soon W5/FE6CNB

INternet: [e-mail]  (remark it's an address in
France) Compuserve: [e-mail] Packet Radio:
FE6CNB @ FF6PTT.FRPA.FRA.EU TCPIP Radio: [e-mail]

------------------------------

Date: 14 Aug 91 15:46:39 GMT From:
swrinde!cs.utexas.edu!ut-emx!ccwf.cc.utexas.edu![e-mail]
Subject: U5MIR / U5MIR-1 To: [e-mail]

Netsirs, Would you describe a VHF station that I might set up to
QSO with U5MIR? I was able to hear him on voice and a few CQ
packets last Saturday morning, and I would like to make a
connect. I am wondering what sort of power / antenna / tracking
I might need. I'd like to build as much of it as is reasonable,
but any suggestions would be greatly appreciated. BTW, I was
using my Kenwood TH25AT, with a 1/4 wave ground plane antenna
(from the ARRL Handbook design), with a Kantronics TNC / Laptop.
Should I buy a brick?  Build a helical antenna? or a Yagi? Will
my YL kill me when I bring this stuff home? (Why ask why :-)
Thanks in advance, David, N5TLZ

------------------------------

Date: 14 Aug 91 08:19:16 GMT From:
pyramid!athertn![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail]> Reply-To
: [e-mail] Subject : Re: 'NA' country domain appears
to be non-unique

In article <[e-mail]> [e-mail] (Kurt
Freiberger) writes: >In article <[e-mail]>,
[e-mail] (Andy Warner) writes: >|>  >|> In article
<[e-mail]>,
[e-mail] writes: >|> > [...] >|> > ***  Let's do
it on the bbs net.  I don't usually have time at work to >|> >
***  play ham radio, and can only read/post now and then, when
workload >|> > ***  is a bit slack. >|> > [...] >|>  >|> This
should slow the whole controversy down - make it more of a test
>|> of patience :-) :-) >|>

There are probably more folks on BBSnet (who do not have access
to USEnet) that can add much to this discussion.  I agree with
Hank.

Let's move the discussion to BBSnet.

'Sides...I will soon lose my news account, and this is important
to me.

73 de Steve BBSnet: KA6ETB @ N6LDL.CA.(you fill in the rest)
USEnet: [e-mail]

------------------------------

Date: 14 Aug 91 16:30:34 GMT From:
usc!cs.utexas.edu!helios!cs.tamu.edu![e-mail] To:
[e-mail]

References <[e-mail]>, <[e-mail]>,
<[e-mail]> Subject : Re: 'NA' country
domain appears to be non-unique

In article <[e-mail]>,
[e-mail] (steve harding TMP) writes: |>  |>
BTW ... It's Namibia

Sorry, the i key on this Xterminal doesn't always work.  I
usually have to hit  it wth ~350 newtons.

|> BBSnet: [e-mail] |> USEnet:
[e-mail] |>  |> Don'cha just love UNIX?

How's this?
wb5bbw@wb5bbw.#STX.TX.USA.NA.EARTH.SOL.UNFASHIONABLE_PART_OF_THE_
 WESTERN_SPIRAL_ARM.MILKY_WAY_GALAXY.MIND_OF_IAEOVAH ???  Think
that's unique enough?  Even UUCP could do that!  8-}--  Kurt
Freiberger, wb5bbw      [e-mail]   409/847-8607
fax:[phone] Dept. of Computer Science, Texas A&M University
     DoD #264: BMW R80/7 pilot "We preserve our freedom using
three boxes: ballot, jury, and cartridge."      *** Not an
official document of Texas A&M University ***

------------------------------

Date: 15 Aug 91 04:56:56 GMT From:
usc!samsung!munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@uc
sd.edu To: [e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail]>
Subject : Re: 'NA' country domain appears to be non-unique

In <[e-mail]>
[e-mail] (steve harding TMP) writes:

>>|> > ***  Let's do it on the bbs net.  I don't usually have
time at work to

>There are probably more folks on BBSnet (who do not have access
to >USEnet) that can add much to this discussion.  I agree with
Hank.

>Let's move the discussion to BBSnet.

Thus guaranteeing no one outside of the USA participates.  At
least keep it going here as well and those who are on both the
US BBSnet and the Internet can repost as necessary.

>'Sides...I will soon lose my news account, and this is
important >to me.

And to me however mail flow from here to the US is virtually
non-existant. :-(  (I intend to rectify that soon!)

Carl.

--
+----------------------------------------------------------------
------------+ | Carl Makin   [e-mail]
[e-mail]            | |              3:620/241.7
              [44.136.0.5/14/16]                  | | It's not
worth worrying about,  whatever it is.
 |
+----------------------------------------------------------------
------------+

------------------------------

Date: 14 Aug 91 08:03:43 GMT From:
pyramid!athertn![e-mail] To:
[e-mail]

References <[e-mail]>, <[e-mail]>,
<[e-mail]> Reply-To : [e-mail] Subject :
Re: 'NA' country domain appears to be non-unique

In article <[e-mail]> [e-mail] (Kurt
Freiberger) writes: >In article <[e-mail]>, [e-mail]
(Brian Kantor) writes: >|>  >|> But wait!  You'll have to change
the bbs software!  After all, it >|> understands '.NA' now, not
'.NOAM' or '.MOON'. > >     Actually, no, that is data driven. >
>|> >3.  Getting the BBS addresses to change the separator from
a "." to a ":" >|>  >|> Hmm.  You'd have to change the software
for this one too.  It would be a >|> nice clean change, though.
> >  No, then some idiot would use the address on banyanmail or
VAXmail and  >we'd have the same problem.  or does Nambia have
the good taste not to use  >VAXen? 8-} > Gawd...I hope so.

BTW ... It's Namibia

BBSnet: [e-mail] USEnet:
[e-mail]

Don'cha just love UNIX?

------------------------------

End of Packet-Radio Digest V91 #207
****************************** Date: Fri, 16 Aug 91 04:30:07 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #208 To: packet-radio

Packet-Radio Digest         Fri, 16 Aug 91       Volume 91 :
Issue 208

Today's Topics:        'NA' country domain appears to be
non-unique (2 msgs)                      Communicating with
Europe                    Hypercard stack for Ham Radio
 Interfacing DIGICOM to the IBM; use with BAYCOM
   The great .NA controversy....

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 15 Aug 91 13:39:37 GMT From: [e-mail] Subject: 'NA'
country domain appears to be non-unique To: [e-mail]

I've AGAIN sent Hank a copy of most of the relevant RFCs for
internet mail, host operation, and domain naming, in the hopes
that he'll read them and learn something from them this time.

Directly applicable or not, there is a LOT of accumulated
networking wisdom in those documents.  After all, they summarize
the lessons learned from 20 years of running a network that now
spans the globe, has more than a million hosts attached to it,
and can reach an estimated 20 million users.

Next to that, the ham BBSnet is tin cans and string.  Let's see
if we can't make it better!

- Brian

------------------------------

Date: 15 Aug 91 12:49:24 GMT From:
sdd.hp.com!samsung!emory!wa4mei!ke4zv![e-mail] Subject:
'NA' country domain appears to be non-unique To:
[e-mail]

In article <[e-mail]>
[e-mail] writes: [I wrote] > >I would suggest
the obvious solution is scanning routing hints right  >to left.
Posting software should always require a full hierarchial
>address. It may supply default continent and country, even
state and  >local, designators if none are supplied by the user.
Then by scanning  >right to left all ambiguities caused by local
names are resolved properly  >at the appropriate local level.
Your forwarding software should certainly >have a forwarding
solution for continental designators that it can >fall back on
if a forwarding solution fails for countries. Similarly, >if a
country solution is found, it can be fallen back on if a state
>solution is missing. And so on down to local LAN names. There
is  >never any uncertainty because *every* address would start
with the >same top level field as it's rightmost element and the
software scans >until it can resolve no further. There should
never be confusion between  >a country code and a continent
code, or some very localized code as  >scanning descends the
routing hierarchy. The only precaution needed to  >prevent
problems with other networks is to avoid using conflicting top
>level names. In the case of the BBSNET, there are only seven to
worry about. >The major fault of current BBS software, as I see
it, is that it doesn't >respect it's own self imposed
hierarchial nature, because it scans in the >wrong direction. >
>Gary KE4ZV > [Hank wrote] > >***  I'd sure like to clear this
up ... >***    IT DOESN'T SCAN LEFT TO RIGHT >***  Have posted
this fact to the bbs net many many times, >***  but someone out
there keeps claiming it does ... >***  If you really do have a
solution, please post details, can implement >***  solution
rather quickly, if you have one.  Please describe how the >***
various tables would look for some example cases.  i.e.  I'm not
going >***  to do  *ALL*  the work myself ... include samples of
init.mb, fwd.mb, >***  and config.mb  ... I assume you know my
code well, since you claim >***  to understand how it operates.

I haven't run a packet BBS in two years, but my recollection is
that your software does regular expression string matches on a
text routing file starting with most local match first. If
that's false, then I'm in error and apologize. I've seen
comments about having to prepend a # in front of local
references in order to avoid confusion with top level names of
the same spelling. This reinforces my view that you aren't doing
a recursive descent right to left parsing of the name. Since I
haven't seen the source code, I don't really know what you are
doing.

Gary KE4ZV

------------------------------

Date: 16 Aug 91 00:18:42 GMT From: [e-mail]
Subject: Communicating with Europe To: [e-mail]

Hello Folks!

Regarding the current discussions about future changes in the
PBBS routing schemes, I have put a message into the EU packet
net saying "US authors of PBBSs want better cooperation with
those in other countries".

This is one of the replies:

In Message <[e-mail]>,
db0sao!db0cz!hb9pd!fe6big!gb7gmx!gb7chs!gb7fci!g6fci writes: >
R:910815/0650z @DB0CZ  [Deisslingen JN48HD DIEBOX 1.8  OP:
DK5TB/DF9UV] > R:910815/0633z @HB9PD  [PRIG BOX GRENCHEN,
JN37QE, TheBox 1.8 Sysop: HB9BRC] > R:910815/0630Z
@FE6BIG.FRHA.FRA.EU #127575 [Annecy - FBB5.12] > R:910815/0622Z
@GB7GMX.#16.GBR.EU #15999 [Manchester] > R:910815/0618Z
@GB7CHS.#11.GBR.EU #48102 [NWPUG] Cheshire NTS > R:910815/0606
@:GB7FCI.#16.GBR.EU #:23057 Blackpool > Hi Rolf.  I don't have
access to the big email networks, so although I might > be
interested in taking part in the discussions (about addressing
and PBBS > software in general), I would be unable to.  As you
are able to contact the > people concerned in the USA, could you
please ask them to reconsider the use > of email networks for
packet discussions.  they may be faster, but not > everyone can
join in.  The medium that most people interested in packet use >
is packet itself, so could you sugget that they use the packet
network > for discussions in the future.  Why have our own
network and then not use it! >  > Bye for now, Chris G6FCI @
GB7FCI

I think it is rather typical for europeans, not to have internet
access. So could you please consider a way to inform your
colleagues all over the world or even better, let them take part
in the discussion, via packet..?

73, Rolf--

Internet: please use the Digest PBBS:     [e-mail]

------------------------------

Date: 15 Aug 91 17:11:14 GMT From:
aramis.rutgers.edu!remus.rutgers.edu![e-mail] Subject:
Hypercard stack for Ham Radio To: [e-mail]

Hello everyone,

Two friends of mine from the Rutgers University amateur radio
club got me into this.  They demonstrated to me  tcp/ip over
ham-radio which impressed me.  I would like to get my own
ham-radio license and they told me that there existed a
Hypercard stack on apple.com that covered everything that I
needed to know to get a license.

Unfortunately, the hypercard stack is not there anymore. I
ftp'ed to apple.com and looked into /pub/hamradio but found
nothing.  Does anyone have this file or know where I can grab it
from.

Thanks for you help!Marc [e-mail]--
_________________________________________________________________
_____________ Marc E. Fiuczynski    \\  Home: [phone]    Work:
[phone] [e-mail]      ||  UUCP:
{backbone}!rutgers!remus.rutgers.edu!mef [e-mail]    //
UUCP: {backbone}!att!mtuxo!mef

------------------------------

Date: 15 Aug 91 12:51:13 GMT From:
swrinde!mips!apple!uokmax![e-mail] Subject: Interfacing
DIGICOM to the IBM; use with BAYCOM To: [e-mail]

[posted from packet] [via WB5RZX @ WB5RZX.OK]

  This past weekend I had a chance to work my friend Dan,
WA3KZO, in one of one first IBM Digicom "BAYCOM" contacts in our
area of PA.  Most of us in NwPa use Digicom, and we were all
wondering how the new program for the IBM would work.  Well, as
Dan said, the color on the clone he was using was "Dazzling!"
Dan at my request, did the job of interfacing a Digicom board I
had for my C-64, to test the program.  After a few good hours of
hand wiring away she went.  The idea of Baycom is the same as it
is for Digicom.  A software approch to Packet radio.  You dont
need a TNC.  All you need is a small Modem that, in Baycom's
case, converts the RS232 port to standard packet tones 1200/2200
HZ.  The board connects the radio to audio in, out and PTT.  As
most Digicom users know, Digicom works very well and in some
cases has many more functions than do some well used packet
programs.  Baycom is a good program from a user stand point.  It
doesn't have the sophistication of a Digicom V 3.51  as we use
on the 64, but It is a great User program.  You can send and
receive programs to and from disc, store a message a friend may
send to you, and generally use the program. Even your hard disc
can be used for storage.  It has a fine presentation on the
screen. The screen is divided into 3 sections; Top=transmit,
Middle=receive, and bottom= a monitor Screen viewing all the
activity on the channel.  You see all the rr0's, Sabm, I frams,
etc. on this screen.  And yes if you have color, it Highlights
all this info in different colors making it easy to follow just
what is happening on the channel.  Our club, the Crawford
Amateur Radio Society, was interested in seeing just how the
Digicom boards could be interfaced to the IBM.  Dan used a
traditional method. Converting the RS232 level serial data to
TTL level so it could be used with the 64 Digicom board.  The
board was one that uses the XR2206 and XR2211 chips.. In looking
at the information that was sent with the program.  There are
many ways to do this job, Almost any Digicom board out there
currently could be used with a few changes.  Dan used the
1488,1489 approach.  We noticed that the program has remote
commands as does Digicom.  Remote commands are those sent by a
connected station.  Something Digicom has had since it
inception.  // is used for a remote command, but be aware some
            responses are returned in German.  By the way, the
same people that wrote  Digicom, wrote Baycom as well.  I'm sure
in future upgrades this will be  changed.  The authors state, as
with Digicom V1.52, that they started the ball           rolling
with Digicom in the US.  Baycom 1.20 is in its infantcy also.

  I think for the IBM user that wants to try someting new in
packet, or for the new ham that just wants to expermint with
packet, Baycom maybe somethng they want to try.  Most Digicom
modems are very inexpensive and can be converted for the IBM.
We will be sending more info on how to convert a Digicom board
when we do a bit more expermenting.  Our Club is trying to make
it as easy as possible.  Baycom is a public domain program and
can be found on some of the National BBS Telephone services.  We
dont want to name any here.              Crawford Amateur Radio
Society is our local ham radio club. Our address:  PO Box 653
Meadville. PA  16335 73's Rick WB3JDI @ K3ASI.#NWPA.PA.USA

IBM RS232 to C-64 DIGICOM MODEM    Well here it is Guys & and
Gals!  The interface you were waiting for! Crawford Amateur
Radio Society member WA3KZO Dan is testing BAYCOM for the IBM
and has come up with an interface that will allow you to use
almost any C-64 Digicom board and your IBM using BAYCOM.   The
Chip used is a MAXIM MAX 232. This chip converts TTL level 5V
signals to RS232 signals used by the IBM.    Here is the circuit:

 Input Voltage 8 to 12v             +5 V output
REGULATOR >-----+--{ 7805
}-+------+-------+---------------+------,       !+    !     ! +
  '       ! +             !      '   .33===   ///   ===.33  '
  === 10uf      16 !      ' cap   !    GND    ! cap  '       !
       !"""""""!   '+10uf      ///         ///     '      ///
+,---!1      !  ===                          '14     4.7uf ===
!      2!---'   C.A.R.S.           !"""""""!          '---!3  M
 !     observe Digicom board        !   7   !              !   A
 6!---, polarity   TO ------               !   4   !        +
,---!4  X   !   !            IBM 6 pin X-1--GND///    !   0   !
 4.7uf ===  !   2   !  ===          RS232 plug  X<5--PTT-----<2!
  4   !1<----    '---!5  3   !   ! +10uf       X<3-tx-data--<4!
     !3<-- '        !   2   !  ///       ======       X 2+5v not
all """"!""""   ' '-------<!12   13!<-------< 4 "ptt       X>4-,
             !7      '          !       !            "    D
 X>6-'---          ///      '-------- <!9     8!<-------<20 "txd
B  -----        '  Receive data               !       !
  " ~ ~           '------+-------------------- >!10
7!>-------> 5 "rcd 2 ANY                  '   10k
!       !            "    5 DIGICOM BOARD        '-######-,   to
      >!11   14!>    GND- 7 " Used with the C-64
'-->+5v       """""""""     ///    "==== Unused 7404 input pins
are grounded.            ! 15 Pin 2 on Digicom board may not be
used.        /// We Hope this interface will help you all get
your IBM operating using BAYCOM.       Crawford Amateur Radio
Society PO BOX 653 Meadville PA.16335      Dedicated to keep
BUILDING and EXPERIMENTING part of HAM RADIO.
 DE WB3JDI @ K3ASI.#NWPA.PA.USA.

------------------------------

Date: 16 Aug 91 01:37:01 GMT From: [e-mail]
Subject: The great .NA controversy.... To: [e-mail]

References: to numerous to mention.

I think we need to stop mentioning solutions that are
impractical. These includes a change to the AX25 BBS address
format.

Many of you are underestimating the inertia of trying to change
the AX25 BBS software.  There isn't just one or two authors out
there anymore, there are about a hundred.  We also have many
systems running old code (such as MBL) that no one really
supports and we have a lot of mailboxes that interface to the
full service systems that are running EPROM firmware.  Do you
really expect every PK-232 mailbox owner to buy a new EPROM?

About the only thing we can do is come to a consensus on either
switching to W3IWI's proposal for 4 letter continent codes
(.NOAM) or adding something higher than the continent
(.USA.NA.AX25PBBS) If the BBS authors here on Internet and few
other key players get behind a new naming scheme, we may be able
to make it work.

Roy, AA4RE

enge @ almaden.ibm.com

------------------------------

End of Packet-Radio Digest V91 #208
****************************** Date: Sat, 17 Aug 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #209 To: packet-radio

Packet-Radio Digest         Sat, 17 Aug 91       Volume 91 :
Issue 209

Today's Topics:        'NA' country domain appears to be
non-unique (2 msgs)                    amateur <=> internet
gateways                     Got the hypercard stack info
              NA not unique etc etc etc                    The
great .NA controversy....

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 16 Aug 91 06:18:35 GMT From:
uhccux!uhunix1.uhcc.Hawaii.Edu![e-mail] Subject: 'NA'
country domain appears to be non-unique To: [e-mail]

While I support the proposal of switching to .NOAM as a 'quick
fix' (and have  implemented it locally), I also think the
long-term solution is to make the addresses look SIGNIFICANTLY
different.  This would alert users to the fact that the
addresses are used on different networks and therefore reduce
the likelihood of mail bouncing or going to some black hole.

The best way to do this is to change the separator character
from '.' to something else.  Changing the separator wont
increase the length of mail addresses.

The other proposed alternative (adding a higher-level domain
name) doesn't necessarily add a whole lot more information to
the address that a different separator could just as easily
accomplish.  Nor is it guaranteed that users will always tack on
the extra name.  The extra name also increases the length of the
mail address and may result in a larger number of potential
'variations' in mail addresses that must be checked for and
corrected at the gateways.--

Antonio Querubin   [e-mail] / [e-mail]
/ [e-mail]

------------------------------

Date: 16 Aug 91 16:54:30 GMT From:
news.mentorg.com!mntgfx![e-mail] Subject: 'NA' country
domain appears to be non-unique To: [e-mail]

Agree.  I personally simply don't care what set of characters
the bbs net uses to identify continents.  My software doesn't
either.

The 'problem' arose because a small number of people who use
both the internet and the bbs net made a mistake when addressing
some messages.  This will always occur ...

[  Again - sorry for using non-standard format, but my editor
does not  allow for a simple method to quote in the standard
manner.

  Lot's of folks assume everyone is on a system running unix.
I'm not.  No, not MSODS either.  It's Apollo Domain.  And yes,
sometime I'll have the free time to locate vi or emacs ... ]

   ...  Hank

From: [e-mail] (Roy Engehausen) Newsgroups:
rec.radio.amateur.packet Subject: The great .NA controversy....
Message-ID: <[e-mail]> Date: 16 Aug 91
01:37:01 GMT

References: to numerous to mention.

I think we need to stop mentioning solutions that are
impractical. These includes a change to the AX25 BBS address
format.

Many of you are underestimating the inertia of trying to change
the AX25 BBS software.  There isn't just one or two authors out
there anymore, there are about a hundred.  We also have many
systems running old code (such as MBL) that no one really
supports and we have a lot of mailboxes that interface to the
full service systems that are running EPROM firmware.  Do you
really expect every PK-232 mailbox owner to buy a new EPROM?

About the only thing we can do is come to a consensus on either
switching to W3IWI's proposal for 4 letter continent codes
(.NOAM) or adding something higher than the continent
(.USA.NA.AX25PBBS) If the BBS authors here on Internet and few
other key players get behind a new naming scheme, we may be able
to make it work.

Roy, AA4RE

enge @ almaden.ibm.com

--

Hank Oredson @ Mentor Graphics Internet     :
[e-mail] Amateur Radio: [e-mail]

------------------------------

Date: 16 Aug 91 14:20:37 GMT From:
mvb.saic.com!unogate!orion.oac.uci.edu!usc!cs.utexas.edu!helios!c
s.tamu.edu![e-mail] Subject: amateur <=> internet
gateways To: [e-mail]

In article <[e-mail]>, [e-mail]
(Alan Bloom) writes: |> In rec.radio.amateur.packet,
[e-mail] (Tim Hayes) writes: |>  |> >I am
interested in setting up a internet <-> amateur radio TCP/IP |>
>gateway. My question is: what are the legal issues involved? I
assume |> >that any amateur could legaly send data to internet
(ie mail) so long |> >as another person on internet was not
responding back. What mmust be |> >done to go the other way?
Does a person have to check all the internet |> >-> amateur
mail? What about telnet type sessions where there is a |>
>virtual circut? |>  |> Despite what others are likely to tell
you here on the net, it seems |> clear that no messages should
ever be transmitted on amateur radio |> without being checked
first by the amateur operator who first |> transmits them.

That looks correct to me, but doesn't completely answer the
question on internet<>AMPR gateways.  Despite what some people
are likely to say on the net, there are more services than just
mail. Two issues: mail from non-AMPR to AMPR; other services
(e.g., file  transfer, host logins) initiated from AMPR.

I would agree that general mail from non-AMPR networks cannot be
 automagically transmitted (or gatewayed to a PBBS).  What about
mail  known to be created by amateurs? (Either thru a wormhole
or by another gateway).

Other services deserve to be discussed, since not everything is
point to point messages.  What if I login to *my* non-AMPR host
from my home station?

Potential network services are possibly more complex than those
considered when the rules were made, but I don't see how the
rules forbid all those  services (except for the mail exception
noted above).

Cheers, Willis n5szf

|> AL N1AL

------------------------------

Date: 16 Aug 91 13:01:16 GMT From:
aramis.rutgers.edu!remus.rutgers.edu![e-mail] Subject:
Got the hypercard stack info To: [e-mail]

Hello everyone,

Thanks so much for all of your help. I've received all the
information  that I need to get the hypercard stacks. Thanks to
all of the below

John Woods - WB7EEL ;  Dick Kriss - KD5VU Jack Brindle - WA4FIB
; sidney markowitz and Antonio Querubin - who sent me Diana L.
Syriac newsletter regarding

       her hypercardstacks.

One thing that I must say is that you people are very nice  and
very helpfull. From the days when I was learning unix and I
asked question people would generally send me a RTFM message and
I was expecting something similar here.  Thanks for helping me
out.

Hopefully, I can be a ham soon and set up an internet <->
amateur gateway at rutgers with the help of Tim Hayes and Allan
Baum.

This fall I will be working for Network Services at Rutgers
University in New Brunswick as a student systems programmer.  At
one point there was some interest at Rutgers to become a
gateway.  I've read Warren Toomey's document (very informative
warren) and will present it to Network Services this fall.

Here are just a few questions that I have: Besides ka9q who used
to be in NJ what are the gateways in NJ?

Does there exist a visual map (for the US would be good enough
for starters) that shows all of these gateways?

What other package besides the ka9q software exists to run
tcp/ip over ham?  I heard about PA0GRI which is available from
ucsd.edu.

Thanks,

Marc--
_________________________________________________________________
_____________ Marc E. Fiuczynski    \\  Home: [phone]    Work:
[phone] [e-mail]      ||  UUCP:
{backbone}!rutgers!remus.rutgers.edu!mef [e-mail]    //
UUCP: {backbone}!att!mtuxo!mef

------------------------------

Date: 16 Aug 91 01:40:18 GMT From:
casbah.acns.nwu.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.
au!cs.mu.OZ.AU!mullian![e-mail] Subject: NA not unique etc
etc etc To: [e-mail]

In article <[e-mail]>
[e-mail] (Grant Willis VK5ZWI) writes:
>Hank and a couple of others want to move this discussion  >to
the BBS network. > >Two problems with this,  >1. It will be
painfully slow! >2. How do you propose to get the coverage of
the entire world? Here >in Australia it is quite unusual to see
ANY bulletins out of the USA. >We do see lots from Europe via
AsiaNet BUT that can be upto a month old.

Make that three problems: 3. Hams who are interested but have no
packet access at the moment   OR Internet folks who may be able
to give valuable advice

will be cut out of the discussion.

Like me :)

gja (vk3xmw, once and hopefully to be again active one day)

------------------------------

Date: 16 Aug 91 08:32:46 GMT From:
mcsun!ukc!axion!kitkat![e-mail] Subject: The great
.NA controversy.... To: [e-mail]

------------------------------

Date: (null) From: (null) I will send out a bulletin in GBR
tonight to let those people who haven't got access to the
Internet (the vast majority of UK packet users) know what is
being suggested and get their views. It might be worth one
person in each country doing a similar job.

Brian

Brian Lloyd Maintenance Section,             # e-mail :
[e-mail] Software Technology Division,        # Phone  :
[phone] SSTF Building, BTRL, Martlesham Heath,     # Fax
  : [phone] Ipswich, Suffolk. UK. IP5 7RE        # Packet :
G1NNA@GB7NNA.#31.GBR.EU

------------------------------

Date: 16 Aug 91 21:56:32 GMT From:
usc!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!aramis.rutg
ers.edu!remus.rutgers.edu!romulus.rutgers.edu![e-mail]
To: [e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail]>lu Subject
: Re: amateur <=> internet gateways

OK, that more or less answers my questions about mail through
gateways, but what about services like telnet and FTP? Should
these type of sevices be alowed through a gateway?

Here is the big problem- what if an amateur was to ftp something
like a X-rated GIF through the gateway (I know at 1200 baud it
would take forever..) Who would be held responsible for this
action the amateur or the license of the gateway?

In this case (as in any FTP session) there is no third party-
one amateur controls the data that is passed so long as the
remote site lets him. With all the anonymnous FTP sites around
there is NO WAY the gateway operator can have absolute control.

Also: in a telnet session how would one deal with the third
party trafic that could be created if a person checked his mail
on a remote system?

It all comes down to who is responsible for the data flow
through the gateway. If an amateur (other than the licensed ham
gateway owner) opens a path using that gateway is he resposible
or is the gateway station?

Many thanks to Willis Marti for his coments so far. If I can get
these legal problems straightened out there may soon be a fully
functional gateway at Rutgers University.

-Tim N2KBG--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~ | Tim Hayes                      | No beast so
fierce but knows some touch  | | Rutgers College of Engineering
| of pity, but I know none and therefore   | |
[e-mail]       | am no beast.
         | | [phone] [leave a msg]    |
                      |
_________________________________________________________________
____________

------------------------------

End of Packet-Radio Digest V91 #209
****************************** Date: Sun, 18 Aug 91 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #210 To: packet-radio

Packet-Radio Digest         Sun, 18 Aug 91       Volume 91 :
Issue 210

Today's Topics:

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 17 Aug 91 12:53:27 GMT From:
europa.asd.contel.com!emory!wa4mei!ke4zv![e-mail] To:
[e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]>O Reply-To :
[e-mail] (Gary Coffman) Subject : Re: amateur <=>
internet gateways

In article <[e-mail]>
[e-mail] (Tim Hayes) writes: >OK, that more or
less answers my questions about mail through >gateways, but what
about services like telnet and FTP? Should these >type of
sevices be alowed through a gateway? > >Here is the big problem-
what if an amateur was to ftp something like >a X-rated GIF
through the gateway (I know at 1200 baud it would take
>forever..) Who would be held responsible for this action the
amateur >or the license of the gateway? > >In this case (as in
any FTP session) there is no third party- one >amateur controls
the data that is passed so long as the remote site >lets him.
With all the anonymnous FTP sites around there is NO WAY the
>gateway operator can have absolute control. > >Also: in a
telnet session how would one deal with the third party trafic
that >could be created if a person checked his mail on a remote
system? > >It all comes down to who is responsible for the data
flow through the >gateway. If an amateur (other than the
licensed ham gateway owner) >opens a path using that gateway is
he resposible or is the gateway >station?

The person responsible for the transmitter that sends the dirty
bits is responsible, ie the guy whose call is on the gateway. In
a ftp or telnet session from the Internet, your gateway is
*originating* the  traffic into the amateur spectrum so you're
responsible for it's content.  You *could* have your system
change it's callsign to the requestor's  callsign, with a
different SSID, for the duration of the transfer and  claim that
he was operating the station under remote control rules. Then
*he's* responsible.

Wormhole repeaters, on the other hand, are no different than
split site repeaters of more conventional type. These can always
act under automatic control, and so far the FCC has held them
blameless for content. In this case the encapsulated AX25 frames
originated in the amateur spectrum and are relayed into the
amateur spectrum. The Internet is acting solely as a common
carrier no different than a phone line connecting a split site
repeater.

At least that's my interpretation.

Gary KE4ZV

------------------------------

End of Packet-Radio Digest V91 #210
****************************** Date: Mon, 19 Aug 91 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #211 To: packet-radio

Packet-Radio Digest         Mon, 19 Aug 91       Volume 91 :
Issue 211

Today's Topics:             'NA' country domain appears to be
non-unique                       DOSGATE by NM1D (2 msgs)
                 Hypercard stack info

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 17 Aug 91 15:40:16 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net Subject: 'NA' country domain appears to be non-unique
To: [e-mail]

In <[e-mail]> [e-mail] writes:

>[e-mail] (Dr. Eberhard W. Lisse) writes:

>> No this is not at all the case. It happens only because
someone put >> something like xxx.xxx.USA.NA into his signature
and someone else uses >> this to answer him. It has nothing at
all to do with any gateways >> (which may not even exist). >>
>>  >> regards, el >> ->> Dr. Eberhard W. Lisse    \          /
                ([e-mail]) >> Katatura State Hospital
  \        |     ([e-mail] works for small files) >> Private
Bag 13215          \ *    / ([e-mail] in
September) >> Windhoek, Namibia           ;____/      (no FTP
yet. [This is Africa :-)-O])

>Forgive a pragmatic response to a technical problem, >But I
have observed the above signature quite a number of times. >This
has raised a question for me. Considering the bandwidth of this
>discussion, and presuming that Dr. Lisse is getting our side of
this  >discussion also, and allowing his own above remark that
the problem is not  >gateways but users forgetting which network
they are on and mis-addressing;   >Then surely there is more
discussion than mis-addressed mail. >If that is the case,  could
it be we have a straw dog? I am not saying that  >the addressing
problems do not need to be rectified, but this discussion and
>its "wheel-spinning" are more of a problem than the problem.

Now that is fantastic !!!!

If I even participate in this discussion I am beeing accused.

Typical ...

el --

Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

Date: 18 Aug 91 17:28:53 GMT From: [e-mail]
Subject: DOSGATE by NM1D To: [e-mail]

Hello All i am testing a program by Rich Bono NM1D called
DOSGATE seems nice but need a newer version Does any one know
were i might find the latest version ?? Where does the callsign
NM1xxx ??? come from not seen this call before  DC0HK @
DB0LJ.DEU.EU DC0HK @ DC0HK.AMPR.ORG [e-mail]  any
should get me but BitNet is faster hi hi... Thanks All...
Barry...

------------------------------

Date: 19 Aug 91 04:48:08 GMT From:
apple!mips!swrinde!cs.utexas.edu!asuvax!anasaz!qip!john@RUTGERS.E
DU Subject: DOSGATE by NM1D To: [e-mail]

In article <[e-mail]>
[e-mail] (BARRY TITMARSH) writes: >Hello
All >i am testing a program by Rich Bono NM1D called DOSGATE
>seems nice but need a newer version >Does any one know were i
might find the latest version ?? >Where does the callsign NM1xxx
??? come from not seen this call before

Rich normally hangs out on USENET, show he may see this posting.
NM1D is a northeastern United States callsign - extra class.

--  John Moore HAM:NJ7E/CAP:T-Bird 381
{ames!ncar!noao!asuvax,mcdphx}!anasaz!john  USnail: 7525
Clearwater Pkwy, Scottsdale,AZ 85253
anasaz![e-mail] Voice: [phone]
Wishful Thinking: Long palladium, Short Petroleum Opinion:
Support ALL of the bill of rights, INCLUDING the 2nd amendment!
Disclaimer: The opinions expressed here are all my fault, and no
one elses.

------------------------------

Date: 19 Aug 91 02:15:36 GMT From:
aramis.rutgers.edu!remus.rutgers.edu![e-mail] Subject:
Hypercard stack info To: [e-mail]

Hello everyone,

A few days ago I asked about the hypercard stack that teaches
one how to become a ham. Since then I've received mail from many
people asking me to forward the info that I received. I felt
that it would be better if I posted it for the benefit of
everyone.

-Marc

Captured from rec.radio.amateur.misc by Antonio Querubin early
this month -- from [e-mail] (Diana Syriac, see signature
line for her info.)

LATEST VERSIONS:  Novice v3.3, Technician v3.5, General v2.3,
              Advanced v2.3, Extra v2.3

This is another announcement about the MacIntosh HamStacks which
I have created.  If you are not interested, press 'n' now.

I have created five HyperCard stacks to help people practice for
the written Amateur Radio tests.  There is one stack for each of
Novice,  Technician, General, Advanced and Extra questions.
Each stack is an interactive multiple-choice test, created from
the entire question pool for that class of license.  The test is
randomly generated, using the algorithms provided for each of
the tests from ARRL, so this is a real-live simulation of the
tests you will get in front of a VE.  There are some print
capabilities (you can print a test with a separate answer key,
but it's slow.  you can also print your results of how well you
did, along with the accompanying correct answer key) and at the
end of each test, it will tell you how well you did, allow you
to review the missed questions, and allow you to take another
randomly generated test.  If you can consistently score over 90
on the tests, it's almost a sure guarantee that you will be able
to take and pass the VE proctored test.

Note that these stacks will only work on a MacIntosh computer.
HyperCard version 1.2 or later is required; they were generated
with HyperCard version 1.2.  Because HyperCard data is NOT
stored in any ASCII form, there is no way that this data can be
used on other computers, including IBM PCs, so please don't ask
for the impossible.  Also, I do NOT have access to email these
stacks over the computerwaves, nor do I have ftp capability.
There  are a couple of sites which are supporting these stacks
via ftp, as follows:

These stacks are supported by ftp by Charley Kline,
[e-mail].  To  access the files, type "ftp
uxc.cso.uiuc.edu", log in as "anonymous", with  your email
address as the password.  Type "binary" at the prompt, then type
 "cd pub/ham-radio".  The five hamstacks are (eg):
novice-v3.2.hqx.Z,  technician-v3.3.hqx.Z, general-v2.2.hqx.Z,
advanced-v2.2.hqx.Z, and  extra-v2.2.hqx.Z (or similar names).
To retrieve one of the files, (for  example, the Novice one),
type "get novice-v3.2.hqx.Z".  When you're finished  retrieving
all the files you want, type "quit" to exit ftp.  Each file must
 be uncompressed before moving it to the Mac: "uncompress
novice-v3.2.hqx.Z".   You need to use Kermit to transfer the
files to the Macintosh.  The files  must then be un-binhexed by
UnStuffit, then unstuffed by UnStuffit.

The latest versions of the stacks are shown below, and are
compressed with Stuffit Classic.  UnStuffit is included on the
diskette.  These versions include modifications for NoCode (very
minor changes from v3.0 or v2.0).

Novice version 3.3

Technician version 3.5

General version 2.3

Advanced version 2.3

Extra version 2.3

If you wish to receive these PUBLIC DOMAIN stacks from me,
please send me a SASE (self addressed STAMPED envelope - 2
ounces postage = .52) and 800K  diskette.  I will no longer send
out the stacks unless the envelope has  sufficient postage for
return mail (in general, that means .52-.98, depending  on size
of envelope) and for those who send a standard business
envelope, I  take no responsibility for the condition of the
diskette through USnail.

Thank you for your attention.

Diana L. Syriac 49A Meadow Pond Drive Leominster, MA 01453

------------------------------
_________________________________________________________________
_____________ Marc E. Fiuczynski    \\  Home: [phone]    Work:
[phone] [e-mail]      ||  UUCP:
{backbone}!rutgers!remus.rutgers.edu!mef [e-mail]    //
UUCP: {backbone}!att!mtuxo!mef

------------------------------

Date: 17 Aug 91 15:50:50 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net To: [e-mail]

References <[e-mail]>, <[e-mail]>,
<[e-mail]>w Subject : Re: 'NA' country
domain appears to be non-unique

In <[e-mail]>
[e-mail] (steve harding TMP) writes:

>In article <[e-mail]> [e-mail]
(Kurt Freiberger) writes: >>In article <[e-mail]>,
[e-mail] (Brian Kantor) writes: [...]

>BTW ... It's Namibia

Opps, missed that :-)-O

el--

Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

Date: 17 Aug 91 15:45:31 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net To: [e-mail]

References <[e-mail]>, <[e-mail]>,
<[e-mail]> Subject : Re: 'NA' country domain
appears to be non-unique

In <[e-mail]> [e-mail] (Kurt
Freiberger) writes:

>In article <[e-mail]>, [e-mail] (Brian Kantor)
writes: >|>  >|> But wait!  You'll have to change the bbs
software!  After all, it >|> understands '.NA' now, not '.NOAM'
or '.MOON'.

>     Actually, no, that is data driven.

>|> >3.  Getting the BBS addresses to change the separator from
a "." to a ":" >|>  >|> Hmm.  You'd have to change the software
for this one too.  It would be a >|> nice clean change, though.

>  No, then some idiot would use the address on banyanmail or
VAXmail and  >we'd have the same problem.  or does Nambia have
the good taste not to use  >VAXen? 8-} >

Well,

actually VAXmail uses :: instead of : which it uses to
differentiate between the drive and the subdirectory. In any
case you can do everything under DECnet if you use enough pairs
of " (so twenty or so :-)-O

I 'grew up' on VMS but with the sanctions DEC didn't sell here
and now we don't have enough money to buy their hardware (as
much as I like it :-)-O)

If you want to unload your old VAX, be my guest...

el--

Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

Date: 17 Aug 91 15:34:40 GMT From:
zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!hippo!spel@uune
t.uu.net To: [e-mail]

References <20010@hel, <[e-mail]>,
<[e-mail]> Subject : Re: 'NA' country
domain appears to be non-unique

In <[e-mail]> [e-mail] (Sidney
Markowitz) writes:

>If the problem is that mail to [e-mail] physically goes
to >Namibia before being bounced, isn't there a solution
involving having >domain name servers that are better connected
that handle the NA domain >and know about the proper subdomains
there? I just checked how mail I >send would go to lisse.na, and
I find MX records at m2xenix.psg.com >and rain.psg.com. Looking
at the latter, I see MX entries for the >default names that
address an apparently bogus host named
>"no.such.host.in.namibia.na". It looks like it is supposed to
bounce >mail to bogus NA addresses without it going there.

>Dr. Lisse, I would suggest sending mail to
[e-mail] if >this isn't working, and to the
postmasters at the other domain name >servers that provide your
routing if it works, but is only installed >over there. From
these discussions, it seems like you need a solution >much
earlier than any change is going to occur in the amateur packet
>systems.

> -- sidney markowitz <[e-mail]>

Sidney,

Randy Bush asked for a host list for Namibia which I gave him
and we will keep all legal hosts in his MX data base and bounce
all others.

regards, el--

Dr. Eberhard W. Lisse    \          /
([e-mail]) Katatura State Hospital   \        |
([e-mail] works for small files) Private Bag 13215          \
*    / ([e-mail] in September) Windhoek,
Namibia           ;____/      (no FTP yet. [This is Africa
:-)-O])

------------------------------

End of Packet-Radio Digest V91 #211
****************************** Date: Tue, 20 Aug 91 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #212 To: packet-radio

Packet-Radio Digest         Tue, 20 Aug 91       Volume 91 :
Issue 212

Today's Topics:                         'NA' country domain
          amateur <=> internet gateways (3 msgs)
        Connecting via nodes                           DOSGATE
by NM1D                         NOS guru needed....
Packet Radio and Amateur Satellite Operation Query

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 19 Aug 91 19:46:47 GMT From:
usc!elroy.jpl.nasa.gov!swrinde!emory!wa4mei!nanovx!gloster!cutter
@ucsd.edu Subject: 'NA' country domain To: [e-mail]

>  el >> cutter >  > >Forgive a pragmatic response to a
technical problem, > >But I have observed the above signature
quite a number of times. > >This has raised a question for me.
Considering the bandwidth of this  > >discussion, and presuming
that Dr. Lisse is getting our side of this  > >discussion also,
and allowing his own above remark that the problem is not  >
>gateways but users forgetting which network they are on and
mis-addressing;  > >Then surely there is more discussion than
mis-addressed mail. >  > Now that is fantastic !!!! >  > If I
even participate in this discussion I am beeing accused. >  >
Typical ... >  > el  > -> Dr. Eberhard W. Lisse    \          /
                ([e-mail]) > Katatura State Hospital
 \        |     ([e-mail] works for small files) > Private
Bag 13215          \ *    / ([e-mail] in
September) > Windhoek, Namibia           ;____/      (no FTP
yet. [This is Africa :-)-O])

Au contraire, I am not accusing you of anything. My comment was
about the amount of bandwidth that we have inflicted on you
discussing the problem. Surely there are not as many fools
mis-addressing mail to you as well  intentioned people arguing
about addressing.

----------------------------------------------------------------c
[e-mail]           All jobs are equally easy
                            to the person who
              doesn't have to do the work.
                       Holt's law

------------------------------

Date: 19 Aug 91 19:01:43 GMT From:
hpl-opus!hpnmdla![e-mail] Subject: amateur <=>
internet gateways To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (Gary Coffman)
writes:

>The person responsible for the transmitter that sends the dirty
bits >is responsible, ie the guy whose call is on the gateway.
In a ftp or >telnet session from the Internet, your gateway is
*originating* the  >traffic into the amateur spectrum so you're
responsible for it's content.  >You *could* have your system
change it's callsign to the requestor's  >callsign, with a
different SSID, for the duration of the transfer and  >claim
that he was operating the station under remote control rules.
Then >*he's* responsible.

Nope.  The originator of a third party message is not allowed to
be operating under automatic control.  97.109(e), 97.115(b)

AL N1AL

------------------------------

Date: 20 Aug 91 01:29:49 GMT From: gatech!prism![e-mail]
Subject: amateur <=> internet gateways To: [e-mail]

In <[e-mail]> [e-mail] (Alan
Bloom) writes:

>In rec.radio.amateur.packet, [e-mail] (Gary Coffman)
writes:

>>You *could* have your system change it's callsign to the
requestor's  >>callsign, with a different SSID, for the duration
of the transfer and  >>claim that he was operating the station
under remote control rules. Then >>*he's* responsible.

>Nope.  The originator of a third party message is not allowed
to >be operating under automatic control.  97.109(e), 97.115(b)

Al, et al.

Yes--but.  From my understanding if using the requestor's
callsign, this presupposes that the originator is a ham.  If so,
then it is not third-party traffic--it is automatic control.

If the originator is just an internet user, then this is clearly
third-party traffic.  It seems clear that the analogy here is
like a cross-band repeater, it is not the repeater trustee who
is responsible for the traffic.

Or is it?  Anyone remember that 900 number ALLUS bulletin?

--Pete--  Peter L. Thomas (Junior AE) "Figures never lie, but
liars always figure." Georgia Institute of Technology, Atlanta
Georgia, 30332 Internet: {gt5139c,ce202a2}@prism.gatech.edu

------------------------------

Date: 20 Aug 91 03:06:03 GMT From:
usc!cs.utexas.edu!helios![e-mail] Subject: amateur <=>
internet gateways To: [e-mail]

In article <[e-mail]> [e-mail]
(Alan Bloom) writes: =In rec.radio.amateur.packet,
[e-mail] (Gary Coffman) writes: =>You *could* have your
system change it's callsign to the requestor's  =>callsign, with
a different SSID, for the duration of the transfer and  =>claim
that he was operating the station under remote control rules.
Then =>*he's* responsible.  =Nope.  The originator of a third
party message is not allowed to =be operating under automatic
control.  97.109(e), 97.115(b)

Al is probably correct IF the data is third-party. If the data
is the requestor's (by whatever appropriate definition), then
the referenced part 97 rules don't apply (Al actually posted the
content of those rules earlier.  Thanks!).

So what rules do apply?  Automatic control? What if the SSID
isn't changed? {remember, still no third party stuff}

Cheers, Willis n5szf

------------------------------

Date: 19 Aug 91 21:37:18 GMT From:
pyramid![e-mail] Subject: Connecting via nodes
To: [e-mail]

I've got a question for all you node hoppin' gurus out there...

Let's say I've connected to node "A", from there to node "B",
and from there to node "C".  Another ham has connected to node
"E", from there to node "D", and from there to node "C".

When I ask for "users" from node "C", it gives me the other
ham's callsign and tells me he's being heard through node "D".
If I want to attempt to talk to him, how do I do it?  Do I have
to connect to node "D", find out he came in through node "E",
connect to it, and then try to connect?

In other words, when you're at a node several hops away and you
see that there is another user on that node who has also made
several hops to get there, do you have to chase him/her all the
way home?

+----------------------------------------------------------------
----------+ | Andre Molyneux   KA7WVV     "Insert your favorite
disclaimer here"       |
+-----------------------------------------+----------------------
----------+ |      -=-------- PYRAMID TECHNOLOGY CORP |Internet:
                      | |    ---===------ 1295 Charleston Road
 |  [e-mail]            | |  -----=====---- Mountain
View, CA       |Packet:                         |
|-------=======-- [phone]          |
ka7wvv@n0ary.#nocal.ca.usa.na |
+-----------------------------------------+----------------------
----------+

------------------------------

Date: 19 Aug 91 16:55:39 GMT From: mdisea![e-mail]
Subject: DOSGATE by NM1D To: [e-mail]

In article <1991Aug19.044808.11719@anasaz> john@anasaz (John
Moore) writes: > >Rich normally hangs out on USENET, show he may
see this posting. NM1D is >a northeastern United States callsign
- extra class.

Careful here. How does the callsign show geographic area? It was
originally issued in the Northeast, but is Rich still there? For
example, as hard as you try, you will have a difficult time
finding me in the Southeast US, no matter how bad I may wish to
move back (for a while, at least)...

Jack Brindle, WA4FIB Bothell, WA (as in Northwest US).

------------------------------

Date: 19 Aug 91 21:02:51 GMT From:
usc!sdd.hp.com!uakari.primate.wisc.edu!caen!news.cs.indiana.edu!n
oose.ecn.purdue.edu!en.ecn.purdue.edu![e-mail] Subject:
NOS guru needed.... To: [e-mail]

    Title says it all.

    Need help configuring NOS for 3C503 etherlink II and Kiss
TNC's. I copied most of the stuff from simtel-20, but some
modules seem to be missing or contradict the manual.

    Thanks,

        Tim        [e-mail]

------------------------------

Date: 19 Aug 91 22:10:43 GMT From: rockyd!hcx![e-mail]
Subject: Packet Radio and Amateur Satellite Operation Query To:
[e-mail]

I just passed the codeless Tech exam and am in the process of
upgrading to  General or more advanced privileges.  My interests
are in amateur satellite and  packet radio operation, in
particular using the new PACSAT/LOSATs launched last  year.
Being new to amateur radio in general and amateur satellite in
particular, I would appreciate any comments people may have.  A
specific query  I have concerns the equipment needed for such
operation.  For example, is a 2m  FM transceiver with a simple
1/2 half wave vertical antenna and a 70 cm to 2m  receiving
converter sufficient for the J-mode of operation on the PACSATs.
  Also, what type of packet modem is needed for this type of
operation.  All  suggestions are greatly
appreciated.----------------------------------------------

Jeffrey Yuan -
[e-mail]-------------------------------------
---------

------------------------------

Date: 19 Aug 91 18:07:48 GMT From:
elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!helios!cs.tamu.edu!willi
[e-mail] To: [e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: amateur <=>
internet gateways

At the risk of violating the "don't ask the FCC" rule, I'm going
to continue this in a public forum...

In article <[e-mail]>, [e-mail]
(Gary Coffman) writes: |> In article
<[e-mail]>
[e-mail] (Tim Hayes) writes: [stuff deleted]
|> >Here is the big problem- what if an amateur was to ftp
something like |> >a X-rated GIF through the gateway (I know at
1200 baud it would take |> >forever..) Who would be held
responsible for this action the amateur |> >or the license of
the gateway?

Without discussing which specific file formats would be obscene
(I mean, what about IBM VSAM files. **ugh**), let's just say
there are data that, if transmitted over AMPR, would violate
either the no obscenity/profanity or the no business rules.
There is a separate concern over data from a non-amateur (not
addressed yet).

In a perfect world, the questionable data would not be sent & I
don't think there would be a question as to the appropriateness
of the link. The real question is "who's responsible?". |> > |>
>In this case (as in any FTP session) there is no third party-
one |> >amateur controls the data that is passed so long as the
remote site |> >lets him. With all the anonymnous FTP sites
around there is NO WAY the |> >gateway operator can have
absolute control.

Not necessarily true.  You may implement an access control
mechanism that would be transparent for 'authorized' sites yet
prevent access to/from some other list of sites/protocols.

[more stuff deleted] |> The person responsible for the
transmitter that sends the dirty bits |> is responsible, ie the
guy whose call is on the gateway. In a ftp or

How about we try an analogy with more mature technology... the
autopatch. Two situations: (1)You own an open repeater with
phone patch.  From my HT, I establish a call to my house, where
my answering machine picks up the line and, to my chagrin,
transmits a profanity over the air.  Who's responsible? (2)Same
as above, except that you operate a closed repeater to which
I've been given access after acknowledging that it was possible
for my actions to cause violations of FCC rules.  Or maybe it's
a club repeater & you're the trustee and we're both members.

{I have *opinions*, but no real *answers* for both situations.
I'd appreciate comments.}

[even more deleted] |> Wormhole repeaters, on the other hand,
are no different than split

I agree.

|> At least that's my interpretation. Thanks. |>  |> Gary KE4ZV

Willis n5szf Internet: [e-mail] PBBS: n5szf@w5ac which
is in SouthTeXas which is in TeXas which is in the
UnitedStatesofAmerica  which is in NorthAmerica.

------------------------------

Date: 19 Aug 91 20:39:21 GMT From:
sdd.hp.com!cs.utexas.edu!asuvax!anasaz!qip![e-mail] To:
[e-mail]

References <[e-mail]>,
<1991Aug19.044808.11719@anasaz>,
<[e-mail]> Subject : Re: DOSGATE by NM1D

In article <[e-mail]> [e-mail] (Jack
Brindle) writes: ]In article <1991Aug19.044808.11719@anasaz>
john@anasaz (John Moore) writes: ]> ]>Rich normally hangs out on
USENET, show he may see this posting. NM1D is ]>a northeastern
United States callsign - extra class. ] ]Careful here. How does
the callsign show geographic area? It was originally ]issued in
the Northeast, but is Rich still there? For example, ]as hard as
you try, you will have a difficult time finding me in the
]Southeast US, no matter how bad I may wish to move back (for a
while, at ]least)... The fact that it is a northeaster US
callsign doesn't mean he is THERE.--  John Moore
HAM:NJ7E/CAP:T-Bird 381
{ames!ncar!noao!asuvax,mcdphx}!anasaz!john  USnail: 7525
Clearwater Pkwy, Scottsdale,AZ 85253
anasaz![e-mail] Voice: [phone]
Wishful Thinking: Long palladium, Short Petroleum Opinion:
Support ALL of the bill of rights, INCLUDING the 2nd amendment!
Disclaimer: The opinions expressed here are all my fault, and no
one elses.

------------------------------

Date: 20 Aug 91 05:31:58 GMT From:
dog.ee.lbl.gov!hellgate.utah.edu!caen!sol.ctr.columbia.edu!emory!
wa4mei!km4ba![e-mail] To: [e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: amateur <=>
internet gateways

In <[e-mail]> [e-mail] (Gary
Coffman) writes:

>The person responsible for the transmitter that sends the dirty
bits

What does a dirty bit look like???

And how do you tell it is dirty?  :-)

Now I have seen the old codgers with tty's and their "dirty"
paper tapes of naked women made out of letters. You can usually
tell dirty baudot by the sound. (IE: if you hear it, it is
usually Miss November.) :)

 Alan Barrow  km4ba | I've seen things you people wouldn't
believe. Attack [e-mail] | ships on fire off the
shoulder of Orion. I watched                    | C-beams
glitter in the dark near the Tannhauser gate. ..!gatech!kd4nc!
| All those moments will be lost in time -         km4ba!alan |
like tears in rain. Time to die.          Roy Batty

------------------------------

End of Packet-Radio Digest V91 #212
****************************** Date: Wed, 21 Aug 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]> Errors-To: [e-mail]
Reply-To: [e-mail] Precedence: Bulk Subject:
Packet-Radio Digest V91 #213 To: packet-radio

Packet-Radio Digest         Wed, 21 Aug 91       Volume 91 :
Issue 213

Today's Topics:                amateur <=> internet gateways (2
msgs)                      Any 23 cm kits available?
           Communications to USSR                  Gracillis &
PackeTen info, please                Increasing thruput with the
PK-232 ???           Looking for ASCII manuals for some packet
modems         NA appears non unique - 4 letter designator
proposal                     Packet-Radio Digest V91 #212
                  packet <> internet
sending UDP broadcast

Send Replies or notes for publication to:
<[e-mail]> Send subscription requests to:
<[e-mail]> Problems you can't solve
otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
 (by FTP only) from UCSD.Edu in directory
"mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all
text herein consists of personal comments and does not represent
the official policies or positions of any party.  Your mileage
may vary.  So
there.-----------------------------------------------------------
-----------

Date: 20 Aug 91 19:12:43 GMT From:
usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!k
e4zv![e-mail] Subject: amateur <=> internet gateways To:
[e-mail]

In article <[e-mail]> [e-mail]
(Alan Bloom) writes: > >Nope.  The originator of a third party
message is not allowed to >be operating under automatic control.
 97.109(e), 97.115(b)

Al, my copy of the rules says part 97.115 prohibits the
transmission of music. Could you post the quoted sections. I
know I need to get a new copy of the rules.

Automatic transmission of third party traffic is legal in
repeater and auxiliary service. The described operation could be
considered auxiliary service.

Gary KE4ZV

------------------------------

Date: 20 Aug 91 21:38:22 GMT From:
hpl-opus!hpnmdla![e-mail] Subject: amateur <=>
internet gateways To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (Peter L.
Thomas, AE) writes:

Re: Internet - to - amateur packet gateways.

>Yes--but.  From my understanding if using the requestor's
callsign, this >presupposes that the originator is a ham.  If
so, then it is not third-party >traffic--it is automatic control.

The only way this would work is if every potential (amateur)
message originator were considered a control operator.  This is
a bit hard to swallow since these "control operators" would
typically not even know where the station was located or what
frequency it is operating on.

AL N1AL

------------------------------

Date: 20 Aug 91 10:50:06 GMT From:
mcsun!news.funet.fi!cc.tut.fi![e-mail] Subject: Any
23 cm kits available? To: [e-mail]

There are dozens of kits available for 2 m and 70 cm from
various manufacturers. However, I have never seen anything like
a 23 cm FM receiver and transmitter kit in advertisements. I
know that e.g. Down East Microwave makes nice transverter kits
but are there any simple kits available for just FM use.

The idea is to find an easy way to interlink our node, mailbox
and cluster on 23 cm to get rid of all the forward traffic on
user port frequencies.

Any info appreciated.

73 de Benjamin OH3BK

------------------------------

Date: 21 Aug 91 00:08:00 GMT From: [e-mail]
Subject: Communications to USSR To: [e-mail]

Our department has a professor touring Russia. He has not been
able to contact home for several days. His Name is Ron Noyes and
he is on a tour inspecting grain storage. His  itinerary shows
he should be in Leningrad or Kazan(sp).

Any help or ideas would be appreciated.

 Thanks in advance Gordon  Couger  N5QAQ Agricultural
Engineering Oklahoma State U. 114 Ag Hall Stillwater, OK 74078
[e-mail] 405 744 6514 day 744 2794 night

------------------------------

Date: 20 Aug 91 08:16:00 GMT From: [e-mail]
Subject: Gracillis & PackeTen info, please To:
[e-mail]

Hello friends !

We are now planning update of YU3 packet network, and PackeTen
is obviously best solution for mountaintop nodes. Our nodes are
really on mountains, and there is no way to put PCs with disks
to loactions. But, something had to be done in near future [I
hope @$#@#$@ stop fighting in YU].

I send E-mail to Gracillis [Bdale confirmed they really received
it], phoned to them and left message into voice machine, but up
to now we have no information from them.

These days we found source for few pieces of 68302, so maybe it
is best to start own project. While our ideas are little
different as PackeTen, I would like to keep HW as compatible as
possible, so software can be ported with minimal efforts from
one to another 68302 based machine.

Can somebody mail memory mapping of PackeTen ? I guess this is
main compatibility question. So far, I have no plans for multi
CPU interface, to keep machine as simple as possible.

How about software ? Is PackeTen software available in source ?
It is based on KA9Q code, so probably they should follow same
copyright policy ?

Thanks !

  73 Iztok, YU3FK

packet: YU3FK @ YT3A   [.YU3.EU.anything you like] e_mail:
[e-mail]

------------------------------

Date: 20 Aug 91 13:58:07 GMT From: [e-mail]
Subject: Increasing thruput with the PK-232 ??? To:
[e-mail]

Anyway I can set up 2 PK-232 TNC's to work  ** Full duplex **
with eachother on VHF at 1200 baud of up the PACLength to a
value greater than 256 ?? Any sugjestions are welcomed. 73, Rich
=================================================================
=========== Internet:   [e-mail] Packet:
4X1DA @4Z4SV.ISR.EU Voice mail: 972-2-897589 FAX:
972-2-897677 Snail:      P.O. Box 6457 Jerusalem, Israel
=================================================================
===========

------------------------------

Date: 20 Aug 91 15:46:46 GMT From:
bloom-beacon!eru!hagbard!sunic!liuida!isy!lysator.liu.se!jonas@uc
bvax.berkeley.edu Subject: Looking for ASCII manuals for some
packet modems To: [e-mail]

Is it possible for someone to arrange with posting of ASCII
manuals for packet modems MFJ-1278, PK-1232 and PK-2232 ?

Please make your posting to this newsgroup!

73, Jonas/SM5LZM    [e-mail]

------------------------------

Date: 21 Aug 91 05:08:05 GMT From:
munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!greed
.teaching.cs.adelaide.edu.au![e-mail] Subject: NA
appears non unique - 4 letter designator proposal To:
[e-mail]

Following the discussions on what to do about the .NA problem I
have obtained from Tom W3IWI a copy of his paper on 4 letter
continent/location designators. Since this has been so highly
discussed, I thought it would be appropriate to pass this on to
the rest of the net.

Tom has given permission for me to post this...

The article comes from the 9th ARRL Network Conference
Proceedings.

     Some comments on the "H"ierarchical Continent Address
Designator                        _________________

                         Tom Clark, W3IWI
 6388 Guilford Road                        Clarksville, MD 21029

At the risk of opening Pandorra's Box, this note suggests a
change in the 2-character continent designator portion of the
PBBS "H" hierarchical address field. An example would be the
North America .NA portion of the packet address,

                         K9DOG @ W6SIX.DE.USA.NA

Let me state at the outset that I'm not convinced that we need
to use the continent field. It seems to me that the country
field by itself is adequate and that the packet BBSes can easily
keep track of all the countries in the world. Let me also state
that many of the issues addressed here arise because of constant
confusion between the functions of addressing and routing.

The correct continent to assign to many countries of the world
is confusing and/or ambiguous. To cite some examples of problems
which have already been identified:

   - 5B4=Cyprus in the Mediterranian is listed by the IARU (for
WAC)     and the ITU as Asia. Ditto 4X=Israel and JY=Jordan in
the middle     East.

   - Both TA=Turkey and and the Soviet Union have part of their
coun-     ties in Europe and part in Asia. 8Q6=Maldives is
listed as both     Africa and Asia. Several other countries are
also "split".

   - Although DU=Philipines and YB=Indonesia are regarded as
Asiatic     countries, the are listed as Oceania, along with
Australia and     Hawaii. If you venture to 9M=Malasia, you may
be in either Ocea-     nia or Asia.

   - The Central American and Carribean countries are nearly all
part     of North America, including YV0, but not 9Y. Anyone
care to guess     what continent the southern part of HP=Panama
is in?

If the purpose of the continent portion of the "H"ierarchical
address is to facilitate delivery of messages, then it is
illogical to route Israeli and Jordanian traffic through the
Orient. It is illogical to make automated routing decisions for
messages to Turkish amateurs based on whether the addressee is
on the east or west side of the Straits of Bosporus.

Stations in Israel and Cyprus already face this dilemma. Rather
than using a .AS Asian address, they choose to use .EU European
designator to avoid having their packet mail routed via the
Orient. Some have suggested the use of a new continent
designator other than .AS; One suggestion has been .ME (Middle
East) but this has a serious conflict with the state of Maine.

The Central Americans and the Carribean are both "legally" .NA
but feel they need a separate geographic identity and both areas
have independently suggested the use of .CA but this would
conflict with .CA state. All this leads to my suggestion that
the present 2-letter continent designator must be changed.
Either:

 (1) The present 2-character designator should be dropped
because it     it not really needed and there are too many
ambiguities. Users     will always try to use address quirks to
force routing, so don't     give them the chance to fould things
up. The computers at the     international mail gateways can
easily handle the entire DXCC     list.

                    - or -

 (2) A new logical regional designator which allows
sub-continent     sized regions should be adopted.

If a new, more flexible scheme is to be adopted, I'd suggest
that new 4character designators be chosen:

  -  .NOAM, .SOAM, .CEAM, .CARB replacing the present .NA & .SA
and     solving the Central American and Carribean problem,

  -  .ASIA replacing .AS for the Orient,

  -  .MDLE for the middle-eastern countries like 4X, JY etc.,

  -   Oceania divided into smaller areas like .NPAC, .SPAC,
.AUST,

  -  The Indian ocean (now partly in .OC and partly in .AF) be
desig-     nated .INDI,

  -  .AFRI replacing .AF for Africa and .EURO replacing .EU for
   Europe,

  -  .ANTR added for Antarctica,

  -  Additional new designators added as needed for
sub-continent     sized logical areas.

NOAM replaces NA for the USA and Canada CEAM is added for
CEntral AMerica including Mexico and Panama CARB is added for
the CARriBean island countries, including 9Y SOAM replaces SA
AFRI replaces AF EURO replaces EU MDLE is added for the MiDdLe
East including 5B4, 4X, HZ, JY etc. ASIA replaces AS including
YB and 9M AUST replaces AU NPAC replaces OC for the PACific
Islands North of the Equator (including KH6) SPAC replaces OC
for the South PACific INDI is added for the INDIan Ocean islands
(VQ9, 3B8 etc) ANTR is added for ANTaRctica

This scheme affords the logic of a 2-character field (.MD) for
the "state", 3 characters (.DEU) for the country, & 4 (.AFRI)
for the continent/subcontinent and avoids conflicts between
state-sized areas and continents. Who knows, a few decades hence
a 5 character field (.EARTH, .VENUS) may be needed too!

-Grant Willis (VK5ZWI), Electronic Engineering Student. |
Adelaide University AARNet/Internet1:
[e-mail]        | South AUSTRALIA
AARNet/Internet2: [e-mail] | My
views are my own, AmPRNET: VK5ZWI@VK5TTY.#SA.AUS.OC
[44.136.171.11]     | not the Uni's!

------------------------------

Date: 20 Aug 91 16:58:50 GMT From: [e-mail]
Subject: Packet-Radio Digest V91 #212 To: [e-mail]

>>The person responsible for the transmitter that sends the
dirty bits > >What does a dirty bit look like???   > >And how do
you tell it is dirty?  :-) > >Now I have seen the old codgers
with tty's and their "dirty" >paper tapes of naked women made
out of letters. You can usually >tell dirty baudot by the sound.
(IE: if you hear it, it is usually >Miss November.) :) > Right
On. Only old men and socks are dirty, NOT bits!    Walt - K2WK
:^)

------------------------------

Date: 21 Aug 91 06:31:10 GMT From:
orion.oac.uci.edu!ucivax!jarthur!elroy.jpl.nasa.gov!swrinde!zapho
d.mps.ohio-state.edu!sol.ctr.columbia.edu!emory![e-mail]
Subject: packet <> internet To: [e-mail]

Sorry, it looks like I came into this a little late and only
caught the politics, not the logistics.

I'm only on the  internet side and want to send e-mail back and
forth to a friend only on the packet side. Is there a general
way to do this?

--  Ken Mandelberg      | [e-mail]          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP  Dept of
Math and CS | [e-mail]              NON-DOMAIN BITNET
Atlanta, GA 30322   | Phone: Voice [phone], FAX [phone]

------------------------------

Date: 21 Aug 91 03:33:50 GMT From:
walter!salt!faline![e-mail] Subject: sending
UDP broadcast To: [e-mail]

How does one send a UDP broadcast over ka9q?

I'm using Ip_addr as the lsock.address and my own port as both
lsock.port and fsock.port, with a broadcast address of
128.96.0.0 as fsock.address but ip_route() gets called with a
packet from some weird address to a weird address:

source addr: 0.20.45.98 dest addr:  198.129.80.196

any ideas or is there an easy way to send udp broadcasts with
ka9q??

thanks in advance, cheers, Tony

------------------------------

Date: 20 Aug 91 19:02:55 GMT From:
usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!k
e4zv![e-mail] To: [e-mail]

References <[e-mail]>,
<1991Aug19.044808.11719@anasaz>,
<[e-mail]> Reply-To : [e-mail]
(Gary Coffman) Subject : Re: DOSGATE by NM1D

In article <[e-mail]> [e-mail] (Jack
Brindle) writes: > >Careful here. How does the callsign show
geographic area? It was originally >issued in the Northeast, but
is Rich still there? For example, >as hard as you try, you will
have a difficult time finding me in the >Southeast US, no matter
how bad I may wish to move back (for a while, at >least)...

Come home Jack, all is forgiven. :-)

Gary KE4ZV

------------------------------

Date: 21 Aug 91 01:48:53 GMT From:
swrinde!mips!dimacs.rutgers.edu!aramis.rutgers.edu!remus.rutgers.
edu!romulus.rutgers.edu![e-mail] To: [e-mail]

References <[e-mail]>,
<[e-mail]>,
<[e-mail]> Subject : Re: amateur <=>
internet gateways

Gary ke4zv writes: >Now transmitting a gif file isn't
transmitting obscene, indecent, or >profane *words*, or
*language*, but perhaps *meaning*. This falls into >the same
grey area as transmitting MIDI sequences being construed as
>transmitting music. Since I believe that the *intent* of both
these rules, >music prohibition and obscenity prohibition, are
aimed at material sent >in the clear and receivable by the
general public, computer files and >MIDI files don't seem to
fall under the intent of the rules.

Ok, I admit it was a bad example- maybe x-rated gifs would be
legal to transmit. *I* won't be the one to test this idea. But
the same question could be applied to something like the 1-900
message on packet:

what if a buisness related message was mailed to a person who
had an account on some internet machine was read by that person
while he had a telnet session into his internet computer from
his amateur packet station? I am of the oppinion (at this point
anyway) that the amateur has now comitted a violation of part 97
since HE was the control operator and knew that the posibility
existed that something illegal could be put on the air through
his actions.

It would be the same as the autopatch example- you COULD order a
pizza though a repeater autopatch, but no one would do that
(right- I've heard it done myself once.) You might also check
your answering machine at home- not a buisness related action
and completely leaglbut in doing so what if someone left an
offer to buy something from you and included the price they
would pay? Now you have violated the rules. You should not have
taked the chance that this message would not have been there,
but who is now responsible?

The answer is not that the person should not have called because
answering machine messages would be third party traffic- if this
were true then ANY call to a house with an answering machine
would become a violation when the outgoing announcement began to
play (its a recording- a message- NOT a real person, thus it is
third-party)

just my 2 cents--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~ | Tim Hayes   N2KBG              | No beast so
fierce but knows some touch  | | Rutgers College of Engineering
| of pity, but I know none and therefore   | |
[e-mail]       | am no beast.
         | | [phone] [leave a msg]    |
                      |
_________________________________________________________________
____________

------------------------------

Date: 20 Aug 91 16:24:30 GMT From:
mvb.saic.com!unogate!orion.oac.uci.edu!usc!cs.utexas.edu!oakhill!
nddsun1![e-mail] To: [e-mail]

References <[e-mail]>,
<[e-mail]>, <[e-mail]>
Subject : Re: amateur <=> internet gateways

In article <[e-mail]> [e-mail]
(Willis Marti) writes: >At the risk of violating the "don't ask
the FCC" rule, I'm going to >continue this in a public forum...

Dave Sumner's editorial was directed at FORMAL inquiries to the
FCC. They are required to make an "on the record" response o
such queries and can be in hot water if they allow something
that later proves abusive. As a result such inquiries ALWAYS
(not just the FCC) will be biased negatively just from a "CYA"
viewpoint.

Dave's comments don't apply to discussions among ourselves, nor
to "informal" inquiries which won't be held against the person
responding afterwards.

>In article <[e-mail]>, [e-mail]
(Gary Coffman) writes: >Without discussing which specific file
formats would be obscene (I mean, >what about IBM VSAM files.
**ugh**), let's just say there are data that, >if transmitted
over AMPR, would violate either the no obscenity/profanity >or
the no business rules.  There is a separate concern over data
from >a non-amateur (not addressed yet).

Of course ther is always the question of "just what IS obscene".
I don't think there exists an answer beyond "what is upsetting
to those in power at present".

>How about we try an analogy with more mature technology... the
autopatch. >Two situations: >(1)You own an open repeater with
phone patch.  From my HT, I establish a >call to my house, where
my answering machine picks up the line and, to >my chagrin,
transmits a profanity over the air.  Who's responsible? >(2)Same
as above, except that you operate a closed repeater to which
I've >been given access after acknowledging that it was possible
for my actions >to cause violations of FCC rules.  Or maybe it's
a club repeater & you're >the trustee and we're both members.

In both cases though there is a "live" control operator who
"originates" and "controls" the transmissions. While you won't
find any regulatory authority who admits this, there is a
"reasonable and prudent" rule which applies. If you hear the bad
words and shut it down as best you are able, then you have done
all that is "reasonable and prudent". If, however, you sit back
and "enjoy the show" for 10 or 15 minutes then you should get
gigged!