Ftp-WG: x 0 A D FF nul lf cr iac summary available where

[[[Hi, lately I've returned to read draft-ietf-ftpext-mlst-16.txt, as 
part of my effort to make my 2002-01 ftp work more accessible via 
google of http://members.aol.com/java/ftp/ ]]]

I wonder if by now we have a consensus interpretation of how to cope 
with the chars x 0 A D FF = NUL LF CR IAC?  And is that interpretation 
precisely as follows?

Two parts:

1) Thru an FTP _data_ connection, for example in LIST/ NLST/ MLSD 
results,

1.a) We shall not pass the two byte sequence x 0D 0A CR LF except to 
mean end-of-line.

1.b) We _should_ not pass the bytes x0D CR and x0A LF except as part of 
the two byte sequence x 0D 0A CR LF meaning end-of-line.
1.c) We _should_ avoid the char x0 NUL.
1.d) We _should_ avoid the byte xFF, for example by UTF-8 encoding the 
char xFF.

2) Thru an FTP _control_ connection, up to the x 0D 0A CR LF bytes that 
end each line:

2.a) We shall pass the byte x00 to mean the char x0 NUL.
2.b) We shall pass the byte x0A to mean the char xA LF.
2.c) We shall pass the bytes x 0D 00 to mean the char xD CR.
2.d) We shall pass the bytes x FF FF to mean the char xFF IAC.

I arrive at this interpretation, be it truth or slander, by grokking my 
whole ftp bibliography, most recently seeing confirming evidence in 
such specifications as the following.  By now I've forgotten all ftp 
jargon and most ftp code, mostly I remember only that this the 
interpretation I believed in 2002-01.

Reviewing now, I find the English of mlst-16 vague on issue (1.b).  As 
quoted below, the first paragraph possibly outlaws only CR LF, whereas 
the third paragraph possibly outlaws CR, LF, and CR LF, yet we see no 
comment on LF CR.

Confusedly yours from if-then-else-if-then-else land, Pat LaVarre

--- draft-ietf-ftpext-mlst-16.txt

September 2002 ...
Expires March 2003 ...

...
Note: for pathnames transferred over a data connection, there is no way 
to represent a pathname containing the characters CR and LF in 
sequence, and distinguish that from the end of line indication. Hence, 
pathnames containing the CRLF pair of characters cannot be transmitted 
over a data connection.  Data connections only contain file names 
transmitted from server-FTP to user-FTP as the result of one of the 
directory listing commands.  Files with names containing the CRLF 
sequence must either have that sequence converted to some other form, 
such that the other form can be recognised and be correctly converted 
back to CRLF, or be omitted from the listing.

Implementations should also beware that the control connection uses 
Telnet NVT conventions [8], and that the Telnet IAC character, if part 
of a pathname sent over the control connection, MUST be correctly 
escaped as defined by the Telnet protocol.

NVT also distinguishes between CR, LF, and the end of line CRLF, and so 
would permit pathnames containing the pair of characters CR and LF to 
be correctly transmitted.  However, because such a sequence cannot be 
transmitted over a data connection (as part of the result of a LIST, 
NLST, or MLSD command) such pathnames are best avoided.
...

---