[ftpext] RFC 959Re: Followup on FTPEXT2 BOF in Maastricht
John C Klensin <john-ietf@jck.com> Fri, 29 October 2010 19:52 UTC
Return-Path: <john-ietf@jck.com>
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 3D0CF3A682A for <ftpext@core3.amsl.com>; Fri, 29 Oct 2010 12:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.45
X-Spam-Level:
X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, 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 tSaoogYQ30qC for <ftpext@core3.amsl.com>; Fri, 29 Oct 2010 12:52:32 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id E2D733A6A74 for <ftpext@ietf.org>; Fri, 29 Oct 2010 12:52:31 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PBv1p-000KyW-Cz; Fri, 29 Oct 2010 15:54:21 -0400
Date: Fri, 29 Oct 2010 15:54:20 -0400
From: John C Klensin <john-ietf@jck.com>
To: Alfred H?nes <ah@TR-Sys.de>, ftpext@ietf.org
Message-ID: <C56AF6DA66D1C2B0530A1972@PST.JCK.COM>
In-Reply-To: <201010291746.TAA10758@TR-Sys.de>
References: <201010291746.TAA10758@TR-Sys.de>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: alexey.melnikov@isode.com, stpeter@stpeter.im
Subject: [ftpext] RFC 959Re: 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 19:52:33 -0000
--On Friday, October 29, 2010 19:46 +0200 "Alfred H?nes" <ah@TR-Sys.de> wrote: >... > Questions: > +++++++++ > > A) John: Does this idea match what you had in mind ? No, but mostly because I'm trying to remain agnostic. Historically, the reason why the navigation facilities of RFC 959 are so primitive is because, at the time FTP was developed, we had a wide variety of file system organizations and no general model was possible. With RFC 3659 and TVFS, the community recognized that virtually all contemporary file systems use a hierarchical model that, when abstracted from issues of syntax, actual file storage forms, and encoding of content types into file names, all turn out to be pretty much the same. If we expect that to remain the case, or decide that FTP should make that case easy and any other cases hard, then your idea, plus or minus details, makes a lot of sense. However, consider the following strawman fantasy: say that various "semantic connections among data" take off and that some were to actually develop a file system and data model that is semantic-relational rather than hierarchical or multihierarchical. At that point, TVFS becomes as irrelevant as some of the historical data storage models are to the hierarchical one. > 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? Note that these issues might be an additional argument for "streamlined" or combination commands such as those for which there is at least one proposal in the hopper. I'd rather see aggressive, asynchronous-command pipelining (which is part of what we had in mind in the early 70s when the two-stream model was defined) but it may be too late for that. > (3) Does the general approach of encoding server capabilities > in 'ftp' URIs make sense? I rather doubt it, but that is a much more complicated question. >... john p.s. This list is not on the non-WG mailing lists page. Unless we anticipate a charter approval _really_ quickly, that should probably be fixed.
- [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