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

From: Frank Ellermann <[email-masked]>
Date: Thu, 4 Aug 2011 09:20:01 +0200

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 4 Aug 2011 14:01:16 +0200

On 4 August 2011 10:05, Mykyta Yevstifeyev wrote:

 [intro]
> This is copying similar statement from your RFC 5538 :-)

If you like it I won't insist on minimizing this part ;-)

 [terms]
>> 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>.

> That's clear that they are used "to clarify syntactical
> requirements". Mentioning this in the text is for the
> sake of clearance.

Maybe it is only me, but when I see an "explanation" of
OPTIONAL in ABNF I start to wonder what is different from
the BCP or even the STD, and why it is different.  If it
turns out to be not different at all I'm happy again, but
would not say that it is now "clearer" - YMMV, obviously.

 [ASCII]
> I may remove reference to RFC 20; but in context of RFC
> 3986 reference to ANSI standard is necessary.

Sure, the RFC 20 reference is fine, but the statement...

| definition of "ASCII" found in RFC 959 [RFC0959] may be
| considered to be equivalent.

...is misleading, RFC 20 does not cover all those historic
ASCII encodings mentioned in RFC 959.  RFC 5198 Appendix A
and B are a summary for "network ASCII", and that might be
"considered to be equivalent" (to the RFC 959 ASCII ideas).

 [syntax]
> Here I should note that there are some reasons for not
> doing as you propose. First. <authority> doesn't have
> clear syntactical requirement for "user:pass" format; it
> also allows empty userinfo.

Yes, I only suggested to keep the name as in RFC 3886, not
the syntax, you clearly need to split it in user [":" pass]

And I mainly do not want you to replace host [":" port] by
a new "<host-port> part" without a compelling reason.  If
you want "non-empty" for <user> it is okay, you are still
free to use RFC 3986 names in the syntax:

authority = [ userinfo "@" ] host [ ":" port ]
userinfo  = user [ ":" pass ]
user      = 1*( unreserved / pct-encoded / sub-delims )
pass      =  *( unreserved / pct-encoded / sub-delims / ":")

Translations to IRIs are simpler if the stuff matching any
<iwhatever> can be found as <whatever>, here: <iauthority>,
<iuserinfo>, and <ihost>.

> Thus, if <userinfo> is present, it must contain username
> at least.

Okay, reflected above.  And that derivation from RFC 3986
needs no extra prose, I have no idea why RFC 3986 permitted
an empty <userinfo>.  The authors of full internet standards
use water to brew coffee like everybody else.

> The ":" is disallowed on order not to make confusion with
> ":" as delimiter.  In this case what username and password
> in the URI <ftp://foo:baz:[email-masked]>?

When you say it's the first colon it will be the first colon.
When you say it's the one and only colon it would break any
existing RFC 1738 passwords containing a colon.  I don't see
a good reason for the second choice.

>> Is an empty<pass>  allowed?  At the moment your ABNF does
>> allow this, and I'd assume that FTP URIs

> No, in both of them there is no pass; they'll be handled in
> the same way.

If you want <pass> to be non-empty add the missing "1" in your
syntax:  1*usp-char instead of *usp-char  Ditto in my variant:

pass      = 1*( unreserved / pct-encoded / sub-delims / ":")

  [abuse]
>> "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
[...]
> This is solely up to the client to decide.  Everything we can
> do is "SHOULD use randomly-generated or non-existence", which
> I am not planning to remove.

"Randomly generated" addresses are net abuse, because it ends
up as spam in the inbox of some "random address owner" victim,
or causes traffic to the MX of "random domains".  Addresses in
TLD .invalid are guaranteed to be invalid, as the name says.

TLD .example and its IDNA variants would be already less clear.

> I don't see strong reasons to mandate use of .invalid domain
> for this purpose.

If mustard is too strong pick SHOULD.  Above all do not mention
"randomly generated" if all you actually want is "non-existing".

 [typecode "d"]
> This issue is quite fishy from RFC 1738/1630.  Suppose there
> is a directory named "file.txt", and we want it's listing.
> The URI <ftp://host.example/foo/file.txt/> will lead the
> client to RETR file.txt in 95% cases, if not more, overlooking
> step (4a), which says "CWD each segment until there is a slash
> or non-slash-ended segment", and then lamenting that there is
> no such file like file.txt.

Okay, if it helps slightly broken clients to get what they want.

An interesting case is a file system permitting a subdirectory
"file.txt" and a file "file.txt" in the same directory - this is
fortunately not the case in any file system I care about.

 [host vs. ihost]
> I see no reason to disallow UCS chars, even pct-encoded, in
> URIs.  One isn't necessarily obliged to make the 'ftp' URI
> with IDN an 'ftp' IRI.

As far as I'm concerned percent-encoded legacy charsets in any
URI are fine as long as client and host agree on what they are
trying to do, and do not claim that it is an "IRI".

But the <host> is the <host> and should match RFC 3986, because
that is already bad enough with its <regname> construct.  And
an <ihost> is an <ihost> as specified in 3987 and IDNA, we'd
need no specifications on "the road to nowhere".

> what is 959bis; I've never heard of such draft

Nor me, I used it as nickname for the "ftpext2" set of drafts.

-Frank

---

From: John Cowan <[email-masked]>
Date: Mon, 8 Aug 2011 21:13:42 -0400

John C Klensin scripsit:

> It seems to me that there are two logical possibilities for an
> FTP URI:
> 
> (a) Do something absolutely minimal that satisfies a large
> number of cases.  This is probably anonymous login only, stream
> and image transfer only, probably PASV only these days, maybe
> even a restriction to an ASCII command stream.  If an email
> address is needed for login, a provision for picking that up
> from an environment variable rather than having it incorporated
> into the URI, would be important.
> 
> (b) Fully-reflect the protocol and all of its standardized
> options.  This would get fairly complex for a URI because one
> would not only want to supply a lot of information but might
> want to supply it conditionally.

The third possibility is to describe what actually works on the
browsers and other URI-basec clients that are actually in use,
which I believe is what is being done.

> Between those two points, there isn't a lot other than slippery
> slope.

A slippery slope is where people actually live.

-- 
One Word to write them all,             John Cowan <[email-masked]>
  One Access to find them,              http://www.ccil.org/~cowan
One Excel to count them all,
  And thus to Windows bind them.                --Mike Champion

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Aug 2011 14:52:07 -0400

It's been a week and a half since the original message was posted, but
I had to discuss this with the other appsawg chairs, the ftpext2
chairs, and the Applications ADs.

On Sun, Jul 31, 2011 at 12:39 AM, Mykyta Yevstifeyev
<[email-masked]> wrote:
> Sorry for cross-posting to 6 addresses :-); please send all your comments to
> [email-masked].

No, please do not.  This document is NOT to be discussed on apps-discuss.
1. It will not be processed in the appsawg.
2. The ftpext2 chairs have told me that it will not be processed in
ftpext2.  It is not in their charter, and the WG is not interested in
rechartering to add it.
3. The Apps ADs have told me that they will not sponsor it as an
individual submission.

In other words, as an IETF document, this is dead.  There is
insufficient energy and interest in the IETF to hash this document
out.  Please do not continue work on this document.  In any case,
please do not discuss it on the apps-discuss mailing list.

Barry Leiba, appsawg chair

>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>        Title           : The&#39;ftp&#39; URI Scheme
>>        Author(s)       : Mykyta Yevstifeyev
>>        Filename        : draft-yevstifeyev-ftp-uri-scheme-05.txt
>>        Pages           : 29
>>        Date            : 2011-07-24
>>
>>    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.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-05.txt

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 12 Aug 2011 06:36:31 +0300

> please do not discuss it on the apps-discuss mailing list.

Barry,

I'm very unlikely to stop working on the document.  Anyway, nothing in 
your message disallows me to wait for better times, when the situation 
changes.

Mykyta

> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>