Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht

[John C Klensin <[e-mail]>]

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

> Alexey Melnikov wrote:
> 
>> Anthony Bryan wrote:
>> 
>>> On Tue, Sep 14, 2010 at 7:19 AM, Alexey Melnikov
>>> <[e-mail]> wrote:
>>> 
>>>> Anthony Bryan 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.
> 
>> Looking at the original BOF request, I am wondering what
>> should happen  to the following:
>> 
>>    draft-hoffman-ftp-uri-04 - The ftp URI Scheme

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
>>    Internationalized Text

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