Subject: Ftp-WG: HOST command and I18N Draft

From: Robert Elz <[email-masked]>
Date: Sat, 20 Mar 1999 00:12:11 -0500

When you have all worked out just what the options and scenarios should
be here, would several (like all ...) of you please re-read the HOST
section of the mlst draft and determine if there is anything that ought
to be reworded (or straight out changed).   (I know I am going to have to
modify it to indicate that language selection is done via LANG, rather than
via an OPTS command which it now suggests, that's trivial).

Also, on the 220 vs 234 as the response to HOST - you all know by now that
Alun wants 220 (and why) and that I believe 234 (or 23x) is the more
correct response, according to the theory of reply codes.   Since no-one
else even seems to desire to proffer an opinion, perhaps I could modify
the draft to say that 234 is the recommended reply, but that 220 is permitted.
That is, servers can send either, and clients need to be prepared for
that.  In practice I suspect a client that looks at more than the '2' is
being unduly pedantic, but we can expect that sometimes.

Also, should I add explicit language (it is already implied in the
definition of error-response) that a server can send a 4xx reply to the
HOST command if the particular virtal host selected is currently unavailable?

kre

---

From: Gregory A Lundberg <[email-masked]>
Date: Sat, 20 Mar 1999 12:39:31 -0500

On Sat, 20 Mar 1999, Robert Elz wrote:

> Also, on the 220 vs 234 as the response to HOST - you all know by now
> that Alun wants 220 (and why) and that I believe 234 (or 23x) is the
> more correct response, according to the theory of reply codes.  Since
> no-one else even seems to desire to proffer an opinion, perhaps I
> could modify the draft to say that 234 is the recommended reply, but
> that 220 is permitted.

Looking strictly at the reply codes section of the RFC (959, ignoring what
it may say elsewhere or what other RFCs/drafts may say), could not the
following be valid as well?

<control connection established>

S> 22z  OK, I'm awake.  Now what?
   23z  I'll try, but I'd like you to select a HOST or login with USER
   32z  You want in?  Tell me more.
   33z  Whadya wan?  Select a HOST, login with USER or go away.
   42z  I can't talk right now.  Maybe later.
   43z  I don't like you right now.  Maybe later.
   52z  I used to be an FTP server.
   53z  Drop dead, I'm not speaking to you!

        Since FTP does not strictly require login, the 23z and 3yz
        responses should be allowed by the client but, for least breakage,
        should not be sent by the server.

C> HOST adventure

S> 22z  Poof!  I'm 'adventure'.  What next?
   23z  OK, but I'd still like you to log in as a USER.
   32z  More.  More.  Tell me more!
   33z  So I'm 'adventure' .. tell me who you are or drop dead.
   42z  I'd like to but I can't seem to do it right now.  Maybe later.
   43z  I tried.  Honest.  'adventure' said come back later.
   50z  Something was funky about your command.
   52z  Dunno who 'adventure' is.  Sorry.
   53z  I tried, but 'adventure' doesn't like you so drop dead.

        Here, again, there is no _requirement_ that a login be made, so
        Alun's suggestion of 220 is more correct.  I'd suggest that the
        response be 222 only so we can differentiate it from the
        generic-server's 220 response.

        Once again, the 23z and 3yz responses should be accepted by the
        client but should not be sent by the server.  One should expect
        a server using 23z or 3yz in the initial, generic-server, response
        would continue in the same vein for the HOST-server response.

-- 

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195