Re: [apps-discuss] FWD: I-D Action: draft-yevstifeyev-ftp-uri-scheme-05.txt

[Frank Ellermann <[e-mail]>]

On 31 July 2011 06:39, Mykyta Yevstifeyev wrote:

> http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme

At some point in time the IETF servers should offer these URLs
on the IETF tools servers, a nice diff with only two clicks is
just too good to ignore it.

Some editorial nits because you are anyway working on version
06.  Please add articles, e.g., s/FTP spec/the FTP spec/, and
s/- pre-Standard Track RFC/- a pre-Standard Track RFC/ (intro).

s/retain on Standard Track/retain it on standards track/ and
s/if RFC 1738 is moved/when RFC 1738 will be moved/ ("ibidem",
as flagged by John Cowan :-)  My "DEnglish" is very suspicious,
therefore I won't list more, and because John Klensin prefers
to fix editorial nits in AUTH48 (or at least not on a mailing
list).

IMHO you can skip RFC 3305 in the FTP URI history, it is not
more relevant after STD 66 was published.  You could also get
rid of the RFC 5538 zoo with all its brothers and sisters in
the intro, or limit it to the first standards track RFC 4248
by Paul Hoffman in this series.

In "Bruce Lily style" only the used BCP 14 keywords are noted
in what you have as section 2.1, that's of course a matter of
taste, keep it "as is" if you like it.  However, OPTIONAL in
ABNF is not something you have to talk about, because ABNF as
in STD 68 has syntactical means to indicate optional elements,
e.g., ABNF [<foo>] vs. ABNF <foo>.

The discussion of ASCII in RFC 0959 is rather complex, saying
that it is in essence RFC 0020 could be misleading.  Don't get
into protocol details for an URI scheme, let RFC 0959 and its
successor(s) handle the protocol.

There is no such thing as a "<host-port> part" in RFC 3986,
please use STD 66 terminology where possible, proposal:

D ftp-hier-part = "//" [ user-pass "@" ] host-port [ ftp-path ]
I ftp-hier-part = "//" authority [ ftp-path ]
I authority     = [ userinfo "@" ] host [ ":" port ]
I userinfo      = user [ ":" pass ]
D user-pass     = user [ ":" pass ]
D user          = 1*usp-char
D pass          = *usp-char
D usp-char      = unreserved / pct-encoded / sub-delims
I user          = *( unreserved / pct-encoded / sub-delims )
I pass          = *( unreserved / pct-encoded / sub-delims / ":")
D host-port     = host [ ":" port ]
I host          = <host as in RFC 3986>
I port          = <port as in RFC 3986>

D = delete
I = insert
Rationale:  Your ABNF requires a non-empty <user>, I can't say if
that is as it should be for STD 9 (FTP), but for STD 66 it is not
required.  Add 1 to <user> if you really want it, and explain all
differences from RFC 3986 somewhere in the prose.

Your ABNF forbids a colon in the <pass>, and that can't be a good
idea without an explanation.  Is an empty <pass> allowed?  At the
moment your ABNF does allow this, and I'd assume that FTP URIs
ftp://user@host/etc are different from ftp://user:@host/etc

Talking about "randomly generated" or "non-existing" addresses is
guaranteed to infuriate the anti-spam community starting with me,
the "non-existence" MUST be certain, e.g., suggest TLD .invalid
for this purpose (.localhost or equivalent domain literals are no
good idea).

Typecode "u" means "Net-Unicode" (in essence UTF-8 with details
explained in RFC 5198), not generally "Unicode" (which could be
UTF-7, BOCU-1, my UTF-4, or worse).

The typecode "d" business could need more details, e.g., why is
ftp://foo/bar/ for directories vs. ftp://foo/bar for files not
good enough, is "d" perhaps never really needed?

Please strike the paragraph "Since a number of clients" in the
new fragment section, all details how clients might ignore any
fragments in URIs have nothing to do with the FTP URI scheme.

IMO URIs must not contain any non-ASCII in <host>, that would
be IRIs.  A <host> is specified in 3986, an <ihost> in 3987 or
its successor.  If we can agree on that it's not necessary to
talk about it for FTP URIs, because they follow the same rules
for <host> and <ihost> like all other URIs and IRIs.

There is an <iauthority> in RFC 3987, and your theory that the
<userinfo> cannot be internationalized appears to be wrong, or
is that something specified in 959bis?

Simply don't talk about it, let RFC 3987 handle any <iuserinfo>,
and let 959bis tackle the consequences.

-Frank