home *** CD-ROM | disk | FTP | other *** search
/ HAM Radio 1 / HamRadio.cdr / misc / pkthints / pd91046.txt < prev    next >
Encoding:
Internet Message Format  |  1991-02-18  |  9.4 KB
  1. From wang!elf.wang.com!ucsd.edu!packet-radio-relay Sun Feb 17 18:17:50 1991 remote from tosspot
  2. Received: by tosspot (1.63/waf)
  3.     via UUCP; Sun, 17 Feb 91 18:06:14 EST
  4.     for lee
  5. Received: from somewhere by elf.wang.com
  6.     id aa15669; Sun, 17 Feb 91 18:17:48 GMT
  7. Received: from ucsd.edu by uunet.UU.NET (5.61/1.14) with SMTP 
  8.     id AA28682; Sun, 17 Feb 91 08:44:24 -0500
  9. Received: by ucsd.edu; id AA09612
  10.     sendmail 5.64/UCSD-2.1-sun
  11.     Sun, 17 Feb 91 04:30:12 -0800 for hpbbrd!db0sao!dg4scv
  12. Received: by ucsd.edu; id AA09602
  13.     sendmail 5.64/UCSD-2.1-sun
  14.     Sun, 17 Feb 91 04:30:09 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list
  15. Message-Id: <9102171230.AA09602@ucsd.edu>
  16. Date: Sun, 17 Feb 91 04:30:06 PST
  17. From: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>
  18. Reply-To: Packet-Radio@ucsd.edu
  19. Subject: Packet-Radio Digest V91 #46
  20. To: packet-radio@ucsd.edu
  21.  
  22.  
  23. Packet-Radio Digest         Sun, 17 Feb 91       Volume 91 : Issue  46
  24.  
  25. Today's Topics:
  26.                     'To:' field anarchy! (2 msgs)
  27. Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway) (2 msgs)
  28.                        Internet->packet Gateway
  29.  
  30. Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
  31. Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
  32. Problems you can't solve otherwise to brian@ucsd.edu.
  33.  
  34. Archives of past issues of the Packet-Radio Digest are available 
  35. (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
  36.  
  37. We trust that readers are intelligent enough to realize that all text
  38. herein consists of personal comments and does not represent the official
  39. policies or positions of any party.  Your mileage may vary.  So there.
  40. ----------------------------------------------------------------------
  41.  
  42. Date: 7 Feb 91 14:16:52 GMT
  43. From: mcsun!ukc!acorn!agodwin@uunet.uu.net  (Adrian Godwin)
  44. Subject: 'To:' field anarchy!
  45. To: packet-radio@ucsd.edu
  46.  
  47. In article <1991Feb6.190903.1295@axion.bt.co.uk> blloyd@zaphod.axion.bt.co.uk writes:
  48. >Well, a fair few of us BBS writers read this newsgroup, so maybe this would
  49. >be a good place to work out something better. I've added an LG command
  50. >(List Group) to my software which lists all the TO `groups' and the number
  51. >of messages in each group. You can also type LG group_name (eg LG RAYNET)
  52.  
  53. This sounds good, but the main point I wanted to make was that there should be
  54. some encouragement whilst actually posting - so users are gently reminded that 
  55. they're posting outside the currently accepted set of topics. I don't think
  56. educating users is sufficient - there will always be new users who don't know
  57. the netiquette, and don't RTFM. 
  58. Gentle prompting towards a more conveniently organised system seems much more 
  59. likely to work, provided that such a system is seen as good by most users.
  60.  
  61. Aliases might be used to remap common TO errors into the more accepted set.
  62.  
  63. It seems wrong to treat one group name differently from others, but perhaps an
  64. entry to ALL should result in an additional prompt to try and obtain a more
  65. specific subject from the user - there's likely to be so many users posting to
  66. ALL that an automatic offer to create a group called that would soon be taken up, 
  67. and no more warnings would be produced. (Yes, I know I argued differently 
  68. previously - I'm just thinking it through :-))
  69.  
  70. I suspect that having a concept of a 'current group' as used by most other 
  71. newsreading software means less typing to select a batch of related news items - 
  72. but perhaps that's just my prejudice.
  73. I certainly find the requirement to remember a whole list of 'interesting'
  74. article numbers, then typing them in 6 at a time fairly irritating - but then
  75. I'm used to a network terminal where it's often quicker to read every article,
  76. hitting the 'junk' key after reading a few lines, than selecting subjects from
  77. a list. 
  78.  
  79. I imagine that the user information stored on current BBSs is quite small, and
  80. would be vastly increased by tracking the articles read in each group, rather
  81. than globally. Is this likely to be a problem ? Do packet BBSs have much larger
  82. user bases than telephone BBSs ?
  83.  
  84. I'm not especially interested in a religious argument about the merits of using
  85. TCP/IP for news distribution - though I would be interested to read a balanced
  86. summary of any previous discussions. It may well be that news will eventually be 
  87. distributed between BBSs and TCP/IP users by another method, and fixed TO
  88. groups would certainly assist that. If you feel inclined to start that war, 
  89. consider this discussion to be about user interfaces to newsreaders/posters, 
  90. regardless of whether that interface runs locally or on the BBS.
  91.  
  92. -- 
  93. --------------------------------------------------------------------------
  94. Adrian Godwin                                        (agodwin@acorn.co.uk)
  95.  
  96. ------------------------------
  97.  
  98. Date: 7 Feb 91 21:59:57 GMT
  99. From: shelby!paulf%shasta.Stanford.EDU@uunet.uu.net  (paulf)
  100. Subject: 'To:' field anarchy!
  101. To: packet-radio@ucsd.edu
  102.  
  103. There is an easier solution to all of this.  With the conversion of most 
  104. minicomputing lines to RISC architectures (SUN, DEC, SGI et al), there are
  105. a ton of surplus unix boxes appearing on the market, at prices far less than
  106. the typical 386 box.
  107.  
  108. Has anybody written the equivalent of G protocol KISS code?
  109.  
  110.  
  111. -=Paul Flaherty, N9FZX      | Without KILL files,
  112. ->paulf@shasta.Stanford.EDU | life itself would be impossible.
  113.  
  114. ------------------------------
  115.  
  116. Date: 7 Feb 91 16:45:29 GMT
  117. From: pa.dec.com!shlump.nac.dec.com!koning.enet.dec.com@decwrl.dec.com  (Paul Koning)
  118. Subject: Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway)
  119. To: packet-radio@ucsd.edu
  120.  
  121. |>
  122. |>  My copy of Part 97 is in the ARRL "The FCC Rule Book". None of these
  123. |>paragraphs (a) exist or (b) say the same thing. Has Part 97 really changed
  124. |>that much since November 1, 1987?
  125. |>
  126.  
  127. It certainly has!  Part 97 was completely rewritten last year.  Throw out
  128. your ancient copy and get a new one...
  129.  
  130.     paul
  131.  
  132. ------------------------------
  133.  
  134. Date: 7 Feb 91 17:07:38 GMT
  135. From: idacrd!mac@princeton.edu  (Robert McGwier)
  136. Subject: Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway)
  137. To: packet-radio@ucsd.edu
  138.  
  139.  
  140.  
  141. ------------------------------
  142.  
  143. Date: 7 Feb 91 21:39:41 GMT
  144. From: att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!clarkson!@ucbvax.Berkeley.EDU  (Tadd,KA2DEW, ,3152621123)
  145. Subject: Internet->packet Gateway
  146. To: packet-radio@ucsd.edu
  147.  
  148.  
  149.  
  150. ------------------------------
  151.  
  152. Date: (null)
  153. From: (null)
  154. What if the guy originating the message IS a ham but is typing something
  155. that he/she doesn't expect to go over ham radio packet?  
  156.                                Tadd - KA2DEW
  157.  
  158. [ KA2DEW @ KA2JXI.#NNY.NY.USA.NA                - Tadd Torborg             ]
  159. [ torbortc@clutx.clarkson.edu                   - 26 Maple St - PO Box 330 ] 
  160. [ NEDA (North East Digital Association) Editor  - Colton, NY 13625         ] 
  161. [ Clarkson University                           - 315-262-1123             ]
  162.  
  163. ------------------------------
  164.  
  165. Date: (null)
  166. From: (null)
  167. Yes Dana:
  168.  
  169. There was a rewrite in 1988, with some other changes made in 1990.  The
  170. ARRL asked that the very paragraphs used in this citation be made more
  171. explicit and less vague and open to interpretation and the FCC rejected
  172. the request.  The ARRL has tried to make changes that would help but many
  173. times their efforts have gone awry.  The most egregious are the codification
  174. and sanctification of AX.25L2V2 in Part 97 after we were explicitly
  175. promised that this would NOT occur and the rewrite in 1988 that included
  176. more confusing language, and in some cases contradictory language on
  177. bits, bauds, spectral occupancy, and more.  I do wish they would take
  178. the time to ask people with some expertise/interest to look things over
  179. and to comment in a timely fashion.
  180.  
  181.  
  182. These opinions notwithstanding, I am supportive of a strong effort, if not
  183. by us, then by the FCC to clean up ALL@USA which is in a gray area in Part
  184. 97 AT BEST IMHO.  The ARRL (the general manager in particular) will have
  185. a policy statement in the NEXT QST which attempts to address this problem
  186. and call for a solution.  Too bad we had to have FCC action before our
  187. own folks got in behind the problem.
  188.  
  189. AMSAT-NA, a large use of packet networks for distribution of news, has
  190. taken an extremely conservative stance of late (the last several months)
  191. after we had one of our officers, W2RS, point out to us that new bulletins
  192. containing our telephone number, or announcing software availability, etc.
  193. was, at best, not in the spirit of those portions of Part 97 concerned
  194. with business communications.  We told WEBER that they could NOT do their
  195. planned mission (having paid employees do experiments on their satellite)
  196. using amateur radio frequencies and more.  If others don't take similar
  197. stands, and exercise similar restraint, then the FCC can AND SHOULD step
  198. in.  It is my opinion that they have gone too far with this particular
  199. set of citations but there is NO ONE to blame buts ourselves.
  200.  
  201. Bob N4HY
  202.  
  203. -- 
  204. ____________________________________________________________________________
  205.     My opinions are my own no matter    |    Robert W. McGwier, N4HY
  206.     who I work for! ;-)            |    CCR, AMSAT, etc.
  207. ----------------------------------------------------------------------------
  208.  
  209. ------------------------------
  210.  
  211. End of Packet-Radio Digest
  212. ******************************
  213.