Subject: Ftp-WG: MLST implementations?

From: "Jan Mikkelsen" <[email-masked]>
Date: Tue, 19 Oct 1999 18:52:28 -0400

>For the client, MLST is easier, as with MLST it *knows* when support is
>present, and hence doesn't have to guess any more (falling back to
>guessing only when MLST isn't available).  For EPLF guessing will remain
>forever - and quite peroably need to deal with EPLF lookalikes where
>someone just decides that they can "improve" things a bit (if one person
>can simply define what EPLF is, any other person can similarly define a
>slightly different, hard to distinguish, improved version).

It strikes me that if a server's LIST response is in EPLF format it should
include (say) "EPLF" in the FEAT response so that the client doesn't have to
guess.  This would let a modern client do a single command to figure out its
strategy for the session (ie: EPLF, MLST, LIST response parsed by goat
entrails, whatever).  As kre says, looking at a bunch of bytes and guessing
is prone to failure.

This way, if a server advertises EPLF, and serves "improved" EPLF, things
should, correctly, break.

I'm curious though;  has anyone done a survey of what EPLF does to old FTP
clients?  In other words, how many clients fail to simply produce the LIST
response as received if it isn't in a format they recognise?

>But as Alun said, all this has been discussed before.

I seem to have missed that discussion. :-)

Jan Mikkelsen

---

From: Alun Jones <[email-masked]>
Date: Tue, 19 Oct 1999 21:17:46 -0400

>I seem to have missed that discussion. :-)

It's all in the archives - a brush through that will allow you to see what
has, and hasn't been discussed, and perhaps also reveal other avenues tried
and either discarded or taken up.  You might even find Dan's original
reasons for not wanting a FEAT command to allow negotiation of EPLF as the
listing format ;-)

As for clients that don't display the listing format "as received" - note
that most clients on operating systems other than Unix are graphical in
nature, and they like to filter out the file names, figure out which is a
file, and which is a directory, etc.  The option to "simply produce the
LIST response as received" is not present for such clients.

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: Robert Elz <[email-masked]>
Date: Tue, 19 Oct 1999 21:57:58 -0400

Date:        Tue, 19 Oct 1999 18:52:28 -0400
    From:        "Jan Mikkelsen" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'm curious though;  has anyone done a survey of what EPLF does to old FTP
  | clients?  In other words, how many clients fail to simply produce the LIST
  | response as received if it isn't in a format they recognise?

Alun didn't explicitly say, but another case where that is useless is
with clients that have no human user (eg: mirror).   The application is
attempting to parse the listing output for its own purposes, rather
that to show to a human in any form.

Looking at the ls parsing in mirror is truly awesome - it can parse (or
at least attempt to) all kinds of random variations of list formats.
Getting rid of that kind of guessing is one of the aims of MLST.

And yes, a FEAT indicator of EPLF would get rid of one of its major
problems, though before that would happen, there'd need to be a stable
definition (ie: RFC) defining EPLF - for which so far there has been
no progres (not even initiation) at all.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: Wed, 20 Oct 1999 11:35:09 -0400

> Getting rid of that kind of guessing is one of the aims of MLST.

Time for a reality check.

Adding MLST support to the mirror program wouldn't simplify it at all.
It still needs to support the other formats.

If MLST is going to succeed in ``getting rid of'' the other formats, it
has to be supported by _every_ server, or at least every server that the
users care about.

Universal support is precisely the problem that the MLST proponents
refuse to consider. Universal server support for MLST is, thanks to the
MLST design, far more difficult than universal client _and_ server
support for EPLF. This is why MLST isn't going anywhere.

---Dan

---

From: Alun Jones <[email-masked]>
Date: Wed, 20 Oct 1999 12:01:02 -0400

>It still needs to support the other formats.

Time for a visit to your optometrist for a vision check.  Robert never said
it would simplify the mirror program, nor that the problems will go away
immediately.  As has been noted before, and I hate to waste time repeating
the old arguments, it's far more likely that servers will become upgraded
to any new (acceptable) standard than it is likely that clients will.
Hence, any strategy that essentially suggests that server authors wait to
implement until 'sufficient' numbers of clients are upgraded seems doomed
to an obvious failure.

MLST seeks to provide something that servers can implement immediately, and
which clients can upgrade to as they see fit.  Neither set of implementors
need to wait for the other to catch up - as you note, the client authors
will be supporting the old servers anyway.  MLST aims to _eventually_
supplant LIST for machine-parsed listings, and thereby avoid the
complexities of having to cope with any number of response formats.  EPLF
appears to expect that a magic wand will be waved someday, at which point
all clients will support EPLF, and server authors will be able to ditch
their /bin/ls compatible outputs.

>has to be supported by _every_ server, or at least every server that the

MLST is not looking to get rid of anything.  It is an attempt to provide a
machine parseable listing format, which will be used by tools that require
automated parsing.  LIST will still be there for display to users, should
such an output be required or desired.  It may even have the effect of
freeing up LIST to display exactly what the local directory listing format
would look like - I know my Windows based server _had_ to produce a
Unix-style listing and 'invent' values for fields that have no meaning to
it; otherwise, clients would discard its output as bogus.

>support for EPLF. This is why MLST isn't going anywhere.

Universal server support for MLST may be difficult to write - personally,
since I have to write the listing function whether I use MLST, EPLF, or a
/bin/ls compatible output, I don't see that.  However, it is far easier to
make a case for its implementation and adoption.  I could ship an
MLST-compliant server the day after the RFC gets published, and have
absolutely _zero_ complaints of clients that fail to display listings.  If
I ship an EPLF-compliant server now, six weeks from now, or six months from
now, I _know_ I will get hundreds of complaints from customers angry that
their clients can no longer navigate through their site.

As far as I am concerned, EPLF is unimplementable; MLST is implementable,
or will be as soon as it is finalised.  As for MLST not going anywhere, I
might note that MLST has an IETF draft under _active_ discussion, and will
eventually make it to the status of an RFC.  EPLF has a specification that
independent server authors throughout this working group have stated they
cannot afford to implement, and that they will not support if it is
submitted as an IETF draft without substantial modifications that the
specification's original author refuses to make.

From my vantage point, MLST seems to be proceeding toward adoption, and
EPLF is mired in the detritus of its own discharge.  Dan, unless you have
something new to say, I'm done talking with you.

Alun.
~~~~

---

From: "D. J. Bernstein" <[email-masked]>
Date: Sat, 23 Oct 1999 09:05:00 -0400

Robert Elz writes:
> a stable definition (ie: RFC) defining EPLF - for which so far there
> has been no progres (not even initiation) at all.

False. I submitted EPLF as an experimental RFC in March 1996. The IESG
waited for three months and then told the RFC editors not to publish it.

See http://pobox.com/~djb/proto/rfced.html for an even more blatant
example of what's wrong with the RFC series. Implementors are better
served by talking to each other directly.

It's not my fault that the IESG refuses to publish documentation of
existing RFC-959-compliant FTP LIST formats.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: Sat, 23 Oct 1999 11:01:32 -0400

Alun Jones writes:
> MLST seeks to provide something that servers can implement immediately,

Yes, it does, but _why_?

Precisely what benefits are you offering to users, or to system
administrators, or to FTP server implementors?

What exactly is your plan for achieving those benefits? What costs are
incurred by that plan? Are all the costs necessary? In particular, why
does the plan depend on servers implementing MLST immediately?

---Dan

---

From: Stephen Tihor <[email-masked]>
Date: Sat, 23 Oct 1999 12:51:15 -0400

This appears to have degenerated into a personal screed rather than technical
discussion.  It is substanaticly redundant with previous dicussions.  Further
Mr. Bernstein's tone is so grating and his debating techniques sufficiently
misleading as to insure many folks will ignore his good ideas as the ranting of
an obsessed monomaniac rather than reasonable proposals from someone willing to
make the sort of compromises that have insure the success of the internet
protocols so far.  

Please take this level of discourse elsewhere and ceases to repeat the
substances of past postings to the list.

---

From: "D. J. Bernstein" <[email-masked]>
Date: Sat, 23 Oct 1999 12:35:45 -0400

Alun Jones writes:
> MLST aims to _eventually_
> complexities of having to cope with any number of response formats.

Gee. Didn't you argue in 1996 that clients couldn't rely on PASV, even
though all servers had been required since 1989 to support PASV?

Client implementors don't want the complexities of having to cope with
both PORT and PASV. The obvious response is to use just one of them---
the better choice being PASV, as explained in RFC 1579.

But they can't do that, you said. Non-PORT clients are unreliable, you
said. Old versions of your server WFTPD didn't support PASV, you said.

``Judging from the fact that I'm still receiving order forms with that
old version number printed on them, there's plenty of these servers
still out there,'' you said, though you didn't identify any of their
addresses when I asked. ``Try as I might, I can't ever replace all the
out-dated copies of my software.''

You insisted repeatedly that all future clients had to support PORT
because we couldn't add PASV to every obsolete server on the Internet.
``Requiring PORT support from future clients is possible,'' you said.
``Fixing all the non-PASV servers that are already out there and running
quite happily is not.''

But now you say that we can add MLST to every server so that future
clients don't have to support /bin/ls.

---Dan