Subject: Ftp-WG: to mlst-16 from mlst-15

From: Pat LaVarre <[email-masked]>
Date: Wed, 2 Oct 2002 15:46:09 -0500

> From: Robert Elz [mailto:[email-masked]] 
> Sent: Mon 9/23/2002 9:52 AM 
> Subject: Ftp-WG: MLST draft 16 finally submitted

= ftp://munnari.oz.au/internet-drafts/
+ draft-ietf-ftpext-mlst-16.txt.gz
- draft-ietf-ftpext-mlst-15.txt.gz

Apart from seeming artifacts of pagination, the
differences I see are:

+ draft-ietf-ftpext-mlst-16.txt   September 2002
+ Elz & Hethmon   [Expires March 2003]
=
- draft-ietf-ftpext-mlst-15.txt   April 2002
- Elz & Hethmon   [Expires October 2002]

= 1. Introduction
=
+ This document updates the File Transfer Protocol
- This document amends the File Transfer Protocol

= 2.2. Pathnames
...
+ 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.
...
+ NVT also distinguishes between CR, LF, and the end
+ 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.

= 3. File Modification Time (MDTM)
...
+ Because the User and server FTPs' clocks are not
+ necessarily synchronised, User FTPs intending to use
+ this method should usually obtain the modification
+ time of the file from the server before the initial
+ RETRieval, and compare that with the modification
+ time before a RESTart.  If they differ, the files
+ may have changed, and RESTart would be inadvisable.
+ Where this is not possible, the User FTP should make
+ sure to allow for possible clock skew when comparing
+ times.

= 6.1. TVFS File Names
...
+ With the sole exception of the "/" character, any
+ valid IS10646 character [11] may be used in a TVFS
+ file name.  When transmitted, file name characters
+ are encoded using the UTF-8 encoding [2].  Note that
+ the two character sequence CR LF occurring in a file
+ name will make that name impossible to transmit over
+ a data connection. Consequently, it should be
+ avoided, or if that is impossible to achieve, it
+ MUST be encoded in some reversible way.
=
- With the sole exception of the "/" character, any
- valid IS10646 character [11] may be used in a TVFS
- file name.  When transmitted, file name characters
- are encoded using the UTF-8 encoding [2].

= 7.7.8. A stress test of case (in)dependence
...
= Next, notice the labels of the facts.  These are
= also case independent strings,
+ Server-FTP is permitted to return them in any
+ case desired.
- Server-FTP is permitted to return them in any
- case they desire.

= 11. Security Considerations
...
+ Server FTP should take care not to reveal sensitive
+ information about files to unauthorised parties.  In
+ particular, some underlying filesystems provide a
+ file identifier which, if known, can allow many of
+ the filesystem protection mechanisms to be
+ by-passed. That identifier would not be a suitable
+ choice to use as the basis of the value of the
+ unique fact.

+12. Normative References
-12. References

= Editors' Addresses

+   Robert Elz
+   Prince of Songkla University
+   Department of Computer Enginering
+   Hat Yai, 90112
+   Thailand
+
+   Email: [email-masked]
=
-   Robert Elz
-   University of Melbourne
-   Department of Computer Science
-   Parkville, Vic   3052
-   Australia
-
-   Email: [email-masked]

P.S. Courtesy Google of this list I remembered:

ftp://munnari.oz.au/internet-drafts/

and so I found:

ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-16.txt.gz
[39075 bytes]

ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-15.txt.gz
[38357 bytes]

ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-14.txt.Z
[50360 bytes]

Sun's `jar -xvf` and Microsoft's Win XP choked over
these .Z and .gz compressions, but Mac OS X just plain worked.

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

---

From: Robert Elz <[email-masked]>
Date: Thu, 3 Oct 2002 02:03:10 -0500

Date:        Wed, 2 Oct 2002 15:46:09 -0500
    From:        Pat LaVarre <[email-masked]>
    Message-ID:  <[email-masked]>

  | Apart from seeming artifacts of pagination, the
  | differences I see are:

Thanks for that...   And yes, I believe those are the changes
(and I think they'd all been mentioned on the list before, at least
in principle).

  | + This document updates the File Transfer Protocol
  | - This document amends the File Transfer Protocol

That one was actually an IESG(AD) directive...

  | = 2.2. Pathnames
  | + Note: for pathnames transferred over a data
  | + connection, there is no way to represent a pathname
  | + containing the characters CR and LF in sequence, [...]

This was discussed at some length on the list.

  | = 3. File Modification Time (MDTM)
  | + Because the User and server FTPs' clocks are not
  | + necessarily synchronised, [...]

This was another IESG (AD?) request.

  | = 6.1. TVFS File Names
  | + [...] Note that
  | + the two character sequence CR LF occurring in a file
  | + name will make that name impossible to transmit over
  | + a data connection. Consequently, it should be
  | + avoided, or if that is impossible to achieve, it
  | + MUST be encoded in some reversible way.

As above.

  | = 7.7.8. A stress test of case (in)dependence
  | + Server-FTP is permitted to return them in any
  | + case desired.
  | - Server-FTP is permitted to return them in any
  | - case they desire.

Grammar...  (hardly a change of substance...)

  | = 11. Security Considerations
  | + Server FTP should take care not to reveal sensitive
  | + information about files to unauthorised parties. [...]

Another IESG (AD) request.

  | +12. Normative References
  | -12. References

A pre-emptive strike (attempt to avoid a later holdup...)   That one
actually wasn't ever mentioned on the list, now I think of it.  If
someone wants to determine that any of the refs aren't normative, be
my guest...

  | = Editors' Addresses

Definitely not a substantive change...

  | P.S. Courtesy Google of this list I remembered:
  | ftp://munnari.oz.au/internet-drafts/

Yes.   I tend to keep ancient copies of anything I find personally
interesting, sometimes old copies of lots...

  | Sun's `jar -xvf` and Microsoft's Win XP choked over
  | these .Z and .gz compressions, but Mac OS X just plain worked.

The .Z is ancient unix "compress" (LZ) compression.   .gz is gzip.

Now munnari has more horsepower, and less work to do than it used to
have, I will probably (eventually) enable decompress on the fly for
these files, so you can just fetch without the ".Z" or ".gz" and you'd
get the TXT version returned.   (I guess I could also make it do that
if someone attempted an ACSII mode file transfer, but that might just
violate the principle of least surprise, even if it would be more useful
than just transferring a useless hunk of mangled data...)

kre

ps: the "IESG (AD)" above is because it isn't always clear which messages
are coming from the IESG as a whole, which from a part of it, or which just
from the AD (not that there's any reason it has to be either).

---

From: Alun Jones <[email-masked]>
Date: Thu, 3 Oct 2002 08:57:14 -0500

>The .Z is ancient unix "compress" (LZ) compression.   .gz is gzip.

Winzip and several other tools handle .Z quite comfortably, ancient though 
it is.  Though I can remember back in the days of DOS that there wasn't 
enough memory to do 16-bit compression :-)

>than just transferring a useless hunk of mangled data...)

It might be more appropriate to simply refuse to transfer such a file in 
ASCII mode.  To be honest, I've half-toyed with the idea of ignoring RFC 
959's requirement that the default transfer method be ASCII - but then 
again, on a Windows system, where the EOL translation is a null one, it's 
not terribly important.

It's about time that the MLST draft made it into RFC-hood, though.  I 
haven't seen any major changes in quite some time, and what changes I can 
remember have been well within the range of what normal RFC readers would 
have figured out for themselves.

Alun.
~~~~

--
Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place   | http://www.wftpd.com or email [email-masked]
Cedar Park TX 78613-1419  | VISA/MC accepted.  NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.