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

[Frank Ellermann <[e-mail]>]

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:[e-mail]>?

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
>> ftp://user@host/etc are different from ftp://user:@host/etc

> 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