[ftpext] ftpext2-typeu-02

[Frank Ellermann <[e-mail]>]

Hi, I've read the "hash" and "typeu" drafts.  The former only looking for
any new MD5 examples for a test suite; no luck, no problem.  Some of the
links did not work for me, but maybe that was in a section to be removed.

For the "typeu" draft I hope that section 1.3 will NOT be removed.  If it
could be a distraction for implementors maybe move this to an appendix,
but please keep it, same idea as for the appendices in RFC 5198.

I'm surprised that TYPE became "less used" by the late 1980s, because all
troubles I ever had with FTP were caused by a missing "binary" or similar
command, when the default TYPE A turned out to be unsuited for binaries,
and from my POV unnecessary for text files -- my favourite text editor is
an XEDIT-clone and can handle any input line end or tab style.  Of course
I recall only miserable "missing TYPE I" failures, and not any cases were
it worked automatically (as mentioned in section 1.3).

In section 2.1 TYPE L was news for me:  So the "typecode" in FTP URIs
does not only add a somewhat obscure D, it also removes an obscure L.
RFC 959 says it stands for "LOCAL TYPE", and the draft says "logical",
is that as it should be?

The next surprise was that my recipe "always use binary" could fail for
servers, which MAY reject any TYPE excluding A.  Checking RFC 959 that's
the case, but RFC 959 also "recommends" (lower case in old RFC) to offer
TYPE I in 3.1.1.3.  It would be clearer if the draft translates this to
the current style of "mustard" (SHOULD or RECOMMENDED).

There is no logical difference between "MAY reject" and "SHOULD support,
and MAY reject", but for readers the latter is hopefully clearer -- and
I think the "recommended" in RFC 959 would back it.

The next interesting point for me was the RFC 5198 profile in section 3,
I didn't know (back when RFC 5198 was a draft) that there would be any
"profiles", I considered it as the final word of the IETF wrt UTF-8 in
Internet protocols.  Now it turns out to be not as simple as I thought.

And I'm not sure that I understand it correctly:  Some characters are
discouraged in RFC 5198, but now permitted for FTP in the draft.  That
(mostly) affects most control codes in RFC 5198 section 2 clause 3, and
"SHOULD be avoided" matches "discouraged".  The exception for SPace was
fixed in an erratum, leaving CR or LF or FF as exceptions in RFC 5198.

Appendix B explains the discouraged BEL, BS, HT, VT, and FF (again).
The "bare LF" barely escapes the "SHOULD be avoided" in RFC 5198, and
I guess that 0x00..0x0C + 0x0E..0x1F + 0x7F are now on the "permitted"
side wrt the "typeu" draft.  If I got this wrong it might be only me,
or an issue in section 3 of the draft.

Apparently 0x0D (CR) is still only permitted in CRLF and still MUST NOT
occur outside of CRLF or CR+NUL, because the draft does not say that it
overrules a "MUST NOT" in RFC 5198.

That leaves 0x80..0x9F, first listed as "SHOULD be avoided" like other
control codes in RFC 5198.  Two statements later and still in section 2
clause 3 0x80..0x9F are caught by a "MUST NOT appear".  That's not only
discouraged, that's verboten:  Does the "typeu" draft stick to RFC 5198
wrt C1 controls, or are they now permitted?

I'm not sure if it helps, but IIRC C1 conrols have 7bit representations
ESC+d2c(c2d(x)-128+64), e.g., CSI (0x9B) can be given as ESC+'[' (0x5B)
in some 7bit encodings -- but that's of course ancient ISO 2022 history
and not the topic of "typeu".  Maybe permit C1 controls explicitly in
the draft, if there is no good reason to treat NEL and CSI completely
different from BEL and ESC.

RFC 5198 discusses the telnet IAC character.  The only case where I met
this beast is in FTP, getting rid of an (erroneous) file or directory
with 0xFF in its name required to send 0xFF twice.  I had to hardcode
this oddity in <http://purl.net/xyzzy/src/ftpsynch.rex> (and the very
similar classic REXX ftpsynch.cmd), but can't tell when I last needed
this -- years ago, both REXX FTP scripts would never create such names.

If that is as it should be (= not only bad luck with an odd FTP server)
please mention it somewhere in the draft.  RFC 1123 lists it in section
3.2.6 (with a reference to RFC 854 page 13), and maybe RFC 1123 should
belong to the normative references in the draft.

-Frank