Subject: Ftp-WG: mlst-16 will correctly say *( %x20-7E )?

From: Pat LaVarre <[email-masked]>
Date: Mon, 29 Jul 2002 17:22:22 -0500

Despite time & study, I'm not sure I'm correctly
understanding the English posted here 17-22 July ...
so I'll post these guesses, and hope for correction?

> From: Gregory A Lundberg [[email-masked]]
> you cannot send ( %x00-1F / %x7F ) on ANY FTP
> command or reply and expect correct interoperation.

Yes.

http://www.ietf.org/internet-drafts/draft-ietf-ftpext-utf-8-option-00.txt
> ...
> The ABNF for pathnames presented in [RFC2640] is
> incorrect.  When UTF-8 encoding is not present,
> the correct syntax is PATHNAME = *( %x20-7E )...

Yes, except where we say "when UTF-8 encoding is not
present" we mean to say "unless some other syntax has
been negotiated", whether that be by OPTS UTF-8 NLST
of the draft FEAT UTF-8 or the OPTS ENCODING URL of
Marc Huber or whatever.

> From: Robert Elz [[email-masked]]
> I'd hate it to fall back into the "Oh, that one"
> state that it has been in for the past year or so.

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.

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.

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.

> > From: Pat LaVarre [[email-masked]]
> > As a server, in a folder, I have a local
> > filename that includes a local Eol.
> >
> > How should that filename appear in my NLST data,
> > supposing the client asked for FEAT UTF-8 NLST?
...
> From: Gregory A Lundberg [[email-masked]] ...
> It cannot appear on ANY FTP command or response.
> Sorry.

Aye, not yet, ouch.

Pat LaVarre

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

---

From: Robert Elz <[email-masked]>
Date: Tue, 30 Jul 2002 01:51:37 -0500

Date:        Mon, 29 Jul 2002 17:22:22 -0500
    From:        Pat LaVarre <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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