Re: [John.Ockerbloom@gs1.sp.cs.cmu.edu: Re: FTP handling suggestion]

Michael A. Dolan (miked@CERF.NET)
Mon, 05 Sep 1994 08:37:24 -0700

Message-Id: <199409051545.IAA11654@nic.cerf.net>
Date: Mon, 05 Sep 1994 08:37:24 -0700
To: Larry Masinter <masinter@parc.xerox.com>
From: miked@CERF.NET (Michael A. Dolan)
Subject: Re: [John.Ockerbloom@gs1.sp.cs.cmu.edu: Re: FTP handling suggestion]

At 09:58 PM 9/3/94 PDT, Larry Masinter wrote:
>Mike, I appreciate your concern, but I think your message was
>inflamatory;

Critical, perhaps. "Inflamatory" implies malicious intent, which there is
none.

>for example, the 'ftp' scheme clearly and explicitly
>allows user name and password to be supplied, yet you call out:
>
>> What if "USER anonymous" doesn't work ? (Some sites require "ftp".)
>> ...

There is, in practice today, the use of "ftp". It might be reasonable to
allow the algorithm to backoff and retry "ftp" should "anonymous" fail.
This is independent of the ability to specify a userid. "ftp" should
be treated as a variation on the "anonymous" login, and not prompt the
user for a password as required when a userid is provided in the URL.

>As for capturing current practice, RFC 1630 attempts to do that.

Hmmm.

>This
>working group was chartered to standardize on a syntax and its
>interpretation that was reasonable, and based on current practice.
>You might not be aware of the long discussions in this working group
>over the exact interpretation of FTP URLs, but I hope you'll give us
>the benefit of the assumption that we are aware of current practice
>(in libwww and in several other URL implementations), and found that
>the FTP URL was ambiguous and implemented differently between the
>various implementations, and required some disambiguation.

At no time was I questioning this group's ability or awareness.
It would be valuable to have more complete specification on existing
practice. If that is not the charter of this group, so be it.

>> The FTP syntax is sound, but the specific issue raised by Mr.
>> Ockerbloom is only the tip of the iceburg on implementation and
>> algorithms.
>
>I don't believe this is true; if you have some actual iceburgs to
>point out, of course, please do so.

With the possible exception of news/nntp, I have no major problem with
the URL syntax and algorithms. But, having implemented URL access for most
protocols in the draft, I can say with some authority that the draft still
needs some more work in the area of algorithm specification. My various
email of 8/7 provided a general overview of what I feel is missing.

>If you have an alternative
>specification that you would like to propose instead,

This, I believe, would be counter-productive.

>or a further
>elaboration of the algorithm than what appears in the current internet
>draft, please send it.

In response to my previous offer to work on the draft, you recently stated,
"I don't think there's a strong sentiment to put much more into it at this
point". Since I don't get paid to review/draft specifications, this
"sentiment" is not much of a motivating factor. However, if the editors
are willing to seriously consider specific changes to the draft, then
I'll take a run at enhancing the algorithms.

Mike
-----------------------------------------------
Michael A. Dolan <mailto:miked@cerf.net>
TerraByte Technology (619) 445-9070, FAX -8864