FWD: New Version Notification for draft-yevstifeyev-ftp-uri-scheme-03.txt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

FWD: New Version Notification for draft-yevstifeyev-ftp-uri-scheme-03.txt

Mykyta Yevstifeyev
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'ftp' URI Scheme
> Creation date: 2011-06-28
> WG ID: Individual Submission
> Number of pages: 20
>
> Abstract:
>     This document specifies the'ftp' 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

Reply | Threaded
Open this post in threaded view
|

Re: [ftpext] FWD: New Version Notification for draft-yevstifeyev-ftp-uri-scheme-03.txt

Daniel Stenberg
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

Reply | Threaded
Open this post in threaded view
|

Re: [ftpext] FWD: New Version Notification for draft-yevstifeyev-ftp-uri-scheme-03.txt

Mykyta Yevstifeyev
28.06.2011 23:50, Daniel Stenberg wrote:

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