comments on comments

[April Marine <[e-mail]>]

Hi all.

I have had a chance to actually READ the comments that people sent on
the draft "how to anony ftp" doc.  Excellent comments!  I really
appreciate them!  Most of them I incorporated into the doc.  BE SURE
TO RE-READ THE DOC IN CASE YOU DISAGREE WITH ANY OF THE NEW STUFF!
(That "re"-read applies to those of you who have read it! ;-)

There are several suggestions/points that I didn't do anything with
either because they were of a technical nature beyond me, or
because I disagreed with the suggestion and want to throw it up
for a vote.  Lots of stuff suggested is stuff I can't write.

I have combined everything I have comments on into this message.
I put someone's comments under his or her name, then add my
comments after "AM:" (my initials, get it?).

My guess is that all of this should be on the agenda for the meeting
in DC.  For those things I punt the writing of, perhaps volunteers can
be recruited.  Gee, too bad I won't be there. 

For those who sent comments, pls check your affiliations in the acks
section (I'm going to send the slightly revised doc next) as I mostly
guessed from your email addresses.  For those who sent comments, but
whose names are not in *this* message, it just means that I got it the
first time for a change.

Again, great thanks for all the response, especially for the improved
text provided!  

--April


From Bob Peterson:

{ You might mention somewhere the problem introduced by "firewall"
configurations, i.e., where an institution's Internet access is
limited. FTP may work fine across the internal network, but all
attempts to contact, e.g., nic.ddn.mil, will fail.  Typically such
users either have no interactive Internet access, or they must log onto
a specific machine in order to interactively use Internet resources
such as FTP. }

AM: Good idea, I think, but I'm not sure we want to get too far into
it.  We might want to say something like, "This doc assumes you
can do ftp.  If you have problems, ask your site sys admin"  without
going in to too much detail about problems.

>     RFC 959.  The text that accompanies these reply codes

{ How about using this RFC as the example file below? }

AM:  Well, I don't really care, but it seems to me that someone
who's just learning how to FTP probably needs the new user Q&A more
than the FTP spec.  I can be easily overruled on this.

{ You might want to mention TENEX mode, since at least one very
important archive site (SIMTEL) needs it. }

AM: A good example of something someone else can write. :-)


{ I suggest you mention the zoo format, heavily used for its
portability across multiple operating systems, and used for the
majority of posting in the comp.binaries.ibm.pc newsgroup. }

AM:  Another good example of something someone else can write...


{ I suggest a short annotated bibliography be added, pointing to
documents such as the following.

AM: If we do, we can just refer to the new novice userdoc, which lists
several docs, including your examples, useful to newbies.  Seems silly
to repeat the list.


From Stephen Tihor:

but this may have implications on how the file is transformed 
to your local system. 

<<    If you are not sure what format a file is in, it does not hurt
      to user BINARY mode as a default.
-- this is just plain wrong >>

AM: This seems to be the consensus!  I have marked this section in
the doc for someone wiser than I to deal with and correct.  Thanks
for spotting it.


  11) Multipart shar/vms_share files

[....]
  Collect all the parts,m concatenate them on your local system, and then
  apply the normal tool to the result.

AM: Did not get this last part.  Added it to the doc, but marked the
question.  Thanks a bunch for actually writing the text for all the
additions!  You may want to check it to make sure my slight edits
did not distort the meaning.


From Aydin Edguer:

A correction:
>     If you are not sure what format a file is in, it does not hurt
>     to user BINARY mode as a default.

This is not strictly true.  When talking to a machine that does not use
8-bit bytes (example DEC-20), binary will not work correctly as a default.

If it is a text file, then transferring between systems in binary mode
can cause problems for users.  I have gotten too many questions about
"why does the this file have no carriage returns" and "why is there
a ^M at the end of each line".


AM:  Definite problems with this section!  I punt the re-writing.


You give an explanation of "8) binhex" on the Macintosh but do not include
the many other formats used by FTP archives for Macintosh files.  Examples
include ".sit", ".cpt", ".image", ".pit", and ".sea". You might want to check
out the comp.sys.mac.comm FAQ.

Similarly you include "6) zip" and "7) arc" but do not mention the ".lzh",
".zoo", or ".sqz".  You might want to check out the FAQ for the newsgroup
comp.binaries.ibm.pc.archives.


AM: These sounds like good ideas for additions, but, again, I can't
write them.  Punt.  (Btw, I really liked your final statment regarding
ethical use of anony FTP.)