Ftp-WG: mlst-16 will correctly say *( %x20-7E )?
Robert Elz <[email protected]> Tue, 30 Jul 2002 01:51:37 -0500
| Newsgroups | gmane.ietf.ftpext |
|---|---|
| Message-ID | <[email protected]> |
Date: Mon, 29 Jul 2002 17:22:22 -0500
From: Pat LaVarre <[email protected]>
Message-ID: <[email protected]>
| Our intent is to close out the MLST effort __without__
| taking the time to teach MLST to handle the path names
| over which NLST LIST etc. choke.
Something like that ... extending the scope of path names isn't really
what this draft was intended to be about - there was another draft (now
an RFC) whose purpose was that, this draft just intended to make use of
that one.
| http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-15.txt
| > pathname = utf-8-name / raw
|
| Accordingly we can hope to see this error corrected
| before the final draft.
I doubt it, it isn't an error. There is one particular set of characters
that we can't transfer in a path name (CRLF) but that's it. All the rest
are OK.
The "utf-8-name / raw" is intended to convey the interpretation that
(almost) any sequence of bytes is legal (that's "raw") while suggesting
that if those bytes happen to be utf-8 that is much better.
| Here when we say utf-8-name's we mean only those which
| do not contain ( %x00-1F / %x7F ). Or maybe we mean
| only those which do not contain ( %x00-1F / %x7F /
| %x80-FF), formerly known as locally printable Ascii
| names.
No, we don't mean anything of the kind.
Note: what is being specified here is what the protocol can transfer.
That is only just peripherally related to the set of names that any
particular client and server will allow. The protocol allows the name
\0\0\0 (and treats it differently from \0\0 and \0\0\0\0) and all of
that works just fine. It also allows xxxCRxxx and xxxLFxxx and
xxxCRxLFxxx as well. And lots more. Whether any of those make
sense to any particular implementation is up to the implementation.
About all that is required is that the names the server presents in
its directory listings (and for us, particularly, in MLSx) can be sent
received back again in those commands that take a file name arg.
I'm currently working out just where and how to say that CRLF isn't
handled (suggestions welcome) - as soon as that is done, a new version
of the draft will be submitted for WG review, and then hopefully it
will finally get sent for IETF last call (or perhaps approved, if the IETF
last call was already held - it has been so long that I forget, certainly
there have been no changes of substance in years...)
kre