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