Subject: Ftp-WG: MLST implementations?

From: "Jan Mikkelsen" <[email-masked]>
Date: Wed, 20 Oct 1999 08:54:27 -0400

>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.

Yes, I see the problem; I'm trying to understand just how big a problem it
is.  I just did a quick test with IE4 against an EPLF server, and it failed
badly (although it worked well through Squid).  So I guess the problem is
rather large. :-)

And I suspect that the GUI browser that Alan mentioned is a much larger
problem than mirror applications, which (I would guess) are more often run
by knowledgeable users potentially even with source access.  If an FTP site
fails with IE4, people will just get annoyed.

I think I can guess the flow of the past discussion now.  As I now see it,
LIST must be alone.

Jan Mikkelsen

---

From: "D. J. Bernstein" <[email-masked]>
Date: Wed, 20 Oct 1999 12:46:30 -0400

Jan Mikkelsen writes:
> I just did a quick test with IE4 against an EPLF server, and it failed badly

I presume that you're talking about my machine koobera.math.uic.edu,
which is running anonftpd, a secure UNIX FTP server that uses EPLF.

Let me emphasize that the EPLF transition plan is to _first_ add EPLF
support to clients, _then_ switch servers to EPLF.

The question of how well EPLF works with clients _now_ is a red herring.
The transition plan does not ask servers to use EPLF _now_. It asks
servers to switch at a time when switching _will_ work well.

Of course, some system administrators may decide to switch to EPLF
sooner. My machine, as an extreme example, is a web server that merely
happens to be built on top of FTP. The vast majority of clients are
using Netscape to read HTML pages. In this fortunate situation---which I
don't claim is common---I can already use EPLF.

On occasion I hear a report from an Internet Explorer user having
trouble accessing my server. Different versions of Internet Explorer
violate RFC 959 in at least two ways that destroy interoperability:

   * Some versions of Internet Explorer treat 230 as a failure response
     to USER, even though RFC 959 specifically allows this response on
     page 50 and shows it as a successful login on page 57.

   * Some versions of Internet Explorer barf if they don't understand
     the LIST output, even though RFC 959 explicitly says that the LIST
     format ``may vary widely from system to system.''

I doubt that these are the only problems. Fortunately, the intended
audience of my web pages consists of experienced users---again, I don't
claim that my situation is common---and, frankly, the percentage using
Internet Explorer is even lower than the percentage using Lynx. So I
don't have much motivation to work around Internet Explorer's bugs.

Of course, if someone from Microsoft is interested in actually making
Internet Explorer work with my server, I'll be happy to help.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Wed, 20 Oct 1999 18:07:38 -0400

Date:        Wed, 20 Oct 1999 12:46:30 -0400
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Let me emphasize that the EPLF transition plan is to _first_ add EPLF
  | support to clients, _then_ switch servers to EPLF.

As Alun said, this is a pipe dream.

  |    * Some versions of Internet Explorer barf if they don't understand
  |      the LIST output, even though RFC 959 explicitly says that the LIST
  |      format ``may vary widely from system to system.''

It is truly amazing how different this response is from your responses on
the drums list - there what the real world does (regardless of what the
specs state) is your prime argument.   Here, what the spec says seems
to be paramount, and what the world does is irrelevant.

You are of course quite right - according to 959 (and there is no
contradiction anywhere) LIST output can look like anything you want it
to, so producing EPLF format is 100% legal, and anything that breaks
because of that is broken.   However, from a practical standpoint, the
de facto standard for LIST output that has emerged is unix ls -l format.

That that is a truly dumb format to standardise on is beyond question.
I assume that is what led to EPLF, and it is certainly what led to MLST,
which, of course, owes a lot to EPLF.  But if a format for LIST output
were to be defined, unix ls -l format would be it - that's the only
thing that could be defined without breaking most of the world.

  |  frankly, the percentage using
  | Internet Explorer is even lower than the percentage using Lynx.

Once, that would have been true, it is no longer.   Microsoft's
strategy of bundling the thing (that all the legal issues were, perhaps
still are, all about) has clearly worked.   I don't know about North
America, but here, in the "magazines for PC user" type rags, whenever
they tell people how to do something on the web, they explain it for
IE (and sometimes for netscape as an after thought).   That's because
they know that all new systems have IE installed - even for normal users
of netscape, an IE recipe to a solution is useable, because IE is there.

That it is perfectly legal for you to break clients which assume ls -l
output format for LIST is exactly the same reason that it is perfectly
legal for anyone else to break clients that assume that listings that
start with a + are EPLF - if the latter is a "rogue implementor", so
is the former - both are relying upon the letter of the spec in exactly
the same way.

Like Alun, I am now done with this issue (this time around anyway),
unless you have some suggestions for improving the MLST draft, I
don't plan to respond to any more messages.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: Mon, 25 Oct 1999 18:38:19 -0400

> to be paramount, and what the world does is irrelevant.

My concern is entirely with making things work in the real world.

Accurate documentation of what the real world does is essential. Many
interoperability disasters begin because an implementor relies on a spec
that doesn't accurately describe what other implementations do.

This doesn't mean, however, that everyone is obliged to pander to the
limitations of every other piece of communications software. I don't
blame sites for making files available only through HTTP, for example,
or for requiring Java; presumably it is not in the users' interests to
incur the costs of support for other clients. Similarly, in the case of
my web pages, users almost never try anything other than Netscape.
(Again, I don't claim that this is a common situation.)

---Dan