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