Subject: [Uri-review] FWD: New Version Notification for draft-yevstifeyev-ftp-uri-scheme-03.txt

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 28 Jun 2011 06:42:05 +0300

Hello,

> A new version of I-D, draft-yevstifeyev-ftp-uri-scheme-03.txt has been successfully submitted by Mykyta Yevstifeyev and posted to the IETF repository.
>
> Filename:	 draft-yevstifeyev-ftp-uri-scheme
> Revision:	 03
> Title:		 The&#39;ftp&#39; URI Scheme
> Creation date:	 2011-06-28
> WG ID:		 Individual Submission
> Number of pages: 20
>
> Abstract:
>     This document specifies the&#39;ftp&#39; Uniform Resource Identifier (URI)
>     scheme, which is used to refer to resources accessible via File
>     Transfer Protocol (FTP).  It updates RFC 959 and RFC 1738.

Any comments are still welcome.

Mykyta Yevstifeyev

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 28 Jun 2011 22:50:22 +0200 (CEST)

On Tue, 28 Jun 2011, Mykyta Yevstifeyev wrote:

>> A new version of I-D, draft-yevstifeyev-ftp-uri-scheme-03.txt has been 
>> successfully submitted by Mykyta Yevstifeyev and posted to the IETF 
>> repository.

I'm afraid this draft is drifting even further into a territory where it 
dictates how to do FTP in a way I don't think it can or should.

Some random remarks on the -03 version:

Section 2.2

Introduced a typo on line 2, "a file a directory" should be "a file or a 
directory".

Section 2.2.3

I object to (1b) as it is present and then mentioned to be NOT RECOMMENDED and 
then it is claimed to be there due to "compatibility with some FTP clients" 
but the only times I've had to use that method it has been to overcome 
problems caused by FTP servers (or server installations at least). Its 
existance in the spec is utterly confusing to me.

(3) seems to mandate PORT or PASV to be used. This is not how many clients of 
today work - they prefer EPSV or EPRT and a lot of them also use STAT instead 
of opening a second connection. I strongly oppose to the the URI spec to 
dictate this.

Similarly, I object to (4a) and (4b) claiming that NLST should be used to list 
directories. That's entirely up to the client on how it thinks is best to get 
the contents of a directory.

-- 

  / daniel.haxx.se

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 29 Jun 2011 08:00:34 +0300

28.06.2011 23:50, Daniel Stenberg wrote:
>>> A new version of I-D, draft-yevstifeyev-ftp-uri-scheme-03.txt has 
>>> been successfully submitted by Mykyta Yevstifeyev and posted to the 
>>> IETF repository.
>
> I'm afraid this draft is drifting even further into a territory where 
> it dictates how to do FTP in a way I don't think it can or should.
>
> Introduced a typo on line 2, "a file a directory" should be "a file or 
> a directory".
Agreed here.  I'll correct.
>
> Section 2.2.3
>
> I object to (1b) as it is present and then mentioned to be NOT 
> RECOMMENDED and then it is claimed to be there due to "compatibility 
> with some FTP clients" but the only times I've had to use that method 
> it has been to overcome problems caused by FTP servers (or server 
> installations at least). Its existance in the spec is utterly 
> confusing to me.
With regard to this, I think this isn't a problem, so I'll remove this step.
>
> (3) seems to mandate PORT or PASV to be used. This is not how many 
> clients of today work - they prefer EPSV or EPRT and a lot of them 
> also use STAT instead of opening a second connection. I strongly 
> oppose to the the URI spec to dictate this.
I agree here as well - so it will be "arrange data connection using an 
appropriate method (eg. PORT, PASV [RFC0959], EPRT or EPSV [RFC2428] 
command; using historical LPRT and LPSV [RFC1639] for this purpose is 
strongly discouraged);"
>
> Similarly, I object to (4a) and (4b) claiming that NLST should be used 
> to list directories. That's entirely up to the client on how it thinks 
> is best to get the contents of a directory.
With this respect NLST was borrowed from RFC 1738.  So I'll change so 
that (4a) and (4b) will not mention NLST but rather "an appropriate 
method, like LIST, NLST [RFC0959] or MLST [RFC3659] command"

Thanks for your feedback.
Mykyta Yevstifeyev