home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / networks / tcpip / multinet / 1811 < prev    next >
Encoding:
Text File  |  1992-07-27  |  2.4 KB  |  51 lines

  1. X-Gateway-Source-Info: INTERNET
  2. Path: sparky!uunet!usc!noiro.acs.uci.edu!network.ucsd.edu!mvb.saic.com!tgv.com!info-multinet
  3. Date: 28 JUL 92 06:47:48 GMT
  4. Newsgroups: vmsnet.networks.tcp-ip.multinet
  5. X-Return-path: <info-multinet-relay@TGV.COM>
  6. X-RFC822-From:     adelman (Kenneth Adelman) @ TGV.COM
  7. From: adelman@TGV.COM
  8. Subject:  Re: IAFA-WG -- please help on the VMS side
  9. Organization: The INFO-MULTINET Community
  10. Message-ID: <23804A0328JUL92064748@TGV.COM>
  11. Nntp-Posting-Host: Mvb.Saic.Com
  12. Lines: 37
  13.  
  14. > How I get involved in what I get involved in is and remains a mystery.  If
  15. > you are unaware of it, the Internet Engineering Task Force (IETF) created
  16. > the Internet Anonymous FTP Archive (IAFA) Working Group last November.  To
  17. > date, a draft and a revised draft have been prepared.  You can retrieve
  18. > these by including the command SENDME IAFA in the body of a mail message to
  19. > FILESERV@SHSU.BITNET (FILESERV@SHSU.edu) or by anonymous ftp from
  20. > Niord.SHSU.edu (192.92.115.8) in the directory [FILESERV.IAFA].  Also, if
  21. > you are interested in this, you can subscribe to the group's e-mail
  22. > discussion list, iafa@cc.mcgill.ca, by sending a mail message to
  23. > iafa-request@cc.mcgill.ca and requesting to be added.
  24.  
  25.     I reviewed the documents and have some basic comments. Feel free to
  26. repost these to the IAFA mailing list if you'd like; I have no desire
  27. to attract what I'm sure would be flames --
  28.  
  29.     The information presented in the first part of the draft doesn't
  30. belong in an RFC -- it belongs in a UNIX man page.  It looks like an
  31. attempt to codify what is already practiced on a large part of the
  32. Internet, and to make up for deficiencies in particular vendors'
  33. documentation.    Is this a standards-track RFC?
  34.  
  35.     The later part of the RFC attempts to provide a mechanism for
  36. automated information retrieval, but it does so in a UNIX-specific way
  37. (eg, it constrains filenames to begin with "IAFA-".  What about MS-DOS
  38. server which can't handle the length, or a server which couldn't
  39. handle upper-case names?  What if it couldn't handle lower-case
  40. names?)  It is very UNIX centric, and perhaps worse, makes particular
  41. pecular assumptions about the current behavior of BSD networking (line
  42. 345; part 2).
  43.  
  44.     I don't think the specification should be saved by putting in the
  45. VMS specifics, it wouldn't fix the fundamental flaws associated with
  46. having OS-specifics in a protocol or RFC.
  47.  
  48.     The document also badly needs a spelling checker run on it.
  49.  
  50.                                 Ken
  51.