| |
PA2AGA > HDDIG 12.10.99 21:10l 177 Lines 7396 Bytes #-9721 (0) @ EU
BID : HD_99_257L
Read: DL6KCF GUEST
Subj: HamDigitalDigest 99/257L
Path: DB0AAB<DB0ZKA<DB0ABH<DB0SRS<DB0SIF<DB0HSK<PI8DRS<PI8DAZ<PI8GCB<PI8HGL<
PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 991012/1459Z @:PI8VNW.#ZH2.NLD.EU #:7559 [HvHolland] FBB7.00g $:HD_99_257
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA21181 ; Tue, 12 Oct 99 14:00:07 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
id AA00016369 ; Tue, 12 Oct 99 07:48:28 MET
Date: Tue, 12 Oct 99 07:44:45 MET
Message-Id: <hd_99_257L>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/257L
X-BBS-Msg-Type: B
> >(See previous posts).
>
> Then what do you want?
Ideas.
> You start out explaining what would be nice to have and how you
> would propose these things to be implemented, and then you tell
> us that you did these things two years ago (like some others).
Try and understand the difference between one (or a few) people
experimenting with something, and the adoption of this "somthing"
into general use in the network.
> Was this just a repost of a historic document?
It was a request to open a discussion.
At least one poster has suggested some interesting ideas.
> My own bi-directonal mail forwarder has been working since Feb 1990.
I've put what I have done onto my web site so anyone can
look at it and make suggestions. Where do I find information
about yours?
--
... Hank
http://horedson.home.att.net
>.
------------------------------
Date: (null)
From: (null)
> 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.
With my view, this would be "ax25.nts", which could be further subdivided up
by
state (e.g. "ax25.nts.ny")...
> 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.
I have a problem with this - maybe: Existing usenet groups aren't restricted
to just licensed radio amateurs, and not every country supports "third-party"
transmissions. In contrast, a new hierarchy ("ax25.*") could be arranged so
that only messages ORIGINATED from packet BBS's appeared in the newsgroup.
> 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.
You lost me with this paragraph....
> 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."
That's easy: Run LINUX (w/ ax.25 support) as the OS. The TCP/IP
implementation and such easily follows. Kill MS-DOS. Kill Windows.
> 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.
Yes, but what most people seem to bitch about is USING the Internet to replace
wireless links - and for emergency communication purposes, they're correct.
It's interesting that here in Southern California, our local SCDCC (Digital
Council) chair (me) is pro-TCP/IP, yet our local SCAPS (packet BBS sysops)
chair is anti-TCP/IP (at least as far as traffic forwarding is concerned), yet
our groups are getting along quite well. [For those in the western states,
the
members of SCAPS are all part of "Westnet" - the packet BBS network for the
western third of the U.S.]
In fact, on the SCDCC web site (namely, at
"http://www.qsl.net/scdcc/iprestrict.html"), we have reserved a page for
traffic restrictions for TCP/IP - classic AX.25 BBS interchange (but are still
working on what those restrictions should be). My PERSONAL view of those
restrictions are as follows:
- E-mail: None as a result of a TCP/IP source. The AX.25 network may
already have its own size limits....
- News: No non-amateur originated bulletins should traverse.
- Callbooks: Single and low volume lookups may occur, but high volume
lookups (like "all of zipcode 10001") are discouraged.
- Web pages: Only text-only pages of probably no more than 4k should
be allowed - all others should probably be banned. (size could be adjusted)
- FTP: Same - size limit of maybe 10k.
- Telnet: Allowed - effectively the same as using Net/ROM nodes.
- All other traffic: Either forbidden or not supported.
Remember that these are meant for AX.25-BBS to TCP/IP interchange only and are
*** NOT *** restrictions to be imposed on a TCP/IP-only reserved frequency.
>.
------------------------------
End of Ham-Digital Digest V99 #257
******************************
You can send in your contribution to this digest by
sending an e-mail to: hd-group@pa2aga.ampr.org
or (via BBS-net) to: hdaga@pi8vnw.#zh2.nld.eu
Read previous mail | Read next mail
| |
