Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16)

From: Marc Huber <[email-masked]>
Date: Wed, 17 Jul 2002 22:12:16 -0500

On Wed, Jul 17, 2002 at 05:25:21AM -0500, Robert Elz wrote:
> Does anyone really believe that we need to say something about NVT
> processing in section 7?

For MLST, <CR><LF> within a file name is transmitted as
<CR><NUL><LF>. However, that only covers the control
connection. For the data connection, no such escape
mechanism exists, and transmitting a file name containing
the <CR><LF> sequence as-is in response to MLSD is
guaranteed to cause trouble.

Marc

===================END FORWARDED MESSAGE===================

Paul Hethmon
[email-masked]
http://www.hethmon.com

---

From: Robert Elz <[email-masked]>
Date: Wed, 17 Jul 2002 22:54:03 -0500

Date:        Wed, 17 Jul 2002 22:12:16 -0500
    From:        Marc Huber <[email-masked]>
    Message-ID:  <[email-masked]>

  | For the data connection, no such escape
  | mechanism exists, and transmitting a file name containing
  | the <CR><LF> sequence as-is in response to MLSD is
  | guaranteed to cause trouble.

This is a different issue entirely, but it is a good point.
Is this a problem that we need to solve?   If not, then we
should probably at least make mention of it somewhere.

kre

---

From: Marc Huber <[email-masked]>
Date: Sun, 21 Jul 2002 03:33:21 -0500

> should probably at least make mention of it somewhere.

It should be addressed, but I'm not sure about the best
solution. Non-shortest UTF-8 is supposed to be illegal, so
it might be advisable to adopt parts of the NVT processing
for the MLSD data connection: transmit <NUL> after <CR>
unless that <CR> starts the regular EOL sequence.

Marc

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Sun, 21 Jul 2002 20:23:02 -0500

----- Original Message -----
From: "Marc Huber" <[email-masked]>
To: "FTPEXT Working Group" <[email-masked]>
Sent: Sunday, July 21, 2002 4:33 AM
Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16)

> unless that <CR> starts the regular EOL sequence.

The parts of NVT processing you're refering to indicate that <CR> <NUL> is
the Telnet End-of-Line.

---

From: Robert Elz <[email-masked]>
Date: Mon, 22 Jul 2002 05:04:21 -0500

Date:        Sun, 21 Jul 2002 03:33:21 -0500
    From:        Marc Huber <[email-masked]>
    Message-ID:  <[email-masked]>

  | It should be addressed, but I'm not sure about the best solution.

Nor I am.

  | Non-shortest UTF-8 is supposed to be illegal,

Yes, though I'm not sure of the relevance here.

  | so it might be advisable to adopt parts of the NVT processing
  | for the MLSD data connection: transmit <NUL> after <CR>
  | unless that <CR> starts the regular EOL sequence.

That's certainly an option, but it would be a big change to make at
this stage of the protocol's design.   It would also mean a big change
to implementations, which, at least as far as I know, don't currently
support anything like this, and while implementations supporting new stuff
isn't exactly a major problem (all of MLSx is new after all...) this
one would be kind of a dramatic change.

An option would be to simply say that names that contain the EOL sequence
can't be handled by the protocol at all.

There is already no way to send them in NLST or LIST, and while it would
be nice for MLSx to be able to cope (and because the control connection is
used, MLST can) it isn't as if we'd be giving up all that much by
simply saying that those filenames can't be transmitted via MLSD.

Opinions?

kre

ps: it would be nice to get a resolution on this one real soon now, we're
in a window where there's actually a possibility of getting this doc
finished and out the door within a measurable time frame - I'd hate it
to fall back into the "Oh, that one" state that it has been in for the
past year or so.

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Mon, 22 Jul 2002 06:34:12 -0500

> can't be handled by the protocol at all.

To be correct, the FTP cannot handle any name containing ( %x00-1F /
%x7F-FF ).

The use of UTF-8 encoding for non-ASCII characters is MARGINALLY workable;
the chances of failure are low enough that there seems little reason to
worry about it as an implementor, but from a protocol level the current
specifications are insufficient to ensure it will work without error.

---

From: Robert Elz <[email-masked]>
Date: Mon, 22 Jul 2002 07:53:44 -0500

Date:        Mon, 22 Jul 2002 06:34:12 -0500
    From:        "Gregory A Lundberg" <[email-masked]>
    Message-ID:  <[email-masked]>

  | To be correct, the FTP cannot handle any name containing ( %x00-1F /
  | %x7F-FF ).

I can assure you that it can, I have done it.   What's more, a whole
legion of hackers, or warez types, or whatever, rely upon the ability
to stick %x08 in file names via ftp... (well, "rely upon" maybe too strong,
"like to use" might be better).

  | The use of UTF-8 encoding for non-ASCII characters is MARGINALLY workable;
  | the chances of failure are low enough that there seems little reason to
  | worry about it as an implementor, but from a protocol level the current
  | specifications are insufficient to ensure it will work without error.

If there's something that needs to be fixed in the specs to make them
clear (aside from that which is already clear - like for FTP the control
channel, and ascii mode data connection, end of line is CR LF and nothing
else at all, regardless of what might be legal sometimes in telnet),
then please let us know.   Especially in the very near term as they apply
to MLSx.

kre

---

From: Marc Huber <[email-masked]>
Date: Mon, 22 Jul 2002 11:53:22 -0500

> simply saying that those filenames can't be transmitted via MLSD.

Agreed. If it turns out to be a problem, we could possibly
come up with something similar to

    C: FEAT
    S: 221-Extensions supported:
       ...
        ENCODING ASCII*;BASE64;URL;
       ...
    S: 221 End.

    C: OPTS ENCODING URL
    S: 200 File names will now be URL encoded.

Marc