Subject: Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht

From: Alexey Melnikov <[email-masked]>
Date: Tue, 19 Oct 2010 08:06:25 +0100

Anthony Bryan wrote:

>On Tue, Sep 14, 2010 at 7:19 AM, Alexey Melnikov
><[email-masked]> wrote:
>  
>
>>Anthony Bryan wrote:
>>    
>>
>>>On Sun, Sep 12, 2010 at 11:30 PM, liu dapeng <[email-masked]> wrote:
>>>      
>>>
>>>>Hi Anthony,
>>>>
>>>>For the draft: draft-ietf-behave-ftp64, during last IETF meeting,
>>>>people are agreed to split the draft to two separate ones, ALG related
>>>>wrok goes to Behave WG, FTP protocol related work goes to FTPEXT.
>>>>Shall we include this work item to the charter?
>>>>
>>>>Following text for your refernece:
>>>>Deliverables: FTP extensions to support IPv4/IPv6 transiation scenario.     
>>>>
>>>hi,
>>>
>>>thanks for the info. should I remove draft-ietf-behave-ftp64 from the
>>>list?      
>>>
>>I think listing a draft from another WG is confusing, so I would say yes.
>>
>>But note that it is Ok to have a Charter listing deliverables for which
>>there is no draft.
>>
>thanks, good to know.
>  
>
Hi,
Sorry for slow response, I am just back from holidays.

>should I also add something like "Review other drafts which may touch
>on FTP in some way" (like draft-ietf-tcpm-urgent-data-06), or is that
>pretty much implied?
>
This is implied. The WG will get such requests informally anyway.

>does anyone else have any comments? deliverables/goals?
>
Looking at the original BOF request, I am wondering what should happen 
to the following:

    draft-hoffman-ftp-uri-04 - The ftp URI Scheme
    draft-klensin-ftp-typeu-00 - FTP Extension for Internationalized Text

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.

>FTP Extensions, 2nd edition (ftpext2) Charter
>
>Chair(s):
>     ?
>
>IETF Area:
>     Applications Area
>
>Applications Area Directors:
>     Alexey Melnikov <[email-masked]>
>     Peter Saint-Andre <[email-masked]>
>
>Responsible Area Director:
>     Alexey Melnikov <[email-masked]>
>
>Mailing list:
>     General Discussion: [email-masked]
>     Archive: http://www.ietf.org/mail-archive/web/ftpext/current/maillist.html
>
>Description of Working Group:
>
>The Standard File Transfer Protocol specification in RFC 959
>has been updated several times with command extensions of one
>sort or another, including those based on the extension
>mechanism of RFC 2389 (a complete list appears in RFC 5797 and
>the corresponding IANA registry at
>http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xhtml
>).
>
>The following are active FTP related drafts:
>
>    draft-bryan-ftp-hash
>    draft-hethmon-mcmurray-ftp-hosts
>    draft-peterson-streamlined-ftp-command-extensions
>    draft-preston-ftpext-deflate
>    FTP extensions to support IPv4/IPv6 translation scenario
>
>The Working Group will:
>* Review and finalize drafts listed above.
>* Continue work on other drafts that are already in progress.
>* Review and confirm or reject errata of current FTP RFCs.
>* Investigate the differences between FTP in theory
>  (current RFCs) and practice, and recommend future work to align them.
>
>The Working Group's specification deliverables are:
>* A document that specifies the HOST command (Proposed Standard).
>* A document that specifies the HASH command (Proposed Standard).
>* A document that specifies FTP extensions to support IPv4/IPv6
>translation scenario.
>
>The Working Group must not introduce a new version of FTP, e.g.
>an incompatible FTP 2.0.
>
>Goals and Milestones
>Oct 2010    Submit 'File Transfer Protocol HOST Command for Virtual
>Hosts' as working group item (draft-hethmon-mcmurray-ftp-hosts will be
>used as a starting point)
>Oct 2010    Submit 'File Transfer Protocol HASH Command for
>Cryptographic Hashes' as working group item (draft-bryan-ftp-hash will
>be used as a starting point)
>??? 2010    Working group Last Call of HOST document
>??? 2010    Submit 'File Transfer Protocol HOST Command for Virtual
>Hosts' to the IESG for consideration as a Proposed Standard
>??? 2011    Working group Last Call of HASH document
>??? 2011    Submit 'File Transfer Protocol HASH Command for
>Cryptographic Hashes' to the IESG for consideration as a Proposed
>Standard
>??? 2011    Close or recharter
>  
>
Best Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 24 Oct 2010 09:43:07 +0100

>> <[email-masked]> wrote:
 [...]

>> does anyone else have any comments? deliverables/goals?
I took the liberty of submitting your last version of the charter to 
IESG/IAB for review. I've made some minor adjustments to milestone dates.

If people can agree on the mailing list about the 2 documents I've asked 
about, they can be added to the charter before the WG is approved.

Best Regards,
Alexey

---

From: John C Klensin <[email-masked]>
Date: Mon, 25 Oct 2010 09:44:00 -0400

--On Sunday, October 24, 2010 09:43 +0100 Alexey Melnikov
<[email-masked]> wrote:

> I took the liberty of submitting your last version of the
> charter to IESG/IAB for review. I've made some minor
> adjustments to milestone dates.
> 
> If people can agree on the mailing list about the 2 documents
> I've asked about, they can be added to the charter before the
> WG is approved.
> 
>> Looking at the original BOF request, I am wondering what
>> should happen  to the following:
>> 

While I think this is important, it gets tied up with the entire
URI/ i18n/ IRI situation as well as evolving i18n work on FTP
(e.g., an eventual review of RFC 2640).  I don't know (1)
whether FTPEXT2 is the optimal place to do that work nor (2)
whether this is the right time to do it given that FTP
extensions work could affect the URI definition.
 
>>    draft-klensin-ftp-typeu-00 - FTP Extension for

Well, I think that one is important, but I'm biased by a
combination of too much time in the i18n space and a continued
belief that TYPE A has actually been useful.   I think it will
be particularly important if we continue to see a variety of
CCSs in use in local filesystems (ISO8859-x, BIG5, GBxxxx,
ISO2022-JP, etc.) and/or some local filesystems using Unicode in
UTF-16, others in UTF-8, and perhaps still others in UTF-32.  On
the other hand, if no one sees a reason to implement it, it
should remain on hold until and unless that changes.

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

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

best regards,
   john