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

Text File | 1993-12-31 | 93.8 KB | 2,073 lines

2-Jun-87 04:50:23-EDT,1030;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Jun 87 04:50-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 2 Jun 87 02:28:56 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 2 Jun 87 02:28:49 EDT
From: ames!pyramid!ncc![e-mail]
Received: by RUTGERS.EDU (5.54/1.14) with UUCP
    id AA08118; Tue, 2 Jun 87 02:28:53 EDT
Received: by mtune.ATT.COM (smail2.3)
    id AA26595; 2 Jun 87 02:28:32 EDT (Tue)
Received: by ihnp4.ATT.COM id AA29561; 2 Jun 87 01:26:08 CDT (Tue)
Received: by pembina.alberta.UUCP (4.12/3.14)
    id AA26147; Sat, 30 May 87 21:56:52 mdt
Received: by ncc.UUCP (smail2.3) id AA04477; 30 May 87 21:27:43 MDT (Sat)
To: [e-mail]
Subject: administrivia
Date: 30 May 87 21:27:43 MDT (Sat)
Message-Id: <[e-mail]>

Would you please drop me from the list - we are now getting a reliable
feed via usenet. Thanks.

Lyndon  VE6BBM
 2-Jun-87 06:25:15-EDT,1030;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Jun 87 06:25-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 2 Jun 87 02:28:56 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 2 Jun 87 02:28:49 EDT
From: ames!pyramid!ncc![e-mail]
Received: by RUTGERS.EDU (5.54/1.14) with UUCP
    id AA08118; Tue, 2 Jun 87 02:28:53 EDT
Received: by mtune.ATT.COM (smail2.3)
    id AA26595; 2 Jun 87 02:28:32 EDT (Tue)
Received: by ihnp4.ATT.COM id AA29561; 2 Jun 87 01:26:08 CDT (Tue)
Received: by pembina.alberta.UUCP (4.12/3.14)
    id AA26147; Sat, 30 May 87 21:56:52 mdt
Received: by ncc.UUCP (smail2.3) id AA04477; 30 May 87 21:27:43 MDT (Sat)
To: [e-mail]
Subject: administrivia
Date: 30 May 87 21:27:43 MDT (Sat)
Message-Id: <[e-mail]>

Would you please drop me from the list - we are now getting a reliable
feed via usenet. Thanks.

Lyndon  VE6BBM
 2-Jun-87 22:56:05-EDT,799;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Jun 87 22:56-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 2 Jun 87 19:40:59 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 2 Jun 87 19:00:22 EDT
Received: from 7328.Span by Jpl-VLSI.ARPA with VMSmail ;
    Tue, 2 Jun 87 15:27:29 PDT
Date:    Tue, 2 Jun 87 15:27:29 PDT
From: [e-mail]
Message-Id: <[e-mail]>
Subject: This is a test of the WA7MBL V3.13 PBBS server mode
To: [e-mail]
X-St-Vmsmail-To: JPLLSI::"[e-mail]"

    This message was originated at the WA7MXZ-2 V3.13 PBBS and forwarded
automatically to the net. Thanks for the test. 73, Bob WA7MXZ
 3-Jun-87 03:41:29-EDT,4624;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Jun 87 03:41-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 02:23:53 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 02:23:40 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA04924; Tue, 2 Jun 87 23:26:05 PDT
Return-Path: <ll-xn!husc6!cmcl2!philabs!westpt![e-mail]>
Message-Id: <[e-mail]>
Date: 2 Jun 87 15:14:06 GMT
From: ll-xn!husc6!cmcl2!philabs!westpt![e-mail] (Bill Gunshannon)
To: [e-mail]
Subject: Filing a petition with the FCC


This message has a couple of different reason behind it.  I have waited to
see if the situation would improve but have seen no action either for or
against yet.  The problem is HF packet and international BBS traffic.
Originally everything went smoothly and international packet ran just like
VHF local packet.  Then the question of International Third Part Traffic
came up, and all communications between US BBS's and other countries stopped.
The assumed third party nature of BBS traffic doesn't seem to bother BBS's
in europe as I watch people from various countries using BBS's in Germany,
England and Sweden regularly.  Having started in ham radio in Germany (DA1WO)
I have many acquaintances in europe that I would like to re-establish
contact with.  Not being in an ideal place for big antenna installations or
high power, the logical alternative is packet messages sent from BBS to BBS.
But now because of what may be another case of regulations that haven't
kept up with technology we are falling behind the rest of the world in another
way.  We have always prided ourselves on how we "self regulate" amateur radio
yet we seem to have a much stricter definition of "Third Party" than our
european counterparts.

Therefore I have decided it is time I stopped sitting back and waiting for
the ham community to do something about it.  If I can acquire the necessary
information I am going to petition the FCC for a redefinition of "Third
Party" under Part 97.

In order to do this I am going to solicit the assistance of everyone who reads
this.  I need two things.  The first is probably the easiest. The second
may be the most dificult task I have ever undertaken.

First:   I need to know the format required for a formal filling with the
     FCC.  If anyone has any experience with this assitance to include
     an example copy if possible would be greatly appreciated. Also
     information like the right person and place to address it and how
     many copies to send.  As you can see I am a novice at tackling this
     leg of the bureaucracy.

Second:  This is by far the most difficult part.  I need input from the
     ham community on what they think "third party" means and what
     they think it should mean in regards to amateur radio.  Hopefully
     I will get enough information to make a reasonable presentation
     to the FCC and get packet communications flowing world-wide the
     way it should.
     The reason for world distribution is that I am hoping to get input
     from other countries hams as to how the BBS situation is handled
     accross international boundries when even VHF is affected.  I would
     also like copies of the appropriate excerpts from different countries
     ham regulations to use as reference.  If english translations are
     not available I can have most any language translated locally.  Also
     if anyone knows of anything from the ITU specifically addressing
     the "third party" issue I would be interested.

As you can see from this I am soliciting input from the whole ham world.  I
want to hear it all pro or con on the issue.  If I am able to put together
a proposal for the FCC I will post a copy of it here as well and then any
further comments can be sent along to me and of course to the FCC if it gets
to that stage.  I will also try sending it out on Packet with the widest
possible dispersion.  Lets see if we can catch up to the rest of the world
in this very important aspect.

All help and comments greatly appreciated.

73's

bill gunshannon

UUCP:      {philabs,phri}!westpt!bill        PHONE:     [phone]
US SNAIL:  Martin Marietta Data Systems      RADIO:     KB3YV
       USMA, Bldg 600, Room 26           AX.25      KB3YV @ WA2RKN
       West Point, NY  10996


 3-Jun-87 03:42:02-EDT,3520;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Jun 87 03:42-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 02:29:05 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 02:28:45 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA05012; Tue, 2 Jun 87 23:30:55 PDT
Return-Path: <rutgers!princeton!idacrd![e-mail]>
Message-Id: <[e-mail]>
Date: 2 Jun 87 13:55:04 GMT
From: rutgers!princeton!idacrd![e-mail] (Bob McGwier)
To: [e-mail]
Subject: Re: TNC-1 lack of updates
References: <[e-mail]>

in article <[e-mail]>, [e-mail] says:
>
>RE: KA4WDK Packet Radio TNC
>    So far the best software out for the TNC-1 is the DED V1.2. If you want to
>ROM's for TNC-2's and everyone with a TNC-1 is waiting in the wings. With the
>changes in protocols (TCP/IP etc) and Networking it is difficult to start
>designing the software to update the TNC-1 and set up its command structure to
>match the Howie code only to see a change in the protocol and be obsolete over
>rammers to develop code. I am still looking for a solution myself to the TNC-1
>hassle, even if it's to put COSI (still not released?) or NET/ROM code into
>it and put it on a hill as a digipeater network device. As far as TAPR's part
>in development, WHERE IS THE NNC (Network Node Controller) that was to be
>released soon??????
> Bob Wood WA7MXZ

I am porting TCP/IP to the NNC and I won't say when but it will be
<<REAL SOON NOW>>,

The TCP/IP crowd is COMPLETELY supporting the TNC-1.  We have Kiss code
written by Marc Kaufman WB6ECE and the your PC can run TCP/IP and use it
to do your netowrking.  I know of noone trying a simple IP only port to
the TNC-1.  You probably won't need it.  The link layer in TCP/IP can
be AX.25 and the stuff from Ron Raikes will work just fine.

COSI has not been heard here and I live near the guys who announced its
availability for May (its June 2).

Phil is going to support NET/ROM style subnets so have at it.
(If you don't know yet Phil KA9Q is the author of the major portion of
the TCP/IP package for the PC).

KA2BQE and I have NNC's and are really banging on the IP code to get it
to fit into the "CP/M" model running on the NNC with 54K TPA.  If you
have a very nice "C" compiler that works on the NNC (SB-180) and would
like to help out give me a call at

(609)-443-8963

and by nice I mean knows about and uses the MMU on the 64180 and
addresses all of the 512k.


We are having a meeting in Princeton, NJ on June 13 here (sorry VHF/UHF
types who wanted attend) at IDACRD.  This is to erect an IP switched
IP net paralleling EASTNET.  We already have participants from Maryland,
Penn., NJ,NY, Long Island (:-) :-))  Conn. and these guys are mostly
"do-ers".  Come if you want to ask questions etc.

Harold lost (1) the use of a "multi thousand" dollar development
environment for the 6809 (2) the partners working with him on the code
supplying the device drivers "pulled out".  TAPR couldn't justify
spending close to $10000 for this development environment to support the
thousand or so TNC-1's.  They did spend almost that much on the NNC and
I for one refuse to see that investment go completely to waste.

Lyle is sending me the prototype multimodem board and enough memory
chips to "fill it up"


Bob N4HY


 3-Jun-87 13:52:59-EDT,1528;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Jun 87 13:52-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 11:51:52 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 11:51:01 EDT
Date:     Wed, 3 Jun 87 11:46:03 EDT
From: [e-mail]
To: Bill Gunshannon <ll-xn!husc6!cmcl2!philabs!westpt![e-mail]>
Cc: [e-mail]
Subject:  Re:  Filing a petition with the FCC
Message-Id:  <[e-mail]>

Bill,

You are tackling a potentially explosive issue, as you say. Procedures to
petition the FCC are well established and some of us have done that in the
past. However, on this issue I doubt you will get very far using the FCC
as the point of attack, since they will quickly point out that there should
be no problem for those countries which have a third-party agreement with the
US. Such agreements pointedly do not exist for countries in Europe. When I
was operating from the UK in the early seventies, the regulations were
positively paranoid to the point that only the license holder could speak in
the microphone and no third-party traffic of any kind was allowed. I therefore
suspect the issue is not the FCC, but the radio regulatory bodies of other
countries.

I suggest the proper forum for this issue is the IARU; although, having said
that, there would have to be a lot of education and persuasion to move that
mob anywhere.

 3-Jun-87 16:56:05-EDT,1376;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Jun 87 16:56-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 13:58:23 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 13:58:10 EDT
Message-Id: <[e-mail]>
Date: Wed, 3 Jun 87 13:50:52 EDT
From: Bob Clements <[e-mail]>
Subject: Re: TNC-1 lack of updates
To: [e-mail]
Cc: [e-mail]

> Date: 2 Jun 87 13:55:04 GMT
> From: Bob McGwier <rutgers!princeton!idacrd![e-mail]>
> Subject: Re: TNC-1 lack of updates

> ...
> Harold lost (1) the use of a "multi thousand" dollar development
> environment for the 6809 (2) the partners working with him on the code
> supplying the device drivers "pulled out".  TAPR couldn't justify
> spending close to $10000 for this development environment to support the
> thousand or so TNC-1's.
> ...
> Bob N4HY


Good grief! What sort of environment do they think they need?!?
The WA8DED TNC-1 code was written on a CP/M box with a $100 assembler/linker.

And unless I'm mistaken, Ron (WA8DED) offered the use of his code, with
perfectly good device drivers, to TAPR.

This sounds like the sort of excuse I have used when I really didn't
want to do a job.

/Rcc
(K1BC)

 3-Jun-87 18:15:02-EDT,983;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Jun 87 18:15-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 15:41:37 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 15:41:18 EDT
Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
    id AA12516; Wed, 3 Jun 87 15:42:58 EDT
Received: by enea.se (5.51/1.34)
    id AA09174; Wed, 3 Jun 87 09:19:09 +0200 (MET)
Received: by erix.ericsson.se (5.51/4.7)
    id AA24420; Wed, 3 Jun 87 08:51:20 +0200
Date: Wed, 3 Jun 87 08:51:20 +0200
Message-Id: <[e-mail]>
From: enea!kiera.ericsson.se![e-mail] (Thomas Nilsson ERA/KI/B/TKR Sweden)
Subject: sendlist @ mit
To: [e-mail]

Would you please delete me from the list at mit.
I am receiving two copies of everything. The other one is from the
European packet list at axis.

Thomas SM0KBD
 3-Jun-87 21:22:23-EDT,1032;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Jun 87 21:22-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 20:03:45 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 3 Jun 87 20:02:43 EDT
Received: by sdcsvax.UCSD.EDU (5.57/5.0)
    id AA20057 for [e-mail]; Wed, 3 Jun 87 13:40:26 PST
Date: Wed, 3 Jun 87 13:40:26 PST
From: [e-mail] (Brian Kantor)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TNC-1 lack of updates

The TNC-1 code (I'm told) was developed on an HP64000 In-Circuit
Emulator Workstation, in Pascal, except for the device driver code,
which was apparently written in assembler.  I hear there are also
problems in getting the device driver code - no details on that,
rumour only.

I suspect that Pascal compilers for the 6809 are somewhat rare.

    Brian Kantor    WB6CYT  UC San Diego
 4-Jun-87 16:27:50-EDT,1832;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Jun 87 16:27-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 4 Jun 87 14:17:59 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 4 Jun 87 14:17:39 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA01755; Thu, 4 Jun 87 11:18:50 PDT
Return-Path: <apollo![e-mail]>
Message-Id: <[e-mail]>
Date: 3 Jun 87 14:16:00 GMT
From: apollo![e-mail] (John Hays)
To: [e-mail]
Subject: 3rd party rules (was: Filing a petition with the FCC)
Keywords: NPRM FCC format
References: <[e-mail]>

Bill,

>From my point of view the regulations should read (in plain english),
something like:

    1. Messages from/to non-amateur licensee(s) are 3rd party
       traffic.  The amateur licensee placing such messages
       into the the amateur radio service is responsible to
       guarantee that 3rd party agreements are not violated.

    2. Messages relayed from one amateur licensee to another
       amateur licensee should not be considered 3rd party
       traffic.  The relaying station is not directly responsible
       for content, however, if a message appears to be in
       violation of the amateur radio service rules, the
       licensee of a relaying station should make all reasonable
       attempts to prevent its retransmission.

John Hays, KD7UW

--
John D. Hays, Consultant             UUCP: ...!decvax!wanginst!apollo!hays
Corporate Systems Engineering              ...!uw-beaver!apollo!hays
Apollo Computer Inc.                 CIS: 72725,424  {weekly}
           !MY OPINIONS, not Apollo's!


 5-Jun-87 00:50:03-EDT,1627;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 5 Jun 87 00:50-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 4 Jun 87 22:37:57 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 4 Jun 87 22:37:15 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA22669; Thu, 4 Jun 87 19:38:27 PDT
Return-Path: <rutgers!princeton!idacrd![e-mail]>
Message-Id: <[e-mail]>
Date: 4 Jun 87 17:22:36 GMT
From: rutgers!princeton!idacrd![e-mail] (Bob McGwier)
To: [e-mail]
Subject: Re: TNC-1 lack of updates
References: <[e-mail]>

in article <[e-mail]>, [e-mail] (Brian Kantor) says:
>
> The TNC-1 code (I'm told) was developed on an HP64000 In-Circuit
> Emulator Workstation, in Pascal, except for the device driver code,
> which was apparently written in assembler.  I hear there are also
> problems in getting the device driver code - no details on that,
> rumour only.
>
> I suspect that Pascal compilers for the 6809 are somewhat rare.
>
>       Brian Kantor    WB6CYT  UC San Diego

This is correct as told to me by Harold Price.  This workstation is
expensive and though porting to another environment would be possible,
I think that Bob (K1BC) is correct, they just "didn't have the heart"
for it.  I also own a TNC-1 and will be using it in a "KISS" mode on
tcp/ip.  Thanks to Kaufman, mine isn't obsolete.  If Raikes volunteered
the use of his code, fine, get it and finish it. :-)

Bob N4HY


 5-Jun-87 01:23:58-EDT,5418;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 5 Jun 87 01:23-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 4 Jun 87 22:36:44 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 4 Jun 87 22:36:11 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA22649; Thu, 4 Jun 87 19:37:07 PDT
Return-Path: <labrea!Umunhum![e-mail]>
Message-Id: <[e-mail]>
Date: 3 Jun 87 20:41:51 GMT
From: labrea!Umunhum![e-mail] (Paul A. Flaherty)
To: [e-mail]
Subject: Re: Filing a petition with the FCC
Keywords: NPRM FCC format
References: <[e-mail]>

An admirable goal, but you should realize what you're up against...

1) The format for a request for rulesmaking is contained in the ARRL FCC
    rulebook (ie part 97).  You might want to pick up the most recent
    (orange) copy.

2) As to getting the FCC to redefine 3rd party traffic, I'm afraid that might
    be more difficult.  Third party traffic definitions come from the ITU
    meetings, which of course heavily attended by prople who are trying to
    make money doing the same thing we're doing for fun.

    Given that, your chances of getting the FCC to consider an alternate
definition would seem to be slim.  However, I would consider the odds much
tougher in Europe, where you're competing with the PTTs.  Oddly enough, you
mention that the Europeans are a bit looser on this, which could be used as
an argument for doing it here...

    Bill brings up an excellent point, the topic the following FLAME:

+Proton - Plasma Cutting Torch FLAME mode on+

    Many moons ago, a group of innovative hackers discovered a mode of
communications that totally mystified the general public.  As a reward, the
government stole their toy from them, giving them a small chunk as a
"token of appreciation".  And, of course, within that chunk, the govenment
told them what they could and could not do.  One of the things that they were
told to do was "advance the state of the art".  They were also told not to
do anything that the government couldn't understand.  "But how can we advance
the state of the art if you have to understand everything we're doing?"
"Oh, just use your own best judgement.  'Good Amateur Practice', and all that.
By the way, if we think you're violating the rules, we cut your nards off
first, and then ask questions..."

    Many moons later, another group of innovative hackers discovered a
new mode of communications.  But this time, they had to deal with the
government beforer they could implement their ideas.  They had to submit
RFRMs, RSTAs, fifteen talents of silver, and a few firstborn.  And to this,
the magnanimous goverment agency replied: "Sure, go ahead.  Just don't use it
for anything practical."

    Does the regulation of amateur radio benefit anyone?

1) Er, why yes, it benefits the ham communtity by keeping out people who don't
    belong.

1x) Wrong!  A good number of amateurs started out as pirates(ask Wayne Green).
    Moreover, the FCC has proven to be very lax in removing nusiances from
    the air (eg, 2m in any large metro area).  Suprisingly, the FCC says
    that it is understaffed and overworked, and yet it seems to have tons
    of time to harass packeteers shipping uuencoded files over the air...

2) Well, um, it prevents the hams from interfering with commercial services.

2x) Horsepucky.  The FCC's own figures show that, if anything, incidents of
    the commercial services interfering with ham radio are more prevalant.
    Moreover, this creates an illusion which is shattered whenever
    somebody next door flicks on their TV set, and sees dah dit dah dit
    dah dah dit dah...

3) Gee, well, we have to do something to protect the investment made by the
    commercial powers that be...

3x) Ahh..., now we're getting to the heart of the matter.  Protecting
    investment.  Now come off it, would people really make all of those
    calls to Aunt Sadie in Melbourne if they had to pay for it?  Of course
    not!  Moreover, as the recect butchering of ATT has shown, people are
    willing to pay more for quality communications.  Frankly, the same
    logic which allowed MCI and the others into the long distance game
    applies; if we can provide the service that people want (scratchy,
    fading connections just a few DB above the noise floor...), then
    whatever happens to the commercials is their own fault.


    Being regulated buys us nothing.  And costs too much.  As far as I'm
concerned, anybody with the knowledge to pass Amateur - Written tests should
be allowed to do pretty well anything they damn well please.  Period.

    As experimenters, that bandwidth is a birthright, and not a privilege.
Personally, I'm tired of trying to deal with that band of bureaucrats
(who gave us an experimental allocation for packet radio, an allocation
shared {as we later found out} with a taxi company...), and tired of living
in fear of the pink slip in the mail.

Nuke the PRB!

+click+

--
-=Paul Flaherty, N9FZX           |POM(4)        Stanford Unix           POM(4)
Computer Systems Lab -- Stanford |NAME: pom -- phase of moon detector
ARPA: [e-mail]  |SYNOPSIS: device pom at uba0 csr 0166666
UUCP: shasta!n9fzx!paulf@umunhum |BUGS: Crashes only on gibbous phase.


 5-Jun-87 02:15:00-EDT,1110;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 5 Jun 87 02:14-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 4 Jun 87 22:39:42 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 4 Jun 87 22:39:09 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA22683; Thu, 4 Jun 87 19:40:04 PDT
Return-Path: <labrea!Shasta![e-mail]>
Message-Id: <[e-mail]>
Date: 4 Jun 87 15:12:02 GMT
From: labrea!Shasta![e-mail] (Marc Kaufman)
To: [e-mail]
Subject: Re: TNC-1 lack of updates
References: <[e-mail]>

I have sent the 6809 cross assembler written by Cal Teague at Stanford
to Bdale (winfree![e-mail]) for inclusion with a future
release of TCP/IP and KISS code.  I have previously sent him a 'mikbug'
type of debugger/loader for the TNC1 -- So, all you hackers, now you
have as much development environment as you need.  Let's see some code.

Marc Kaufman ([e-mail])


 6-Jun-87 09:27:44-EDT,1596;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Jun 87 09:27-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 6 Jun 87 06:43:14 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 6 Jun 87 06:43:00 EDT
Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
    id AA24618; Sat, 6 Jun 87 06:43:42 EDT
Received: by enea.se (5.51/1.34)
    id AA24243; Sat, 6 Jun 87 11:08:21 +0200 (MET)
Received: by kuling.UU.SE (4.40/SMI-3.0DEV3)
    id AA06647; Fri, 5 Jun 87 22:39:16 -0100
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Filing a petition with the FCC
In-Reply-To: Your message of Wed, 3 Jun 87 11:46:03 EDT.
         <[e-mail]>
Date: 05 Jun 87 22:39:12 N (Fri)
From: Anders Klemets <enea!kuling![e-mail]>

> I therefore
> suspect the issue is not the FCC, but the radio regulatory bodies of other
> countries.

I can't understand how it would be easier making all European countries
sign a third party agreement with the FCC than making the FCC adopt the
rules followed in Europe.

John Hays describes how the new regulations should be. Almost the
same regulations are used in Europe. If there were paranoid regulations in
the UK during the early the seventies they have probably changed a long
time ago.

--
    Anders Klemets, Sikvagen 51, S-135 41 Tyreso, Sweden
    UUCP/ARPA:      [e-mail]
    Phone:          [phone]
    Packet:         SM0RGV @ SK0TM
 6-Jun-87 11:13:50-EDT,1596;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Jun 87 11:13-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 6 Jun 87 06:43:14 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 6 Jun 87 06:43:00 EDT
Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
    id AA24618; Sat, 6 Jun 87 06:43:42 EDT
Received: by enea.se (5.51/1.34)
    id AA24243; Sat, 6 Jun 87 11:08:21 +0200 (MET)
Received: by kuling.UU.SE (4.40/SMI-3.0DEV3)
    id AA06647; Fri, 5 Jun 87 22:39:16 -0100
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Filing a petition with the FCC
In-Reply-To: Your message of Wed, 3 Jun 87 11:46:03 EDT.
         <[e-mail]>
Date: 05 Jun 87 22:39:12 N (Fri)
From: Anders Klemets <enea!kuling![e-mail]>

> I therefore
> suspect the issue is not the FCC, but the radio regulatory bodies of other
> countries.

I can't understand how it would be easier making all European countries
sign a third party agreement with the FCC than making the FCC adopt the
rules followed in Europe.

John Hays describes how the new regulations should be. Almost the
same regulations are used in Europe. If there were paranoid regulations in
the UK during the early the seventies they have probably changed a long
time ago.

--
    Anders Klemets, Sikvagen 51, S-135 41 Tyreso, Sweden
    UUCP/ARPA:      [e-mail]
    Phone:          [phone]
    Packet:         SM0RGV @ SK0TM
 9-Jun-87 15:03:32-EDT,4563;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 Jun 87 15:03-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 9 Jun 87 12:58:44 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 9 Jun 87 12:58:21 EDT
Received: from 7328.Span by Jpl-VLSI.ARPA with VMSmail ;
    Tue, 9 Jun 87 09:59:05 PDT
Date:    Tue, 9 Jun 87 09:59:05 PDT
From: [e-mail]
Message-Id: <[e-mail]>
Subject: Features of WA7MBL PBBS V 3.13
To: [e-mail]
X-St-Vmsmail-To: JPLLSI::"[e-mail]"

The following message was posted by Tom Clark on Compuserve Hamnet:

Sb: MBL 3.13 BBS
Fm: Tom Clark W3IWI 71260,3640
To: all

   Some of you have been hearing rumors about the 3.13 WA7MBL BBS code.
I don't want to steal Jeff's thunder, and I'm sure he will want to
make additional comments, but I will confirm that it does exist in
the 'Alpha' test mode right now. Copies are on the air at WA7MBL and
W3IWI. So far the test looks good, so you might want to get your
'order' in to K7PYK since it will be available "REAL SOON NOW". Here
are some of the major enhancements that tickle my fancy:
   (1) Full support of NET/ROM and other high-level "switch" networks.
This feature works well and we have forwarded quite a few pieces
of mail to west coast stations thru the Wormhole+NET/ROM network.
A minor bug was fixed tonite with a patch Jeff sent to me today.
   (2) A 'SERVER' function has been added which should make for a 'bridge'
between the TCP/IP network and the 'mere mortal' BBS network. A message
arriving at a BBS addressed like SERVER @ W3IWI will be filed into
an ASCII file in entirety for 'export' to the 'other' network. A new
feature has been added to the FWD.BBS file which allows any entries
in an 'import' ASCII file to be converted to normal BBS messages.
A TCP/IP SMTP program (perhaps running in another DoubleDOS partition?)
could read from/write to this pair of files to provide the internet
gateway function.
   (3) The forwarding files have been revised extensively. Time fields
now have a lot more flexibility. You can specify multiple times like
05,07,11-17,22, and you can specify that only mail pieces smaller
than a certain size will be forwarded during specific hours. The "P"
fields can now have time flags so that your TNC can have a different
"personality" at different times. Wild cards are now supported in the
individual routing entries, so that you can forward all NTS messages
except for those to your state, or mail for all but the following
5 calls.
   (4) A nice feature for the users who get frustrated at long lists
of mail headers has been added. If a message went thru 8 intermediary
BBSs (and all used one of the standard message header protocols),
then the "R" command will list one line at the top of the message with
Path:BBS1!BBS2!BBS3!BBS4!BBS5!BBS6!BBS7!BBS8 and the long string
of headers are suppressed. If the user is really a masochist and
wants to see all the gory details, her can read the message with
the "V" (for VERBOSE!!!) command and see what he used to see.
   (5) For those who use the "guest" mode to restrict users to only
being able to read their own mail or send mail, you now have the
option of not making the messages they generate be "hidden" (I use
this feature at IWI since my main role is as a server for all the
other area BBSs).
   (6) A guest user can no longer type [MBL312] to defeat the guest
user mode.
   (7) Two digit SSIDs are now supported throughout.
   (8) DesqView is supported, although DesqView 2.0 is untested.
   (9) Some bugs in the bulletin broadcast feature have been fixed.
Both the originator and sender are marked as having the bulletin.
   (10) The bug that caused premature disconnects during reverse
forwarding has been fixed, along with all other known "gotcha" bugs.
   (11)The distribution disk also contains the nice user-oriented
tutorial written by N4CAK and WA6ERB from RMPRA.
   I've had it on the air since last Saturday and am pleased. Once again
Jeff has done a fantastic job. PLEASE!!!!!! don't flood him with requests
for copies because he still has a little clean-up work to do. I would
guess that you will be able to get copies in about 2 weeks. Just FYI,
Jeff and I are transfering files/bug reports/etc. using a high speed
DECnet channel we have available out of hours. The US SNAIL would be
totally unsuitable for the task!
73, Tom
 9-Jun-87 15:45:09-EDT,4563;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 Jun 87 15:45-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 9 Jun 87 12:58:44 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 9 Jun 87 12:58:21 EDT
Received: from 7328.Span by Jpl-VLSI.ARPA with VMSmail ;
    Tue, 9 Jun 87 09:59:05 PDT
Date:    Tue, 9 Jun 87 09:59:05 PDT
From: [e-mail]
Message-Id: <[e-mail]>
Subject: Features of WA7MBL PBBS V 3.13
To: [e-mail]
X-St-Vmsmail-To: JPLLSI::"[e-mail]"

The following message was posted by Tom Clark on Compuserve Hamnet:

Sb: MBL 3.13 BBS
Fm: Tom Clark W3IWI 71260,3640
To: all

   Some of you have been hearing rumors about the 3.13 WA7MBL BBS code.
I don't want to steal Jeff's thunder, and I'm sure he will want to
make additional comments, but I will confirm that it does exist in
the 'Alpha' test mode right now. Copies are on the air at WA7MBL and
W3IWI. So far the test looks good, so you might want to get your
'order' in to K7PYK since it will be available "REAL SOON NOW". Here
are some of the major enhancements that tickle my fancy:
   (1) Full support of NET/ROM and other high-level "switch" networks.
This feature works well and we have forwarded quite a few pieces
of mail to west coast stations thru the Wormhole+NET/ROM network.
A minor bug was fixed tonite with a patch Jeff sent to me today.
   (2) A 'SERVER' function has been added which should make for a 'bridge'
between the TCP/IP network and the 'mere mortal' BBS network. A message
arriving at a BBS addressed like SERVER @ W3IWI will be filed into
an ASCII file in entirety for 'export' to the 'other' network. A new
feature has been added to the FWD.BBS file which allows any entries
in an 'import' ASCII file to be converted to normal BBS messages.
A TCP/IP SMTP program (perhaps running in another DoubleDOS partition?)
could read from/write to this pair of files to provide the internet
gateway function.
   (3) The forwarding files have been revised extensively. Time fields
now have a lot more flexibility. You can specify multiple times like
05,07,11-17,22, and you can specify that only mail pieces smaller
than a certain size will be forwarded during specific hours. The "P"
fields can now have time flags so that your TNC can have a different
"personality" at different times. Wild cards are now supported in the
individual routing entries, so that you can forward all NTS messages
except for those to your state, or mail for all but the following
5 calls.
   (4) A nice feature for the users who get frustrated at long lists
of mail headers has been added. If a message went thru 8 intermediary
BBSs (and all used one of the standard message header protocols),
then the "R" command will list one line at the top of the message with
Path:BBS1!BBS2!BBS3!BBS4!BBS5!BBS6!BBS7!BBS8 and the long string
of headers are suppressed. If the user is really a masochist and
wants to see all the gory details, her can read the message with
the "V" (for VERBOSE!!!) command and see what he used to see.
   (5) For those who use the "guest" mode to restrict users to only
being able to read their own mail or send mail, you now have the
option of not making the messages they generate be "hidden" (I use
this feature at IWI since my main role is as a server for all the
other area BBSs).
   (6) A guest user can no longer type [MBL312] to defeat the guest
user mode.
   (7) Two digit SSIDs are now supported throughout.
   (8) DesqView is supported, although DesqView 2.0 is untested.
   (9) Some bugs in the bulletin broadcast feature have been fixed.
Both the originator and sender are marked as having the bulletin.
   (10) The bug that caused premature disconnects during reverse
forwarding has been fixed, along with all other known "gotcha" bugs.
   (11)The distribution disk also contains the nice user-oriented
tutorial written by N4CAK and WA6ERB from RMPRA.
   I've had it on the air since last Saturday and am pleased. Once again
Jeff has done a fantastic job. PLEASE!!!!!! don't flood him with requests
for copies because he still has a little clean-up work to do. I would
guess that you will be able to get copies in about 2 weeks. Just FYI,
Jeff and I are transfering files/bug reports/etc. using a high speed
DECnet channel we have available out of hours. The US SNAIL would be
totally unsuitable for the task!
73, Tom
10-Jun-87 01:45:25-EDT,1440;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jun 87 01:45-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 9 Jun 87 22:25:27 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 9 Jun 87 22:25:08 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA16049; Tue, 9 Jun 87 19:26:49 PDT
Return-Path: <ihnp4!homxb!houxm!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 9 Jun 87 18:22:03 GMT
From: ihnp4!homxb!houxm!hou2d![e-mail] (J.BEATTIE)
To: [e-mail]
Subject: Emergency Operation of PC/XT
Keywords: PC XT Portable Emergency

I am looking for information on ways to adapt my very
compatible PC clone to a 12 volt power source.  I am a member
of my local Emergency Management Amateur Radio group and we
are looking at ways to run these toys in vehicles in
conjunction with packet radio.

The first issue is the basic power supply: what's on each pin?

Is any of it AC ?

If we can get away without having to supply a low level (or
any level AC) source then we can probably cook up something
for any DC voltage required.

We don't want to use one of those power inverters...they're
hogs on juice !

Anybody done this before ?

Any thoughts ?

Thanks, Gordon Beattie   houxm!hou2d!n2dsy
             201-615-4772


10-Jun-87 19:21:11-EDT,4893;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jun 87 19:21-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 10 Jun 87 14:47:38 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 10 Jun 87 14:47:16 EDT
Message-Id: <[e-mail]>
Received: from UNLVM(BITMAIL) by MITVMA (Mailer X1.23) id 9002;
      Wed, 10 Jun 87 12:42:59 EDT
Received: by UNLVM (Mailer X1.24) id 2343; Wed, 10 Jun 87 09:02:35 CDT
Date:         Wed, 10 Jun 87 08:55:50 CDT
From: Michael Ruhrdanz <AGRI003@UNLVM>
Subject:      Re: Emergency Operation of PC/XT
To: [e-mail]
In-Reply-To:  Message of 9 Jun 87 18:22:03 GMT from
 <IHNP4!HOMXB!HOUXM!HOU2D![e-mail]>


   This is in regard to your question about power supply voltages
and other related information about an IBM-PC power supply.  The
following information is for a real IBM-PC 63.5 watt power supply.  The
voltages and pin-outs are the same for a 135 watt supply, but the
current is naturally greater.  The job you describe should not be too
difficult, depending upon the amount of protection you build into your
supply.

    --CURRENT (AMPS)--   REGULATION (TOLERANCE)
VOLTS   MINIMUM    MAXIMUM        +%       -%
 +5.0     2.3         7.0          5        4
 -5.0     0.0         0.3         10        8
+12.0     0.4         2.0          5        4
-12.0     0.0         0.25        10        9

PIN-OUTS ON THE MOTHERBOARD
   The following is a list of the power supply pins on the motherboard
of an IBM-PC.  This list starts with the pin closest to the back of the
computer, and ends with the pin closest to the front.  I suggest you
confirm these pins with your compatable with a VOM.

-- Plug closest to the back of the computer --
Power Good  (see note below)
Key
+12v
-12v
ground
ground

-- Plug closest to the front of the computer --
ground
ground
-5v
+5v
+5v
+5v

-- Description --

   The power supply for an IBM-PC is a dc-switching supply designed for
continuous operation at 63.5 watts.  It has a fused 120 VAC input and
provides 4 regulated DC output voltages.  These outputs are OVER-VOLTAGE,
OVER-CURRENT, OPEN-CIRCUIT, and SHORT-CIRCUIT protected.  If a DC
overload or over-voltage condition occurs, all dc outputs are shut down
as long as the condition exists.

   The +5 VDC powers the logic on the system board and the diskette
drives and allows approximately 4A for the adapters in the system-unit
expansion slots.  The +12VDC is designed to power the system's dynamic
memory and the internal 5-1/4 inch diskette drive motors.  It is
assumed that only one drive is active at a time.  The -5VDC level is
designed for dynamic memory bias voltages; it tracks the +5 and +12
very quickly at power-on and has a longer decay on power-off than the
+5 and +12 outputs.  The +12 and -12 are also used for powering the
EIA drivers on the communications adapters.  All four power levels are
pussed across the five system-unit expansion slots.

-- Misc. comments --

   On over-voltage, the power supply is designed to shut down all outputs
when either the +5 or +12 output exceeds 200% of its maximum rated
voltage.  On over-current, the supply will turn off if any output
exceeds 130% of its nominal value.

POWER-GOOD signal

   When the power supply is turned on after it has been off for a
minimum of 5 seconds, it generates a power-good signal which indicates
that there is adequate power for processing.  When the 4 output
voltages are above the minimum sense levels, as described below, the
signal sequences to a TTL-compatible UP level (2.4v to 5.5v), which
is capable of sourcing 60uA.  When any of the 4 voltages is below its
minimum sense level or above its maximum sense level, the power good
signal will be a TTL compatible DOWN level (0.0 to 0.4v) capable of
sourcing 500uA.  The power good signal has a turn-on delay of 100ms
after the output voltages have reached their respective minimum sense
levels.

 output                   Nominal Sense Level
voltage           under-voltage        over voltage
  +5                  +4.0                 +5.9
  -5                  -4.0                 -5.9
 +12                  +9.6                +14.2
 -12                  -9.6                -14.2

   I hope this information helps - it came right out of an IBM
technical reference manual.  Some of the information about the uses of
the voltages are slightly out dated, but the values are correct.  The
larger power supplies (135 watts) have a LOT MORE +5VDC (about 15A if I
remember correctly), a little more +12VDC (about 5A I think), and the
negative supplies are about the same (more would not hurt).

Michael Ruhrdanz
Section Emergency Coordinator
Nebraska Section
10-Jun-87 19:55:58-EDT,770;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Jun 87 19:55-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 10 Jun 87 18:00:28 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 10 Jun 87 18:00:11 EDT
Received: from nssdc.Span by Jpl-VLSI.ARPA with VMSmail ;
    Wed, 10 Jun 87 14:59:03 PDT
Date:    Wed, 10 Jun 87 14:59:03 PDT
From: [e-mail]
Message-Id: <[e-mail]>
Subject: Does this link work?
To: [e-mail]
X-St-Vmsmail-To: JPLLSI::"[e-mail]"

WA7MXZ told me that this was the route to get to youse guys from SPAN.
Just testing to see if it really works.
73 de Tom, W3IWI
12-Jun-87 01:44:12-EDT,2702;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Jun 87 01:44-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 12 Jun 87 00:02:43 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 12 Jun 87 00:01:56 EDT
Resent-Message-Id: <[e-mail]>
Date: Thursday, 11 June 1987  20:32-MDT
Message-Id: <[e-mail]>
Sender: k1bc![e-mail]
From: k1bc![e-mail]
To: [e-mail]
Subject:   Version 12.0 of Xerox-820 W0RLI MailBox/Gateway now available
Resent-From: [e-mail]
Resent-To: [e-mail]
Resent-Date: Thu 11 Jun 1987 22:01-MDT

Version 12.0 of the Xerox-820 version of the W0RLI MailBox/GateWay
is now available from SIMTEL20.

Filename                        Type     Bytes   CRC

Directory PD:<CPM.PACKET>
RLI120.ARK.1                    BINARY  229800  8237H

Even though the high part of the version number changed from "11" to
"12", this is a minor update from version 11.9.

The main reason for this release is to support two features requested
by the National Traffic System folks.  One allows users to edit the
headers of NTS messages, to aid in the routing process.  The second
allows "*" and "?" wildcards in the forwarding file FWD.TNC.  The
intent of this is that NTS routing can be based on ZIP codes.  A
message can be sent to NTS021 (meaning a Zip code from 02101 to
02199).  A MailBox site in California can have "NTS0*" in its
forwarding file to cause all East Coast traffic to be forwarded along
the right path.  W0RLI C-code (PC) also is getting this enhancement,
and WA7MBL V3.13 will have it.


This is likely to be the last release of the 820-based system from
K1BC.  I have switched over to PC-clones at my station.  I will be
glad to help with problems, but it won't be the main thrust of my
efforts.

The excerpt from the CHANGES.TNC file follows.

73,
Bob, K1BC
Arpanet: [e-mail]
Usenet: {backbone}!bbn.com!clements


     Changes and additions since version 11.9 are:

Changed default forwarding header line in CONFIG.TNC to match the one
that seems to have won the "header wars".

Add "ET" command, Edit Traffic. Allows ordinary user to change the
"TO", "AT", "TYPE" and "TITLE" field if msg is TYPE T or S or it is
addressed TO NTSxxx.

Forwarding file can have "*" and "?" in destination patterns.

Define mhext field in msg header and clear it in untangle and for new
msg.  (Local mod at K1BC: Disallow connects via BADDIG digipeater.
You could patch this callsign to a real digi, as I have done here.)

Reading an S msg is not considered "snooping".

12-Jun-87 02:07:14-EDT,3626;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Jun 87 02:07-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 12 Jun 87 00:56:03 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 12 Jun 87 00:55:32 EDT
Resent-Message-Id: <[e-mail]>
Date: Thursday, 11 June 1987  20:32-MDT
Message-Id: <[e-mail]>
Sender: k1bc![e-mail]
From: k1bc![e-mail]
To: [e-mail]
Subject:   Version 25A of MS/PCDOS W0RLI MailBox/Gateway now available
Resent-From: [e-mail]
Resent-To: [e-mail]
Resent-Date: Thu 11 Jun 1987 22:55-MDT

Version 25A of the MS/PCDOS version of the W0RLI MailBox/GateWay
is now available from SIMTEL20.

Filename                        Type     Bytes   CRC

Directory PD:<MSDOS.PACKET>
IO25.ARC.1                      BINARY    7808  1AD0H
IOSRC25.ARC.1                   BINARY   42368  E78AH
MB25ARED.ME.1                   ASCII      869  EDC1H
MB25READ.ME.1                   ASCII     1706  7644H
MBRUN25A.ARC.1                  BINARY  111192  AAF8H
MBSRC25A.ARC.1                  BINARY   80352  EB92H

This release, called version 2.5A, is an offshoot of Hank's version
2.5 MailBox.  It contains the features which I had added in version
11.9 and 12.0 of the Xerox-820 MailBox system.  The most significant
of those are: the time-of-day dependent access controls for
BBS/ordinary people, gateways and links; prompting for home BBS; mail
snoop detection; the ET command for Editing NYS Traffic; and support
of wild cards in the FWD.MB file.

There are no changes from version 2.5 in the I/O drivers.

I hope to convince Hank to merge these changes in to his main line
development code.  Stay tuned for news on that.  In the meantime, if
he releases a version 2.6 or greater, I will do the merge again and
you will just have to flip a coin as to which version you want to run
until we all get on the same track.

73,
Bob

Here are Hanks notes on version 2.5:

     The W0RLI / VE3GYQ C BBS

Release notes for C BBS Version 2.5 - 3/23/87

*** YES ! ALL your messages and bug reports DO get here.
If I answered more than just a few, I could write no code.
(Todays harvest is 7 printed pages + 1 hour land line time).

Without the reports debugging is near impossible, keep 'em coming.

Please please include DOS version, DoubleDOS or DESQView version,
device driver used. Many problems only show under specific versions.

*** Note: Check that any sub-directory you use in config.mb exists,
the existance of any directory / device paths is NOT checked.

A special thanks to those who send little chunks of code showing bug
fixes they have found. w1goh and ag3f have been especially helpful.

To extract the REAL files from the archives:

ARC51 E MB        (The MailBox stuff)
ARC51 E MBSRC   (The MailBox source code)
ARC51 E IO        (The serial port device drivers)
ARC51 E IOSRC   (The serial driver source code)

MBMODE can be used to set the port parameters, in the same
manner that MODE would be. MBMODE supports COM1 thru COM7.

The code has been run on:

  Several flavors of IBM and compatibles.
  Leading Edge "M".
  Victor VI, Victor V286 clone.
  Zenith Z-100 (port not yet finished).
  Xerox 820 (Not too useful).
  Victor 9000 (ah6cl, n6iya).
  OS-9 (Contact DH1IAZ for details).

The code runs under DoubleDOS or DESQView.

Please read the first few pages of NOTES.MB before you attempt to run
the program, and read it in detail for information on setting up
route tables, etc.

There WILL be sysops documentation sometime "soon".


... Hank
12-Jun-87 11:31:43-EDT,1037;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Jun 87 11:31-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 12 Jun 87 10:23:03 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 12 Jun 87 10:22:46 EDT
Message-Id: <[e-mail]>
Received: from CUVMA(MAILER) by MITVMA (Mailer X1.23) id 6109;
      Fri, 12 Jun 87 10:16:13 EDT
Received: by CUVMA (Mailer X1.24) id 4691; Fri, 12 Jun 87 10:17:12 EDT
Date: Fri, 12 Jun 87  10:17 EDT
From: MIKCU@CUVMA
To: [e-mail]
Cc: [e-mail]
Subject: HAM RADIO CLUBS AT COLUMBIA UNIVERSITY

I would like to get in contact with someone about ham radio clubs at
Columbia University.  I am new in New York and would like to get
involved in a radio club.  I have a novice license and would like to
upgrade to technician.  I have an HF rig and packet gear. Contact me
me at MIKCU@CUVMA, SY.MIKE@CU20B or mike@cunixc.
------
12-Jun-87 21:00:47-EDT,4725;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Jun 87 21:00-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 12 Jun 87 19:55:34 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 12 Jun 87 19:55:15 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA15474; Fri, 12 Jun 87 16:56:40 PDT
Return-Path: <ihnp4!homxb!houxm!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 12 Jun 87 14:49:56 GMT
From: ihnp4!homxb!houxm!hou2d![e-mail] (J.BEATTIE)
To: [e-mail]
Subject: ARRL Hudson Division Packet/Traffic Meeting
Keywords: Packet NTS

On 6 June, the ARRL Hudson Division Director, Steve Mendelsohn, WA2DHF
hosted a meeting of folks interested in getting the Packet and
NTS communities more closely aligned.

Representatives included W2JUP (for WA7MBL) and KA2BQE (for
PRMBS) software developers, W2XD for EAS, K1CE for ARRL NTS
management, W4RI for ARRL Digital Committee, all STMs, two of
three SMs, local NTS folks, and representatives of the major
packet groups in the division.

Everyone stated their concerns, which were quite extensive,
and we ended up with the following agreement:

1. NTS message format would be carried as unmodified user
data in a packet message.

Note: Message formats were left for another day !

2. NTS liason with various packet systems are the
responsibility of the NTS community.

3. Basic unprompted mode (other than normal BBS message
prompts) would be the prefered mode of operation.

Note: This is consistent with the general goal of making
all message editing an "off-line" function where possible.

4. BBS support for a full prompted mode for NTS format
information would be added as a SYSOP configurable option.

Note: This allows special nodes to provid this service
without forcing the on-line editing on all systems.  The
prompted mode is also a good training tool because it helps
familiarize more operators with the NTS Message format.

5. The prefered routing mode for NTS messages needs to be more
generic and application independent.  We therefore suggest
separating the "NTS" from the locator descriptor.  The format
for message entry would then be:

ST NTS (atsign) 201

This would allow the routing table entry to be used for
other kinds of forwarded BBS traffic.  A configuration option
will be added to support "blanking" of the "at" field when
there is a match by a system in, or local to, the area code

An alternative format using the two letter state codes was
also accepted.  The format would be:

ST NTS (atsign) NJ

Once the packet message is in a locality or region, final
routing becomes much less complex as each system has a better
handle on who's traffic goes where.

Note: The use of the area code was chosen over other
alternatives because it was felt that:

A. The directory for Area Codes was the most available;

B. A majority of NTS messages have a Telephone Number;

C. The telephone system apportions Area Codes on the basis of
population;

D. The North American Numbering Plan is used by both telephone
and data networks.  Amateur use facilitates routing to local
gateways for interworking with telephone and packet switched networks;

E. This type of plan is used by foreign telecommunications
administrations in their voice and data networks; (Usually with City
Codes)

F. This Area Code plan maps into the CCITT X.121 country code
assignments.  This is handy for automatic routing and go/no-go
forwarding for international messages (third-party or not);

Note: Domestic traffic would not use the country code - US,
Canada, Mexico, or the Caribean messages can be routed on the Area
Code alone.


6. K1CE would publish the full-blown proposal in the August ARRL Section
Leader, etc...

7. W4RI would publish the full-blown proposal in Gateway.


It should be noted that all attendees felt that Area Code
routing was the way to go for implicitly-routed messages of
all sorts on the Packet Network.  It should also be noted that
at the beginning of the meeting we did not all agree on this
point, but by the end of the meeting we felt that we had made
a major step toward understanding the needs and limitations of
each part of the Amateur Service represented.

(Note: This does not include
K1CE and W4RI.  They were not asked to state an opinion
because of their roles at the ARRL.)

Your comments would be most welcome.


Thanks,

   J. Gordon Beattie, Jr.
   ihnp4!houxm!hou2d!n2dsy
   n2dsy at kd6th
   201-615-4772 (W)
   201-387-8896 (H)


13-Jun-87 00:24:42-EDT,1810;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Jun 87 00:24-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 12 Jun 87 23:12:00 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 12 Jun 87 23:11:47 EDT
Date: Fri, 12-Jun-87 21:17:13 EDT
From: k1bc![e-mail]
Subject: ARRL Bulletin #48: ARRL files request for packet SKIPNET STA
Message-Id: <8706122117.0.UUL1.1#[e-mail]>
To: [e-mail]
Sender: k1bc![e-mail]
Source-Info:  From (or Sender) name not authenticated.

[Sorry for double posting this to both info-hams and packet-radio,
but as it applies directly to packeteers, I thought I would do
it this time.  /K1BC ]

Hr ARRL Bulletin Nr 48  From ARRL Headquarters
Newington CT  June 12, 1987, Edited by K1BC
To All Radio Amateurs BT

The ARRL has filed a request to the FCC for Special Temporary
Authority to permit more than 50 Amateur packet stations around the
country to have unattended automatic operation while transmitting
third party traffic on frequencies below 50 MHz.  The request would
waive for 6 months section 97.80 of the FCC rules which only allows
this to be done on frequencies above 50 MHz.

The packet stations participating under this waiver are to
participate in a national net called SKIPNET.  This net will provide
the Amateur packet network with national message transfer
capabilities.

The ARRL request states that it has requested the temporary waiver
to, among other things, study the concept of unattended automatic
operation of packet stations on HF and to demonstrate that such
operations can be conducted without interference to other users.  AR

[K1BC note:  So did they request the 1200 baud permission?!?]

15-Jun-87 17:47:26-EDT,2597;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Jun 87 17:47-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 15 Jun 87 14:26:32 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 15 Jun 87 14:26:08 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA04855; Mon, 15 Jun 87 11:27:33 PDT
Date: Mon, 15 Jun 87 11:27:33 PDT
From: [e-mail] (Clifford Neuman)
Return-Path: <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu![e-mail]
In-Reply-To: ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!hamilton's message of 15 Jun 87 06:03:00 GMT
Subject: amiga/mac/unix tcp/ip package

Wayne Yamamoto (no call, yet) and I have also gotten IP running on top
of AX.25 for Unix.  We made the necessary changes to an Ultrix kernel,
and have been able to use a Microvax-I as a gateway between an IBM PC
on the packet side, and several machines on our department's ethernet.

I would still like to do a bit more testing and cleanup before
distributing anything, but if anyone is interested, send me a message.
The changes do require Ultrix source to implement, but the
modifications do not include such source themselves, so I can
distribute them.  I may make the same changes to BSD 4.3 shortly.  The
code to build and take apart AX25 and SLIP packets came from Phil
Karn's PC implementation.

I also have a few ideas on how to control access to the gateway such
that connections can only be initiated from the amateur side.  A table
can be maintained of valid hosts that can use the gateway on the
non-amateur side, and who they can send IP packets to.  When a packet
from the amateur side is gatewayed to the non-amateur side, the
reverse path is entered in the table.  These entries time out after
non use for certain period of time.  One also requires some kind of
ICMP packet to allow someone on the amatuer side to specifically
remove an entry from the table if it is determined that the contents
of such messages are counter to part 97.

The last issue that needs to be decided, is how to deal with multiple
gateways to different parts of net 44.  Right now, when mine is turned
on, it provides a gateway to 44.24.0.*.  But, since the rest of the
internet would like to think there is a single gateway for all of net
44, this won't work.  Any solutions out there?

    ~ Cliff
      N1DMM/7
16-Jun-87 00:37:42-EDT,2592;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Jun 87 00:37-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 15 Jun 87 21:21:42 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 15 Jun 87 21:21:01 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA21066; Mon, 15 Jun 87 18:21:47 PDT
Return-Path: <delni.dec.com![e-mail]>
Message-Id: <[e-mail]>
Date: 15 Jun 87 22:19:32 GMT
From: delni.dec.com![e-mail] (Fred R. Goldstein dtn226-7388)
To: [e-mail]
Subject: numbering plan for NTS traffic?

I noticed in the report on the ARRL NTS-on-packet meeting that they
decided to use telephone Area Code in their headers.  Without casting
a value judgement on this per se, I noted a mistaken assuption about
the Numbering Plan.

The Telephone network follows CCITT Recommendation E.163, in which the US
has country code "1" (shared with other North American countries, but not
Mexico which is South America) followed by the nationally-signifiant
number.  This latter number (area code, prefix, line) is administered
per Bellcore.

Data networks using X.25 format make use of CCITT Recommendation X.121
for numbering.  This is very, very different from E.163.  X.121 uses
14-digit numbers (vs. <=12 for E.163), of which the first 4 are the
Data Network ID Code.  This in turn is parsed into a 3-digit country
code and a 1-digit network ID.  The US is currently allocated 20 countries,
or 200 DNICs, of this plan (more competitive than others!).  These DNICs
have nothing in common with E.163 country codes.  The numbers within
each network are also set only by that carrier (i.e., Telenet, Tymnet,
AT&T Accunet) and do not follow a central plan.  In other words, E.163
and X.121 are about as close as English and Chinese.  Both are languages.

Integrated Services Digital Networks (ISDN) will use E.164 numbers, which
are a superset of E.163 (max. length extended to 15 digits).  Packet
carriers will eventually have ISDN numbers, though there's a forum that
hasn't yet resolved how to give them numbers.  (Some want their own area
codes, others want prefices in telco area codes, some want a mix.)  So
by 1995 X.121 may be history.
b

But in the meantime, they are different.  If you want to use North American
Numbering Plan plus E.163 numbers, fine, but do note that there'll be a
number of area code splits within the next couple of years.
      fred k1io


16-Jun-87 01:48:33-EDT,1113;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Jun 87 01:48-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 15 Jun 87 23:07:35 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 15 Jun 87 23:06:57 EDT
Date:     Mon, 15 Jun 87 22:59:04 EDT
From: [e-mail]
To: "Fred R. Goldstein dtn226-7388" <delni.dec.com![e-mail]>
Cc: [e-mail]
Subject:  Re:  numbering plan for NTS traffic?
Message-Id:  <[e-mail]>

Fred,

At least some American X.25 carriers are using the area code as the first
three digits following the DNIC. Apparently the Dutch PTT is following
the telephone numbering plan as well, even to extent of prefixing a
1 (yes, that makes 15 digits) to get to the international gateway. Also,
your assumption that we will all be using ISDN numbers is at the very
least arguable. Check out the ISO NSAP addressing document and see what
standards have done for us lately. O' give me 40 octets and I'll walt,
tra la....

Dave
16-Jun-87 02:00:38-EDT,8049;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Jun 87 02:00-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 15 Jun 87 22:04:30 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 15 Jun 87 22:03:55 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA21707; Mon, 15 Jun 87 19:05:22 PDT
From: ulysses!faline![e-mail]
Return-Path: <ulysses!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 15 Jun 87 04:51:14 GMT
To: [e-mail]
Subject: Proposed changes to AX.25 Level 2

At the recent ARRL Digital Communications Committee meeting in Newington,
the subject of revisions to the AX.25 Level 2 spec came up.

AX.25 is modeled on LAPB, the CCITT X.25 link level protocol. LAPB was
intended for full duplex operation. Many of the problems encountered with
AX.25 in the amateur world are caused by our half duplex, multiple-access
radio environment.  A detailed discussion of these problems can be found in
"Link Layer Protocols Revisited", by Phil Karn, KA9Q, and Brian Lloyd,
WB6RQN, in the 5th ARRL Computer Networking Conference proceedings (the 1986
Orlando conference).

Several of us are investigating possible changes to AX.25 to make it run
better in the radio environment. These would become Version 3.  Here's a
partial list of the changes being considered that would apply ONLY to the
half-duplex, multiple access case. Comments are welcome.

1. Persistence.

The "DWAIT" feature in some TNCs would be removed and replaced with a more
general (and more effective) "p-persistence" feature.  When a node wishes to
transmit, it monitors the channel for other signals.  If or when the channel
becomes clear, THE TNC DOES NOT IMMEDIATELY TRANSMIT. Rather it generates a
random number between 0 and 1. If and only if this number is smaller than a
parameter "p" (also ranging from 0 to 1) does the TNC transmit. Otherwise
the TNC delays for a period of time, "slottime", another settable parameter.

2. Flow control.

Only one frame may be sent per transmission; a TNC must receive an
acknowledgement for this frame before it may send more.  In other words, the
TNC parameter MAXFRAME is always 1.

3. Maximum packet length.

The current limit on the size of the data field in an I-frame is raised from
256 to 1024 (the exact value here is still under discussion). If at all
possible, implementors should not restrict the maximum allowable size of
incoming frames. If a limit is necessary (e.g., for buffer space
pre-allocation) it should be changeable by operator command.

4. Poll/Final bits

"Poll/final recovery" is not recommended when timeouts occur because of lost
acknowledgements except for "large" packets. For "small" packets, the
unacknowledged data packet should simply be retransmitted.  Polls should also
be used to probe a receiver not ready (RNR) condition.  The size above
which poll/final recovery is used should be settable by the operator.

5. T1 and Round trip timing

The T1 (retransmission) timer (called "FRACK" on most TNCs) should be set
automatically through round trip time measurement (the interval between the
transmission of a packet and the receipt of its acknowledgment). The recent
history of round trip time measurements is to be smoothed into the "smoothed
round trip time" (SRTT). The operator may set the initial value of SRTT, but
it should be adjusted as acknowledgements arrive according to the following
formula:

        SRTT' =  (1 - alpha) * SRTT + alpha*RTT

where

SRTT' = new value of SRTT
alpha = a parameter ranging from 0 to 1; if not adjustable, a suggested
    fixed value is 0.9
RTT = round trip time measurement for the current packet

(Note: since floating point numbers are difficult to deal with on small
microprocessors, fixed point numbers between 0 and 255 may be used to
represent floating point numbers between 0 and 1).

The retransmission timer T1 should be computed by

T1 = beta * SRTT

where

beta = a parameter greater than 1. A suitable fixed value for beta is 2.

6. Backoff

The retransmission timer for a packet being retransmitted MUST be doubled on
each subsequent attempt. For example, if beta is 2 and SRTT = 2.5 seconds,
the first transmission of a packet will be made with a timeout setting of 5
seconds, the second must be made with 10, the third with 20, and so on.
When an acknowledgement finally arrives for a retransmitted packet, the SRTT
is *not* updated, however, and the backed-off timer setting is kept for the
*next* packet. Only when a packet is acknowledged without retransmission is
the round trip time used to update the SRTT, and a new timeout based on beta
* SRTT used for the next packet.

Closed window probes (i.e., polls sent to a station repeatedly returning
RNR) are backed off in the same manner as retransmitted data.

7. Other timers

The T2 (acknowledgement delay) timer is not used.

Discussion of proposed changes

Many of the new features described here are already present in my TCP/IP
package, where they have been shown to work very well in actual on-air
testing. I am proposing them here because they are readily adaptable to
AX.25.

The "KISS TNC" usually used with TCP/IP on the air already implements the
p-persistence feature. When the p and slottime parameters are properly set,
the reduction of channel collisions and improvement of performance is
dramatic.

Automatic retransmission timeout setting and retransmission backoff have
always been features of TCP. I recently devised the rules regarding round
trip timing and timeout settings in the face of retransmissions in order to
improve performance when the channel is lossy; they work so well that I am
proposing them to other TCP implementors as well as AX.25.

The recommendation for permanently setting MAXFRAME to 1 is based on an
analysis of AX.25 transmission efficiency in our "Link Level Protocols
Revisited" paper. We defined "transmission efficiency" as the number of
usable data bits received divided by the total number of bits transmitted,
including data and acknowledgement header overhead, damaged frames, and
undamaged frames rendered unusable by an earlier damaged frame. (AX.25
requires you to drop out-of-order frames).

We found that on a half duplex channel, maximum efficiency ALWAYS occurred
when each transmission was limited to a single frame and the size of the
frame (transmission) adjusted as appropriate depending on the channel bit
error rate.  This held for a very wide range of bit error rates.  If the
transmission is large, dividing it up into several frames sometimes allows
you to "salvage" the beginning of the transmission even if the end is
damaged, thereby improving efficiency.  HOWEVER, you can ALWAYS do better by
going to single-frame transmissions and cutting down the transmission size,
because you're saving header overhead.

With the 1-frame rule on a good channel the optimum frame size will be much
larger than 256 bytes.  This is especially true with high speed modems when
the transmitter keyup delay is long compared to the bit rate (e.g., the 56
kbps modems by WA4DSY). This is one reason for increasing the maximum frame
size limit. Another is to allow the transmission of large IP datagrams (when
conditions permit) without needless fragmentation.

Going to single-frame transmissions also allows several major
simplifications in the protocol; for example, the T2 timer is no longer
needed.

Poll/final recovery is intended to recover from lost acknowledgements
without having to retransmit data packets that were successfully received.
When a timeout occurs for a small data packet, however, it is more efficient
to retransmit the data than to go through a poll. This is the intent of the
revised poll/final procedures.

Again, comments and suggestions are solicited.

Phil Karn, KA9Q


16-Jun-87 02:06:33-EDT,1113;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Jun 87 02:06-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 15 Jun 87 23:07:35 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 15 Jun 87 23:06:57 EDT
Date:     Mon, 15 Jun 87 22:59:04 EDT
From: [e-mail]
To: "Fred R. Goldstein dtn226-7388" <delni.dec.com![e-mail]>
Cc: [e-mail]
Subject:  Re:  numbering plan for NTS traffic?
Message-Id:  <[e-mail]>

Fred,

At least some American X.25 carriers are using the area code as the first
three digits following the DNIC. Apparently the Dutch PTT is following
the telephone numbering plan as well, even to extent of prefixing a
1 (yes, that makes 15 digits) to get to the international gateway. Also,
your assumption that we will all be using ISDN numbers is at the very
least arguable. Check out the ISO NSAP addressing document and see what
standards have done for us lately. O' give me 40 octets and I'll walt,
tra la....

Dave
17-Jun-87 06:29:41-EDT,3181;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Jun 87 06:29-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 17 Jun 87 05:08:15 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 17 Jun 87 05:08:02 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
    id AA04828; Wed, 17 Jun 87 05:05:33 EDT
Received: from SFU.Mailnet by um.cc.umich.edu via MTS-Net; Wed, 17 Jun 87 05:00:57 EDT
Date: Tue, 16 Jun 87 17:41:48 PDT
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Re: ARRL Hudson Division Packet/Traffic Meeting.

     Re: ARRL Hudson Division Packet/Traffic Meeting.

     Provinces and telephone system Area Codes cover a lot of ground in
Canada.  If the intention is to get traffic sent into the local area of its
destination, please consider that "BC" (British Columbia) or Area Code 604
(the BC area code) covers a rather large area (about 700 by 1200 km).  Since
radio coverage is more based on distances than on population densities, a
geographic indicator would do a much better localising the destination than
would an Area Code.

     A comment was made that the packet switched data networks use the NNP
Area Codes.  Please note that this is not true in Canada, as the addresses
used in the Datapac network (our major packet switching network) does not
use Area Codes at all.  If the intent was to be able to in some way use Area
Codes to route via the public packet switching networks, this is not
terribly convenient outside the United States, especially since the data
networks require traversing gateways between the U.S.  and Canada, unlike
the telephone network.

     I'm not sure what the "correct" solution to this problem is.  A naming
scheme that can (optionally) allow for more 'granularity' of location would
be helpful.  For instance, knowing that a destination is somewhere in Maine
narrows down the location (and the possible number of packet stations
required to cover the area) than would a destination like Montana (or
Northwest Territories!)  .  (All three of these examples are each covered by
a single area code.)  Perhaps a hierarchical naming structure that could
optionally go further than country+state/province would be in order, i.e.
include the city or some geographical localiser to the address, as in:
'CDN,BC,VANCOUVER' or 'CDN,BC,SW'.  This should make it possible to get mail
closer to its destination before the routing system needs to rely on the
name of the recipient to correctly route a message.

     This problem has been tackled in some of the other electronic mailing
system (such as the one I'm using to send this message!), but I believe that
it will be quite some time before the Amateur Radio community will be able
to support Name Servers!

--- Richard Chycoski, VE7CVS
    Simon Fraser University
    Computing Services Department
    Burnaby, B. C.
    Canada
    V5A 1S6

--- [e-mail]  (Internet)
--- USERRICH@SFU                          (Bitnet)

17-Jun-87 16:20:18-EDT,1024;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Jun 87 16:20-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 17 Jun 87 13:58:11 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 17 Jun 87 13:57:53 EDT
Received: from Burger.ms by ArpaGateway.ms ; 17 JUN 87 08:42:00 PDT
Sender: "Thomas_A._Cagan.ElSegundo"@Xerox.COM
Date: 17 Jun 87 08:21:09 PDT (Wednesday)
Subject: Re: numbering plan for NTS traffic?
From: "Thomas_A._Cagan.ElSegundo"@Xerox.COM
To: delni.dec.com![e-mail]
Cc: "Thomas_A._Cagan.ElSegundo"@Xerox.COM, [e-mail]
In-Reply-To: delni.dec.com!goldstein%DECWRL.DEC:COM:Xerox's message of
 16-June-87 (Tuesday) 1:17:03 PDT
Message-Id: <870617-084200-1594@Xerox>

Just a note on your memo: Mexico is part of North America, and although
it doesn't follow on the phones as USA and Canada it's still part of our
continent,whether they like it or not.      Tom KB6NQW
18-Jun-87 00:14:05-EDT,2337;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Jun 87 00:14-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 17 Jun 87 22:19:02 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 17 Jun 87 22:18:50 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA22210; Wed, 17 Jun 87 19:20:28 PDT
Return-Path: <cbosgd!cblpf!cblpe![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Jun 87 22:12:28 GMT
From: cbosgd!cblpf!cblpe![e-mail] (Rob Stampfli)
To: [e-mail]
Subject: watchdog timer for KPC TNC-I

Our club has a KPC TNC-I which is left in unattended digipeater operation.
Recently a storm caused a power glitch which resulted in the TNC keying
the transmitter permanently (until manually reset).  Because of this, we
designed and installed two circuits to prevent this from reoccurring:
(1) a watchdog timer, which drops the xmit line if the TNC leaves it keyed
for more than 45 seconds, and (2) a voltage sensor, which will reset the
microprocessor on a significant voltage drop prior to the point where the
voltage becomes low enough to become unregulated.  The watchdog timer is
built around a 555 timer and is quite easy to install on the board.  It
consists of two resistors, a capacitor, the 555, and requires the removal of
one end of an existing resistor and 4 soldered connections.  The voltage
monitor circuit is more complex, and built on a small daughterboard which
was glued to the TNC, and attached at three points.  Both have been
tested individually and with the KPC TNC-I and appear to function as designed.

The KPC TNC-I obviously does not have a built in watchdog timer, and I have
heard that stuck xmit on power glitches is generic in this design.
This makes its use for unattended digipeaters undesireable, and probably
illegal.  During the installation, we discovered our TNC was manufactured
with incorrect components, which may have aggravated the problem.

Although we can make no warranties, we will certainly make the schematics
available for anyone who feels that they could benefit from them.  Contact
me for more information.

73's
Rob Stampfli (kd8wk)
cblpe!res
kd8wk @ w8cqk
614-860-4268 (work)


18-Jun-87 18:44:02-EDT,2093;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Jun 87 18:44-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 18 Jun 87 16:07:28 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 18 Jun 87 16:07:17 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA01729; Thu, 18 Jun 87 13:08:48 PDT
From: ulysses!faline![e-mail]
Return-Path: <ulysses!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 17 Jun 87 23:34:52 GMT
To: [e-mail]
Subject: Re: ARRL Hudson Division Packet/Traffic Meeting.
References: <[e-mail]>

>      I'm not sure what the "correct" solution to this problem is.  A naming
> scheme that can (optionally) allow for more 'granularity' of location would
> be helpful.  For instance, knowing that a destination is somewhere in Maine
> narrows down the location (and the possible number of packet stations
> required to cover the area) than would a destination like Montana (or
> Northwest Territories!) ...

Please, not again. It is a very bad idea to encode geographical location
into packet network addresses. Knowing that I'm here and you're there
says NOTHING about the route that I should take to get to you. Encoding
the *topology* of the network *may* help, but even here it is a) random
and b) subject to arbitrary changes (consider the satellite wormholes).
We must allow the functional equivalent of "flat" (location independent)
addresses. Topologically-based assignment may be used to the degree possible
to allow efficient storage of routing tables, but the addressing scheme can
NOT require it. I do this in my TCP/IP code.

> ...but I believe that
> it will be quite some time before the Amateur Radio community will be able
> to support Name Servers!

Try RIGHT NOW. I have a Sun 3/75 on TCP/IP packet. Send it a domain request
and it'll answer.  The client code in my TCP/IP package to make use of it
is on my list of things to do...

Phil


18-Jun-87 22:27:34-EDT,3473;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Jun 87 22:27-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 18 Jun 87 20:08:59 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 18 Jun 87 20:08:47 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
    id AA21708; Thu, 18 Jun 87 20:06:19 EDT
Received: from SFU.Mailnet by um.cc.umich.edu via MTS-Net; Thu, 18 Jun 87 20:02:13 EDT
Date: Thu, 18 Jun 87 16:38:28 PDT
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Message Destinations and Routing.

     Using a physical location to identify the destination does *not* hamper
the routing!  It only indicates, to a reasonable degree, where the message
needs to end up.  Unless you're willing to register every person in North
America (at least!)  on a naming system, you absolutely *must* know where
the message is going to end up.  (Note that when identifying a destination
like CDN,BC,Vancouver, I'm only telling you where the destination is, not
that you should route it to CDN, then BC, and then Vancouver.)

     Also, although the offer of a name server at your location is very
generous, the NTS should not need to rely on expensive, administration
intensive name servers.  Suns are *not* cheap (even a 3/50 with a disk is
more than CDN$13000), and cannot be expected to be ubiquitous enough to
supply routing information to packet stations scattered across the entire
continent!

     The Amateur Radio community simply does *not* have the financial
resources to build another Internet.  We do need simple, cheap, reliable
means to get traffic from "anywhere to anywhere".  Requiring extensive
central facilities just isn't practical, and simply isn't necessary for this
kind of traffic.  A name server that replaces the need for routing
information is a great idea, but it doesn't preclude physical addressing of
the destination.  The domain naming system is based on a hierarchy of
adminstrations, each taking responsibility for maintaining up-to-date
information on their subdomain.  This works for highly-interconnected,
administration intensive systems such as the Internet, but you can't expect
the Amateurs to register everyone to whom they might ever deliver a message,
nor even every amateur station that might receive such messages for
delivery.  Even the Post Office (I know, not necessarily the best example of
how to get a message somewhere, but it does work most of the time!)  does
know how to deliver a message to John_Doe@Some_Institution.EDU, but *can*
get a letter to John Doe if you tell them *where* he lives.

     We can't expect the Amateur Radio community to spend large amounts of
time in the administration of *anything*, and expect it to work.  The more
that can be done by the individual, and the less that requires central
administration, the more likely it is to succeed.  (eg.  The first Packet
Radio TNCs were designed to operate *only* through a central switching
node.  The outcry was such that when a quickly cobbled together TNC-to-TNC
program was made to work, interest in Packet Radio suddenly exploded.)  Most
hams just want to "get on with it", and activities that require lots of
coordination eventually fade or become a major headache.  (Frequency
coordination of repeaters, for instance.)
18-Jun-87 23:33:01-EDT,2372;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Jun 87 23:33-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 18 Jun 87 21:15:32 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 18 Jun 87 21:15:19 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA14291; Thu, 18 Jun 87 18:16:58 PDT
Return-Path: <ihnp4!homxb!houxm!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 18 Jun 87 05:02:23 GMT
From: ihnp4!homxb!houxm!hou2d![e-mail] (J.BEATTIE)
To: [e-mail]
Subject: OSI Protocol Software

A week or so ago I put a message on the net looking for source
code for a small PC or Unix OSI protocol stack.  I am happy to
say that several folks responded to me.  I'm sorry to report
that they chose to do it privately...
WHAT'S WITH YOU GUYS ?

Don't get me wrong I am thankful for the responses...and I
would love to hear from folks who may have stuff to offer
 - even a single protocol layer contribution is of interest...

What I guess I'm frustrated about is that I chose a title of
OSI Protocol Software which spurred several people into
action, but

MOST of the "respondents" who used the title were:

1. Interested in pushing Internet,
2. CCITT/ISO/COS/OSI bashing, and
3. NOT CONTRIBUTING to the request.

To them I should probably not say much more on the subject
(other than what is above), because I try to remain a
gentleman even when I disagree...

NOW...
What was in the original request ?

In summary:
I am interested in seeing OSI protocols in general use.
A subset of these protocols is being assembled for the PC
clones...but we want to have a good selection of
implementations at each layer...so if you have something or
know of implementations LET ME KNOW !

WHY ?

We are going to circulate a public domain (no profit a la
Columbia University's Kermit) OSI stack for the PC.  We'll
give it plenty of use where ever we can...specfically in
Amateur Radio Packet Networks and in the Freeware/Shareware
landline Internet and BBS worlds.

We feel that this approach will help popularize and refine OSI
protocols.

Thanks,

   J. Gordon Beattie, Jr.
   ihnp4!houxm!hou2d!n2dsy
   201-615-4772 (W)
   201-387-8896 (H)


21-Jun-87 19:17:53-EDT,1349;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Jun 87 19:17-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sun, 21 Jun 87 16:58:24 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sun, 21 Jun 87 13:31:31 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA09607; Sun, 21 Jun 87 10:29:52 PDT
From: ulysses!faline![e-mail]
Return-Path: <ulysses!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 20 Jun 87 06:33:14 GMT
To: [e-mail]
Subject: Re: amiga/mac/unix tcp/ip package
Summary: ms-dos version of my tcp
References: <[e-mail]> <[e-mail]>

In article <[e-mail]>, [e-mail] writes:
>
> Re yr posting: Can I assume the same address, etc. for
> the ms-dos version of tcp/ip?  Also, what compiler
> was used?
> Forrest Gehrke K2BT


You can get floppy copies of my stuff for MS-DOS from Brian Lloyd, WB6RQN,
19200 Tilford Way, Germantown, MD 20874. Send him $5 to cover costs
of floppies and mailing.

I used the Manx Aztec C compiler for the PC. I don't have any strong
attachment to it, but I've not switched to Microsoft because Aztec
seems to produce code that is both smaller and faster.

Phil


24-Jun-87 04:57:38-EDT,2075;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 24 Jun 87 04:57-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 24 Jun 87 03:23:53 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 24 Jun 87 03:22:49 EDT
Received: by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.14QM)
    id AA24113; Wed, 24 Jun 87 00:22:54 PDT
Message-Id: <[e-mail]>
Return-Path: [e-mail]
Received: by DTUZDV1 (Mailer X1.23) id 8480; Wed, 24 Jun 87 08:52:28 CET
Date:         Wed, 24 Jun 87 08:50 CET
From: Ralf D Kloth <[e-mail]>
Subject:      TCP/IP: IP addresses
To: Info-Packet <[e-mail]>

> Date:         Wed, 10 Jun 87 09:58 CET
> From:         Ralf D Kloth <ZRKL001@DTUZDV1>
> Subject:      TCP/IP address
> To:           Wally Linstruth WA6JPR <[e-mail]>
>
> Hello,
> in the KA9Q TCP/IP package documentation I read your name to be in
> charge for TCP/IP packet radio subnet addresses.
> This is to inform you, that since our initial tests with the first
> available version of the KA9Q package we are locally using the
> following IP addresses:
>    44.192.0.xxx : Stuttgart/Tuebingen subnet
>    44.192.0.1      DL4TA  Ralf D. Kloth, QTH Tuebingen
>    44.192.0.2      DJ7KA  Hans Ulrich Wandel, QTH Tuebingen
>    44.192.0.3      DK5SG  Dieter Deyke, QTH Gaertringen
>    44.192.0.4      DF1TL  Klaus Dittrich, QTH Waiblingen
>    44.192.0.5      DK3SI  Harald Tietze, QTH Gerlingen
> Please, add our net to your listings.
> Can you send me your list of other local subnets, just to see who else
> is there .....

Since I don't know if the above message ever has reached its recipient
(I didn't receive any confirmation) I send it again via this list.
Just to tell others who we are and where we are ...
Wally, are you listening?

73, Ralf D. Kloth (DL4TA)  <[e-mail]>
Acknowledge-To: Ralf D Kloth <ZRKL001@DTUZDV1>
28-Jun-87 15:14:38-EDT,1842;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 Jun 87 15:14-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sun, 28 Jun 87 13:50:05 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sun, 28 Jun 87 13:49:55 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA05501; Sun, 28 Jun 87 10:52:02 PDT
Return-Path: <rutgers!mtune!ky2d-2![e-mail]>
Message-Id: <[e-mail]>
Date: 27 Jun 87 02:18:11 GMT
From: rutgers!mtune!ky2d-2![e-mail] (Jim kutsch)
To: [e-mail]
Subject: mod.ham-radio and mod.ham-radio.packet???

There are several of  us  in  NJ  who  offer  access  to  the  ham-radio
newsgroups  via  packet  radio systems.  To comply with FCC requirements
for being responsible for transmissions from my station, I  capture  the
articles  in  a  holding  directory.  From there, I read each one before
"approving" it for access via packet radio.  Very infrequently, I remove
inappropriate  language  or  delete  an  article  containing  commercial
interests.  Essentially, I perform the  same  function  as  a  newsgroup
moderator  does  with  a moderated news group.  I know others who do the
same for their packet stations.

To the point... is there any interest in converting  the  ham-radio  and
ham-radio.packet  groups into real moderated news groups?  Several of us
(nearby in NJ) are willing to share  the  responsibility  of  being  the
moderator.  Since we all are licensed hams, I believe we could "approve"
the traffic for use  on  everyone's  packet  BBS  stations.   A  further
advantage is that the groups could then be carried via Stargate as well.

Let's hear some comments pro or con please.

73, Jim  ...!mtune!ky2d-2!jak