| |
PA2AGA > HDDIG 12.10.99 19:40l 158 Lines 7703 Bytes #-9721 (0) @ EU
BID : HD_99_257I
Read: DL6KCF GUEST
Subj: HamDigitalDigest 99/257I
Path: DB0AAB<DB0ZKA<DB0CRL<DB0TTM<DB0FP<DB0SRS<DB0AIS<DB0NDK<DB0ACH<DB0PKE<
PI8DRS<PI8DAZ<PI8GCB<PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 991012/1302Z @:PI8VNW.#ZH2.NLD.EU #:7540 [HvHolland] FBB7.00g $:HD_99_257
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA21167 ; Tue, 12 Oct 99 12:29:29 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
id AA00016360 ; Tue, 12 Oct 99 07:47:58 MET
Date: Tue, 12 Oct 99 07:44:39 MET
Message-Id: <hd_99_257I>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/257I
X-BBS-Msg-Type: B
in all gateway directions.
> The other concern that I have about your plan is that there is no apparent
> way to limit the use of the network to licensed hams, thereby insuring
that
> commercial use and/or "spam" does not end up on ham radio linked bbs
> systems. With the current AX/IP transfer mechanism, only those stations
> properly authorized by the "gateway" systems have access to the ham radio
> bbs system from the Internet.
Perhaps my use of the term "gateway" was confusing. I had in mind the
gateway function between the tcp/ip protocol and application suite, and
the traditional AX.25 BBS protocols and applications. Internet not invovled.
> I certainly have no problems if you choose to use TCP/IP and newsgroups
> protocols over radio between the "gateway" stations except that it has
been
> my experience that TCP/IP has way more overhead than what the
> run-of-the-mill 1200 baud links can handle in a crowded environment.
Don't run 1200 baud links. This is a separate issue.
> I
> also think it is unreasonable to expect the masses to rush right out and
> buy the piece-parts for 56KB radio links. As I recall the history of
> packet, 1200 baud was chosen because of the availability of the
> off-the-shelf modem parts using the Bell 202 standard. The current run of
> Rockwell/Lucent 56KB surface mount devices isn't too practical for the
> average ham with a 100 watt American Beauty soldering iron! Nor do they
> work 1/2 duplex as most ham stations require.
> Do I have a better solution? Not yet. I'd hope the new rules on spread
> spectrum emissions will encourage higher bit rate data radios. Maybe some
> wizard will figure out how to tweak a Qualcom digital PCS radio into the
> ham band and make packet fly! Let's face it, without the old converted
> Motorola and GE radios, 2 meter and 440 ham bands would not be as popular
> as they are today! The same thing can happen again, only this time high
> speed digital!
Separate issue. Run the stuff I talk about below over whatever speed
links you like. There is no more data involved than already runs over
those exact same links.
> Don, K8EIW
>
> Hank Oredson wrote:
>
> > A couple folks asked that I repost my specific suggestions
> > on how to migrate the existing BBS network to the model in
> > current use on the internet. Here they are again. Not well
> > organized, a bit of babble, but specific ideas. Would they
> > work in practice? I don't know (yet) but may implement some
> > of them and find out.
> >
> > Each BBS network message type has an equivalent internet
> > application and protocol. For the BBS network to interoperate
> > with these applications and protocols we need some number
> > of "gateway" systems which do the appropriate translations.
> >
> > 1) Bulletins map to net news and the nntp protocol.
> > We need a set of newsgroups defined to map to/from the common
> > BBS network topics. One solution would be to use newsgroups
> > of the form alt.hamradio.<topic> where <topic> is the To:
> > field of the BBS message. Thus we would have, for example,
> > alt.hamradio.keps, alt.hamradio.sysop, alt.hamradio.all
> > The "gateway" servers would move messages both directions
> > using the obvious and simple mapping.
> >
> > 2) Personal messages map to standard email and the pop3/smtp protocols.
> > We can use the obvious address mapping. I've run this kind
> > of "gateway" server for years, using a version of JNOS.
> > It works fine, and is already available.
> >
> > 3) NTS messages are an intersting case. They probably need to map
> > to net news and the nntp protocol. We might use a newsgroup
> > such as alt.hamradio.nts-traffic for this purpose. In this
> > case the same "gateway" servers which handle 1) will suffice.
> > Ideas welcome from the NTS folks on how we might handle this.
> >
> > Note that we do not need "permission" from NIS or anyone else to
> > begin to implement this capability. Everything exists within the
> > ham radio network and not within the internet per se. The model
> > is designed to be compatible with internet standards for the obvious
> > reason: those standards exist and are well tested. We should use them.
> >
> > For some of the standards, file transfer protocols also exist. For
> > example email has pop3 and smtp as network data transfer standards,
> > and RFC-822 (and it's various updates) provide a guide to the
> > construction of a bulk transfer protocol. We already use this protocol
> > as import/export between BBS systems of various kinds. The needed
> > extensions to the standard set of headers are documented in the
> > BBS specification. For net news two standard transports exist. One is
> > a bulk file transport using the "ihave/iwant" scheme similar to
> > what is called "X forwarding" in the BBS network. The needed mappings
> > are obvious and should be simple to implement.
> >
> > All the above would require only a small amount of fairly simple
> > programming effort on the part of the authors of the ham radio
> > tcp/ip programs, and very little effort on the part of the authors
> > of the ham radio BBS programs. The hard work is deciding on the
> > details of how the mappings will work, and setting up enough
> > gateway servers to attract users.
> >
> > One advantage of this scheme is that we could use it to link
> > existing news groups in the internet directly to the ham radio
> > BBS network, with bidirectional exchange of messages. Some might
> > consider this a disadvantage because of the obvious possibility
> > of abuse by both hams and non-hams. This possibility should not
> > get in the way of creating and testing the technology.
> >
> > There is an interesting technique we could use to do this integration.
> > If each "gateway" server ran a web server with a standard middleware
> > API to a local database, then the task of programming the needed
> > applications would be fairly simple. What applications are needed?
> > Those required for the administration of the "gateway" server itself,
> > for example, to maintain mappings, deal with exceptions, and all the
> > other "sysop" type of activities.
> >
> > One could even consider creating a "regular ham radio BBS" using the
> > capabilities of the web server. This has in fact been done, several
> > times, by various hams. Perhaps those hams might consider making their
> > work available to others in the ham radio network as well as on the
> > internet. Doing so might help move the digital networking facet of
> > our hobby forward. i.e. "The folks using html on ham radio are headed
> > in the right direction."
> >
> > Disclaimer: Yes, I know the above sounds a lot like the integration
> > of ham radio networking with the internet. That is exactly what it is.
> > I hope everyone can understand the difference between taking ideas
> > and techniques from the internet for use in ham radio, and replacing
> > ham radio with the internet itself. I propose the former, and not
> > the later.
> >
> > ... Hank - W0RLI
> > _^___^_
> > \\|// / 0 O \ __
> > (O O) <| V |> /..\
> > ----oOO--(_)--OOo------o000o-U-o000o------oOO--(____)--OO---
To be continued in digest: hd_99_257J
Read previous mail | Read next mail
| |
