Subject: Ftp-WG: MLST "comment" fact

From: "Mike Gleason" <[email-masked]>
Date: Mon, 18 Jan 1999 01:51:52 -0500

At 07:25 PM 1/17/99 +1100, Robert Elz wrote:

>---> MLST aarnet
>250- Listing aarnet
> Type=OS.unix=slink:aarnet;Size=6;Modify=19951105154900;Perm=;Unique=keVO1+A 
>/aarnet
>250 End

I retrieved the latest -05 draft and I hope to have some modifications
completed to both client and server for further testing.  A quick question
regarding the symbolic link type:  I had been wondering how to include the
"linked to" portion of the symbolic link in the data and I noticed how you
have it embedded after the OS.unix=slink portion.  That seems reasonable,
but how should we handle the case where the destination contains a
semi-colon or space character?  We may need to provide for an escape
character to be able to embed a space or semi-colon.

Another reason we may want to do this is because I can foresee a need for a
"comment" fact.  For example, on MacOS, the user can embed a few lines of
text as a description for a file which could easily have spaces and
semi-colons.  Or, on Windows, a "version" fact which can print the version
resource information embedded in the file.  Come to think of it, a
"comment" fact may be useful all around as an easy way to attach a
description to a file.  Atleast one FTP client (Alex Kunadze's?)  looks for
files named "README" or "CONTENTS" and then in directory listings, try to
match up lines from the downloaded CONTENTS file right along side the
filenames in the listings.  Something like this wouldn't take off and be
useful unless the spec mentioned it as a possible optional fact to implement.

Also, just my personal preference, I like OS.UNIX=symlink better than
OS.unix=slink.  (UNIX since we use UNIX.mode in the spec, and symlink just
because.)

Mike Gleason

---

From: Robert Elz <[email-masked]>
Date: Mon, 18 Jan 1999 02:18:30 -0500

Date:        Mon, 18 Jan 1999 01:51:52 -0500
    From:        "Mike Gleason" <[email-masked]>
    Message-ID:  <[email-masked]>

  | At 07:25 PM 1/17/99 +1100, Robert Elz wrote:

Mike is referring to some mail we exchanged - we have been testing
against each other's servers (so, no, the list didn't break for the
rest of you).   And when I sent the MLST data to Mike, the MLST
output fact line was all one line, it hadn't been wrapped (or if it
was, my mailer needs fixing, as that wasn't what was supposed to be sent).

  | That seems reasonable,
  | but how should we handle the case where the destination contains a
  | semi-colon or space character?

Very good question (and a lot of other chars that aren't legal as well).

  | We may need to provide for an escape
  | character to be able to embed a space or semi-colon.

That, or encode the whole thing somehow.   Or don't provide the
target in the MLSx output at all, but make some other way to fetch
that information.

Aside for other readers - this all refers to symlinks that point to
nothing (there is no file at the target location, or the file there
can't be referenced by the authorised user, or various other wacky
error cases).   Where the target exists, the server should refer to
the target for all the facts (including the file type, so the symlink won't
be visible as such - the unique fact will also represent the target file,
so the client will know that a link of some kind was used between the
files).

  | Another reason we may want to do this is because I can foresee a need for a
  | "comment" fact.

Is there support in the group for this to become a standard fact type?
If so, how do we do the encoding?

  | Also, just my personal preference, I like OS.UNIX=symlink better than
  | OS.unix=slink.  (UNIX since we use UNIX.mode in the spec, and symlink just
  | because.)

"UNIX" and "unix" and "Unix" (and all the rest) are the same thing, it is
case independent.   As my server is more for generating examples for the
draft than for production use I'm sometimes weird in not generating what
the draft might suggest is the "normal case" for case independent strings.

As for "slink" - I wimped ... some people like "symbolic link" others like
"soft link", "slink" let me win both ways...

That's the kind of detail (along with how to encode the value) that we
need to sort out when we register a set of UNIX.* OS dependent facts and
file types with the IANA, after the doc itself is published.

Ideally there will be two or three servers around that I can send some
queries at to assist in generating examples for the draft.   Even better
would be if (for now) they did the system dependent things differently,
so I can put in these kinds of examples in the draft without thereby
suggesting what the registered system dependent labels ought to be.
That is, if I can show "OS.UNIX=symlink" and "OS.unix=slink" (and maybe
even more) in adjacent examples, and explain that they show how OS
dependent types can be used - but that the IANA register should be
consulted to obtain the actual types names to use (or to add new ones),
as clearly the inconsistent usages in the examples cannot themselves
be the thing to do.

kre