Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht
Alfred Hönes <ah@TR-Sys.de> Fri, 29 October 2010 17:45 UTC
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: ftpext@core3.amsl.com
Delivered-To: ftpext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226313A677C for <ftpext@core3.amsl.com>; Fri, 29 Oct 2010 10:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.322
X-Spam-Level:
X-Spam-Status: No, score=-98.322 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S5hLwAYuqlg for <ftpext@core3.amsl.com>; Fri, 29 Oct 2010 10:45:05 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 239153A67FC for <ftpext@ietf.org>; Fri, 29 Oct 2010 10:44:59 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA122844392; Fri, 29 Oct 2010 19:46:32 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA10758; Fri, 29 Oct 2010 19:46:30 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201010291746.TAA10758@TR-Sys.de>
To: klensin@jck.com, ftpext@ietf.org
Date: Fri, 29 Oct 2010 19:46:30 +0200
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Cc: alexey.melnikov@isode.com, stpeter@stpeter.im
Subject: Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2010 17:45:07 -0000
John, thanks for your additional considerations. You wrote, in response to Alexey's appeal: >>> [Alexey] >>> In particular, I would like this WG to revise the FTP URI spec, >>> but I understand that there might be no interest in doing that. > > [John] > I'm less concerned about interest than I am about the right mix > of skills. I note that draft-hoffman-ftp-uri-04 expired over > five years ago and that there has been a lot of thinking about > URIs since. I wonder if that draft would even still be a good > foundation (I just glanced at it but haven't looked carefully at > it in a couple of years). My recollection is that it carries > forward the URI definition from RFC 1738 and therefore has no That's what has Paul confirmed. That draft essentially only was an excerpt from the old RFCs and there was a lack of energy and resources, and of interest from the community, in doing improvements. > provisions for extensions (commands or functions not found in > RFC 959) at all. It also appears to have assumed that FTP was > going to be static: not only is that unlikely to be true in a > world in which we have an extension mechanism and are using it > but overloading NLST (or other commands) on TYPE could turn out > to be a really bad plan. > > My instinct is that it might be reasonable to put "new/updated > FTP URI scheme" somewhere in the WG's queue, but that, while > such an effort should consider the RFC 1738 / > draft-hoffman-ftp-uri approach, it may well want to start over > and design something appropriate for "modern" FTP, even if that > requires a different scheme keyword. My existing pre-draft already _is_ different from draft-hoffman-ftp-uri-04, but it is still imcomplete and not yet ready to be submitted. I indeed plan to do that ASAP, most likely shortly after the IETF. One of the points where I got stuck when this work started out also was related to the perceived mismatch between the very conservative approach of the old 'ftp' URI scheme and the capabilities of more modern FTP servers that you describe. In particular, one raw idea I had started off during working on the text to describe the tedious step-by-step navigation procedures prescribed in the old spec for a "consumer" of an 'ftp' URI (see Section 3.2.2, "FTP url-path", of RFC 1738). This procedure was based on the lack of an accepted model for the (abstract or concrete) hierarchical naming system (supported by URIs in general, but not expected by FTP servers at the time of RFC 959). Since those days, the old FTPEXT WG has produced a specification of the TVFS, published in RFC 3659. My idea then was: If an 'ftp' URI could carry an indication that the server specified in the <authority> part if the URI supports the TVFS model (it will announce TVFS capability if asked), and therefore that URI follows TVFS semantics, an application interpreting such URIs could save a lot of round trips and gain performance (on both sides of the control connection and on the network) by directly changing directory in a single step over multiple hierarchical levels. The proper way I envision to encode this extra information is via a URI parameter, say ";tvfs". This would maintain backwards compatibility (a client that doesn't understand and support the parameter would ignore it -- following the robustness principle -- and behave as inefficiently as it did before, and the original creator/publisher of an 'ftp' URI is expected to know the capabilities of her server(s) and therefore would only add this parameter if the related expected "new" client behavior would be supported by the server(s). Similar extensions could be conceived for other server capabilities (yet to be determined) for which it would make sense to make prospective URI consumers aware of beforehands, without having to negotiate with the server. Questions: +++++++++ A) John: Does this idea match what you had in mind ? B) to the list: (1) What do you think about this idea ? In detail: (2) Is there actually a problem in practice, i.e. are there opportunities and needs, e.g. for optimization, that actually need to be addressed? (3) Does the general approach of encoding server capabilities in 'ftp' URIs make sense? (4) Would there be good chance this would be supported by (client) implementations and 'ftp' URI creators ? (5) Does the encoding in a URI parameter make sense to you? (6) Is the above idea worth being specified in the inital new ftp-uri draft ? Feedback welcome! Kind regards, Alfred Hönes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ Appendix -- for more context: ++++++++ The introduction of my current pre-draft currently says: <snip> 1. Introduction Uniform Resource Identifiers (URIs) were initially described for the IETF in RFC 1630 [RFC1630], and later on more precisely specified, first in RFC 1738 [RFC1738] and RFC 1808 [RFC1808], then by RFC 2396 [RFC2396], which eventually was obsoleted by STD 66, RFC 3986 [RFC3986]. The earlier documents also specified how to define schemes for URIs; the applicable rules and procedures for URI schemes are now prescribed by BCP 35, RFC 4395 [RFC4395]. The first definition for many 'classical' URI schemes also appeared in RFC 1630 [RFC1630]; the first standard specifications for these were contained in RFC 1738 [RFC1738], and RFC 1808 [RFC1808] has elaborated on "relative URLs" (now more precisely called "relative URI references" in STD 66). These documents were made obsolete without creating replacement documents for all parts of their URI scheme specific content. Thereby, some basic URI schemes that are in widespread use have been orphaned, leaving the IANA Registry of URI schemes without a valid reference to a normative definition document. Most of these gaps already have been closed (by RFCs 4156, 4157, 4248, 4266, and 5538). This document recollects and updates the definition of the 'ftp' URI scheme from the older RFCs to allow that material to remain on the Standards Track and bring it in alignment with current IETF STD and BCP documents. Note that the 'file' and 'ftp' URIs are not the same, even when the target of the 'ftp' URI is the local host. Specification of the 'file' URI scheme is out of scope for this draft. </snip> And this is what I have in the central syntax and semantics part, *without* any mention of the aforementioned extension: <snip> 2.4. FTP url-path The <url-path> of an FTP URI has the following form: <cwd1>/<cwd2>/.../<cwdN>/<name>[;type=<typecode>] <cwd1> through <cwdN> and <name> are (possibly encoded) strings and <typecode> is one of the characters "a", "i", or "d". The <cwdx> and <name> parts may be empty. The part ";type=<typecode>" may be omitted. In fact, the whole url-path, including the leading "/", may be omitted. The <url-path> is interpreted as a series of FTP commands as follows: o Each of the <cwd> elements is to be supplied, sequentially, as the argument to a CWD (change working directory) command. o If the typecode is "d", perform a NLST (name list) command with <name> as the argument, and interpret the results as a file directory listing. o Otherwise, perform a TYPE command with <typecode> as the argument, and then access the file whose name is <name> (for example, using the RETR command.) Within a <name> or <cwdx> component, the characters "/" and ";" are reserved and must be encoded. The components are decoded prior to their use in the FTP protocol. In particular, if the appropriate FTP sequence to access a particular file requires supplying a string containing a "/" as an argument to a CWD or RETR command, it is necessary to encode each "/". Historical note: Most FTP client implementations precede the <cwd1> with a "/" before sending the CWD command. This is in conflict with RFC 1738, although the practice is quite widespread. Thus, a client that is presented with the URI ftp://myname@example.com/abc/def might send the two commands "CWD /abc" and "RETR def" or it might send the two commands "CWD abc" and "RETR def". Server implementers should be aware of these two different interpretations of the same URI. FTP URIs may also be used for other operations; for example, it is possible to update a file on a remote file server, or infer information about it from the directory listings or FTP extension commands. The mechanism for doing so is not spelled out here. 2.5. FTP Typecode is Optional The entire ;type=<typecode> part of a FTP URI is optional and is rarely used. Historically, the typecode option was rarely implemented and, in practice, dereferencing is done by guessing. If the typecode is omitted, the client program interpreting the URI must guess the appropriate mode to use. In general, the data content type of a file can only be guessed from the name, such as from the suffix of the name; the appropriate type code to be used for the transfer of the file can then be deduced from the data content of the file. </snip> Additional question to the list: I have been told that in practice RFC 1738 behavior described above is not followed and RFC 1630 behavior is implemented: In current practice, a trailing "/" in the <url-path> (i.e. an empty <name> is regarded as equivalent to (and a substitute for) ";type=d". Is that correct ?
- [ftpext] Followup on FTPEXT2 BOF in Maastricht Alexey Melnikov
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Anthony Bryan
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Alexey Melnikov
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Anthony Bryan
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Alexey Melnikov
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Anthony Bryan
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht liu dapeng
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Anthony Bryan
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht liu dapeng
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Alexey Melnikov
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Anthony Bryan
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Alexey Melnikov
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Alfred Hönes
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Alexey Melnikov
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht John C Klensin
- Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht Alfred Hönes
- [ftpext] RFC 959Re: Followup on FTPEXT2 BOF in Ma… John C Klensin
- Re: [ftpext] RFC 959Re: Followup on FTPEXT2 BOF i… Anthony Bryan