Subject: Ftp-WG: MLST Draft Comments

From: Paul Hethmon <[email-masked]>
Date: Fri, 21 May 1999 17:01:25 -0400

I've been trying to go through the MLST draft and related
comments on it since the first of the year and I think
I've come up with the list of issues which are outstanding.

For each issue, I've summed it up and then offered my
opinion on it. My opinion also emcompasses the working group
view as much as possible. So what you need to do is read
this note and reply to it, either positive or negative.

MLST Open Issues:

1. HOST reply code: 220 vs 234 reply code

234 Reasoning: Editor's belief that the HOST command
is an authentication command and hence according to reply
code theory, 23x would be correct.

220 Reasoning: After a HOST command the server should be
in an "initial" state awaiting the clients first command,
just as a server would be now. The reply is about establishing
a connection with the virtual server.

*** Chair's Opinion: Go with the 222 reply code suggested earlier
on the list. I think it's a close toss-up as to whether HOST
qualifies as an authentication or connection command. Given
the argument of implementing a "wrapper" process around a
current server, I'd give preference to the connection command.
Going with 222 gives a distinctive reply code for HOST.

2. Directory Permission Bits

Should the current "l" bit be split into two bits, one
to indicate a directory can be listed, a second to indicate a
directory may be searched (ie you can get to the files in the
directory). Reasoning is that the "l" bit currently requires both
which makes it possible to list directories which have no
permissions at all.

*** Chair's Opinion: I kind of think leaving this one as is. My
thinking is that while a quirk, it does no harm. The example I
think of is a directory which has "l" set. Inside the directory
are several files. Those files have their own permissions which
don't allow them to be seen. Hence they override the "l" bit
on the directory. The Unix case that a directory itself has
permissions which don't allow the contents to be referenced is
similar.

Another thought is to strike the last sentence of the draft:

Original>
   The "l" permission applies to the directory file types, and indicates
   that the listing commands, LIST, NLST, and MLSD may be applied to the
   directory in question, and that MLST, LIST, NLST, and STAT may be
   applied to objects in the directory.
New>
   The "l" permission applies to the directory file types, and indicates
   that the listing commands, LIST, NLST, and MLSD may be applied to the
   directory in question.

We don't specifically say that it means you can see the objects in
the directory, but you can try.

I'm open to these suggestions or even possibly adding another
permission bit. If someone wants another permission bit, then now is
the time to argue for it.

3. Fact delimiter vs terminator for the ";" (semi-colon)

As currently defined, the ";" character is the fact delimiter.
Implmentation experience has shown that defining it as a
fact terminator leads to easier code on both client and
server. This can be a good thing since new implementations
are easier.

*** Chair's Opinion: Make it a terminator. Life is easier.

4. Response to OPTS MLST

The spec currently says a server is to issue an error response
when a client requests a fact which is not a standard fact 
and which is not a non-standard fact the server implements.
Suggestion is to only return an error response on syntax
errors and ignore the request for unknown facts.

As a corollary, the response to OPTS MLST could be a defined
format which lists the currently selected fact set.

*** Chair's Opinion: I'd say this matters more to client
authors than server authors. Any client authors want to speak
up here about which is easier/better to implement? If no one
speaks up, then I guess it will stay as is.

5. OPTS MLST format

Should the format of OPTS MLST also be changed so that the ";"
character is the terminator instead of separator character? So
section 8.9 becomes:

        mlst-opts     = "OPTS" SP "MLST"
                        [ SP factname ";" *(factname ";") ]

Just going along with #3 here, this seems simpler to implement.

*** Chair's Opinion: This I noticed while putting together this
list. So it's my issue. If other's think it is a good idea, then
we'll change the draft. If no one speaks up, we'll leave it as
is.

---

From: "Mike Gleason" <[email-masked]>
Date: Fri, 21 May 1999 17:32:03 -0400

>*** Chair's Opinion: Make it a terminator. Life is easier.

Agreed.  Please make it a terminator.

>errors and ignore the request for unknown facts.

My client program would prefer not to receive an error for the above 
scenario.  Although I could make a note of the FEATure response for MLST 
and carefully form an OPTS MLST using only the server's supported facts, 
I'd prefer to have a canned set of facts that I'd request for every 
server.  The resulting listings may only contain a subset of those facts 
for each item, but a client must already be ready for that behavior (simple 
example: there may not be a size fact returned for a directory item).

>format which lists the currently selected fact set.

We don't have to require this, but it is very useful.  The well-defined 
format would be a bonus that would allow a client author know exactly which 
subset of server facts to expect, if desired.  Here's a mini-example:

     >> OPTS MLST 
type;size;modify;UNIX.mode;UNIX.owner;UNIX.uid;UNIX.group;UNIX.gid
     << 200 Options accepted: type;size;modify;UNIX.mode

>Just going along with #3 here, this seems simpler to implement.

I agree that the draft should be changed to reflect the above.  This should 
also be applied to the "Options accepted" message, above.

Mike Gleason

---

From: Alun Jones <[email-masked]>
Date: Fri, 21 May 1999 17:59:45 -0400

Since I came up with the HOST code, and the justification for the 220
response, I thought I might add a little here on that:

>Going with 222 gives a distinctive reply code for HOST.

I'm still not sure that I understand why a wrapper that calls an external
'ftpd' type of process would be able to turn 220 messages into 222 any way
better than it could turn them into 234 messages.

If the response to HOST can be 220, then the 'wrapper' can simply pass the
control connection in as stdin/out to the 'ftpd' process.

If the response to HOST has to be anything other than 220, then the
'wrapper' must be a real wrapper, i.e. actively filtering what the ftpd
process sends back out.

I was kind of envisioning a HOST wrapper that would act rather like inetd,
accepting the initial connection (and in this case, the HOST command)
before passing the input and output to an instance of 'ftpd'.  That
instance may be on the same machine, or the wrapper may act as a kind of a
NAT.  Much of this could be done if the HOST response isn't 220, just as
easily as it could with 220 - but there is one item that is made
specifically easier with 220, and the only reason not to use 220 is (as far
as I can tell) a belief that the standard would be more 'pure' perhaps by
choosing a specific response code for that command.

[As a note, this idea of the wrapper simply passing off to a regular 'ftpd'
underscores much of the ideas behind other interactions with HOST, such as
the language selected, whether the command comes before or after a USER
command, etc.]

Alun.
~~~~

--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613     | us at [email-masked].  VISA / MC accepted.
Fax +1 (512) 378 3246   | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*WFTPD and WFTPD Pro now available as native Alpha versions for NT*

---

From: Alun Jones <[email-masked]>
Date: Fri, 21 May 1999 18:02:54 -0400

>     << 200 Options accepted: type;size;modify;UNIX.mode

As a nod to the language-specific folks, should we have any text in there
that is in a specific language?

Alun.
~~~~

---

From: Robert Elz <[email-masked]>
Date: Tue, 25 May 1999 21:26:10 -0400

Date:        Fri, 21 May 1999 17:01:25 -0400
    From:        Paul Hethmon <[email-masked]>
    Message-ID:  <[email-masked]>

  | 1. HOST reply code: 220 vs 234 reply code
  | Going with 222 gives a distinctive reply code for HOST.

If we were to do that, I'd stick with the 234 that is there now
by preference - but I had pretty much already concluded that there
wasn't much support for that position, and there was at least some
support (and rationale) for 220, so if there hadn't been this extra
debate over the past few days, I would have just made it 220.

The other option, which you didn't mention of course, is to allow
either.   That lets server authors who have an integrated client
do 234, those with a wrapper which hands off to different ftp servers
(or the same one with different options or in a different environment)
use 220.   The drawback is that clients (those whch check more than
just the leading '2' they probably ought be checking) need to allow
for either possibility.

But wrt the conversation between Alun and Gregory ...

[email-masked] quoted [email-masked]:
| > Noted, but doesn't this mean that the presumably regular ftpd to
| > which you'll be passing the connection will _then_ also generate its
| > usual 220 greeting?

and then said:
| Almost certainly.

That would certainly be wrong.    Only one 2xx response allowed to any
FTP command, not two.   That is, after the HOST command, if you were to
give a 222, or 234 response, no 220 would be permitted after.

Simply accepting the host command (assuming it was valid) and passing it
off to a server which then emits the 220 banner it currently does would be
fine (assuming we do allow or require a 220 response).   Or, giving a response
and then handing off to a server which emits no welcome message at all, but 
just waits for the next command.

I hope that the draft is already clear enough (if not, please tell me, and
if possible suggest improved language) that it is fine to "forget" any
negotiated info (such as language) when a HOST command is received.   The
basic intent is that HOST is the first command an FTP client sends when
it commects, based entirely upon its idea of where it was trying to connect.
That is, the TCP open and the HOST command go hand in hand.   Even allowing
a HOST command later in the process seems a bit wrong to me (though while we do
need to define what a server should do when it sees that, I don't think that
clients should ever split the TCP connection and the HOST command, the two
should be considered a unit, part of the FTP TCP connection opening process).

Should the draft say more about that?

  | 2. Directory Permission Bits
  | Another thought is to strike the last sentence of the draft:

That looks like the right thing to do to me.   Then if sometime later
we find that being able to access objects in a directory needs a separate
permission bit, we (someone) can add one.

  | 3. Fact delimiter vs terminator for the ";" (semi-colon)
  | *** Chair's Opinion: Make it a terminator. Life is easier.

Consider it done.

  | 4. Response to OPTS MLST
  | *** Chair's Opinion: I'd say this matters more to client
  | authors than server authors. Any client authors want to speak
  | up here about which is easier/better to implement? If no one
  | speaks up, then I guess it will stay as is.

Still waiting on this one.

On Alun's comment though ...

[email-masked] said:
| As a nod to the language-specific folks, should we have any text in
| there that is in a specific language?

If we do make the response to OPTS MLST list the options that were
actually set, then it is going to take an awful lot of pressure to make me
write text/abnf which permits arbitrary English (or French, or anything else)
in the response.   That is, the most likely response format would be
something like

	mlst-opts-ok = "200 " *(factname ';')

(using the ';' as a terminator again here).  Mike's "Options accepted: "
noise would need to go.

  | 5. OPTS MLST format
  | Should the format of OPTS MLST also be changed so that the ";"
  | character is the terminator instead of separator character?

Clearly the two (#3 and this one) ought be consistent, so consider
this changed as well.

I will wait another day or two for any more comments on all of these
isssues, and then send in a new draft (maybe even our last draft?)

kre

---

From: Gregory A Lundberg <[email-masked]>
Date: Tue, 25 May 1999 21:44:12 -0400

On Tue, 25 May 1999, Robert Elz wrote:

> Simply accepting the host command (assuming it was valid) and passing
> it off to a server which then emits the 220 banner it currently does
> would be fine (assuming we do allow or require a 220 response).  Or,
> giving a response and then handing off to a server which emits no
> welcome message at all, but just waits for the next command.
> 
> I hope that the draft is already clear enough (if not, please tell me,
> and if possible suggest improved language) that it is fine to "forget"
> any negotiated info (such as language) when a HOST command is
> received.  The basic intent is that HOST is the first command an FTP
> client sends when it commects, based entirely upon its idea of where
> it was trying to connect. That is, the TCP open and the HOST command
> go hand in hand.  Even allowing a HOST command later in the process
> seems a bit wrong to me (though while we do need to define what a
> server should do when it sees that, I don't think that clients should
> ever split the TCP connection and the HOST command, the two should be
> considered a unit, part of the FTP TCP connection opening process).
> 

You are correct.  My wrapper would _silently_ accept the HOST and pass it
off to the normal daemon for a 220 response.  The only time the wrapper
would speak on it's own would be a _negative_ response (ie., unknown
hostname).  In my typical fashion for fidling with stuff like this, left
to myself, I'd not have spotted the problem until my client became
confused by the sequence of events.

The question is what is the greeting number which should be issued on
initial connection.  Frankly, I don't care; obviously something in the 2xy
series.

As to what is the first command, I see LANG, OPTS, et al, as being
possible before HOST.  What effect they have, if any, is debatable.  The
HOST wrapper _may_ pass the information along, or it may not.

-- 

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

---

From: Alun Jones <[email-masked]>
Date: Wed, 26 May 1999 07:54:10 -0400

At 09:26 PM 5/25/99 -0400, you wrote:
>... I don't think that

How about something to the effect of:

"A server accepting the HOST command MAY pass additional state information
through to the host being requested (or keep that information if the host
is the same process as the accepting server).  A client sending the HOST
command SHOULD NOT require or expect that the effects of any command sent
before the HOST command will be honoured by the server after the HOST
command has been received.  A client supporting the HOST command SHOULD NOT
assume that any commands other than HOST will be accepted or have any
effect prior to sending the HOST command.  A client SHOULD send the HOST
command, if it sends it, immediately upon connecting to an FTP server.

"The rationale behind this is that implementations of the HOST command
should be free to work as 'wrappers' - as a separate process, which accepts
the incoming connection, decides which HOST is being requested, and then
passes the connection on to any of a number of external FTP server
processes.  These external FTP servers may be existing RFC-959 compliant
processes, and know nothing of the HOST command."

[If this gets included, do I get an author credit?]

>(using the ';' as a terminator again here).  Mike's "Options accepted: "

It may be nice to use:
    mlst-opts-ok = "200 MLST OPTS " *(factname ';')

The commands are, if not language neutral, at least the same for each
server, and this allows really paranoid FTP client authors to ensure that
they aren't out of step with the server's responses (there may be other
commands that have output similar to "factname;" and the MLST OPTS gives a
fixed string to check against).  Perhaps this also allows people watching
the client's log screen to note what is going on, and more easily guess why
the server isn't responding with all facts requested.

>isssues, and then send in a new draft (maybe even our last draft?)

I'd very much like to see this one become an RFC ASAP.  If only to get my
name in another RFC ;-)

Of course then I'll actually have to implement it. :-(

Alun.
~~~~