Ftp-WG: RE: MFXX questions

Greetings,

> after having read the MFXX-draft I started to implement the features
> mentioned there into my own server.  This brought me some some questions.

I hope I can give some answers.

> 1. mlst-16 states that the MDTM command is only defined on files, not on
> non-files like directories.  What about MFMT and MFF?  Sometimes
> the draft
> mentions "file" and sometimes "object in the NVFS", see e.g. section 4.1.

OK. In my document (draft-somers-ftp-mfxx) that's an editorial mistake... it
should only refer to objects... files and directories are just types of
objects and they should be treated the same. Hopefully I'll get it right for
draft -02 :-)

> 2. Your draft shows (allows?) only the modification of the
> traditional UNIX
> mode bits, what about the sticky-bit set?

Let's be clear about this: draft-somers-ftp-mfxx only specifies two facts
for use in MFF, 'Create' and 'Modify'. Any others mentioned are purely
examples of what could be possible - not what is possible - see section
5.2.1.

I'm thinking that it should also specify a fact for the perms, since that is
pretty neutral. Perhaps by doing something like:

perms=xxx to *set* the permissions to xxx
perms=+xxx to *add* permissions xxx to the existing permissions
perms=-xxx to *remove* permissions xxx from the existing permissions

The OS-specific facts should be documented in a separate I-D/RFC/whatever.
The idea is that somers-ftp-mfxx  meerly provides the framework to modify
the facts... draft-ietf-ftpext-mlst-16.txt provides the framework to read
the facts; the two are complimentary.

My Unix knowledge isn't that great, but I thought the sticky bit could only
be modified if you have root priviledge. Notwithstanding root issues, sure,
you could implement a fact to twiddle the sticky-bit: 'UNIX.sticky' .. don't
forget to document it somewhere as an I-D/RFC/whatever :-)

>
> 3. I can imagine situations where I don't want remote users to set the
> file's execution bit for uploaded files, even if changing permissions in
> general is allowed.  Such a server receives then a "MFF UNIX.mode=775
> some.file" which is not allowed or, depending on the point of view, not
> supported.

If not supported, then UNIX.mode shouldn't have been returned as part of the
MFF FEAT response.

If the client-PI sends it and the server-PI doesn't support it, 504 MUST be
returned.

> It can now be argued that
>
>    (A) the client's permissions are not enough for the operation which
> results in "550 no access",
>
>    (B) the MFF command is not implemented for this particular argument:
> "504 not implemented for this parameter".
>
> On the other hand, the "no-x-bit" configuration could be seen as
> some kind
> of "missing granularity" (as it could happen for timestamps) which whould
> then return a
>
>    (C) "213 UNIX.mode=664 some.file"
>
> showing the client the file's real mode after the operation.

Good point. I think A or C would be the ideal response; B to me seems wrong.

I think that the exact behavior is out of the scope of my document... it
should be covered by a document that details the facts for a Unix-type OS,
which then details the behavior required. Any volunteers to write such a
document? If nobody feels like writing such a document I could be persuaded
to edit/prepare such a document if I'm fed the content (beware: my unix
knowledge is a bit rusty!)

> Please take these as "questions only", I have no preferences for their
> answers.  It's just that, since we are
> discussing this draft, it should perhaps be defined in some way.

They are very good questions, and many thanks for asking them. They got me
thinking :-) I hope I gave some good answers.

> Regarding the current modification/creation time discussion, (3C)
> could be
> also interesting.  As said above, (3C) is already in effect for the MFMT
> and MFCT commands.  But time resolution is mentioned only as one
> example.  Another example could be the OS's limitation that creation time
> can never be newer than a file modification time.  Generalizing such
> OS-dependent cases, the meaning of the 213 response code would become
> something like
>
>     Even if the client receives a 213 response it MUST|SHOULD parse
>     the return value given in the response to see if this is (or
>     comes near to) what the client wants.

That is implicit in the current draft... it says the response MAY not be the
same as that in the request. I'll add a note to implementors that they are
RECOMMENED to parse 213 to see what was actually set.

I've had some further thoughts on the create/modify debate... I'll post
another message when these thoughts can be put into writing.

> This is not very difficult since the server's response lists the file's
> real attributes (or facts) in the same format as they were
> requested by the
> client.

That was why it was done that way.

>
> But to make the create/modify time thing even more difficult, the
> question
> if such things are allowed or not, could be filesystem- and not
> OS-dependent (as the time granularity already is: even a Linux system
> doesn't have time resolution down to a second on a real FAT
> filesystem).  So depending on the FTP server's file space (the filesystem
> mounts) operations might work or fail to some degree.  And in the case of
> the MFMT time resolution even a partial failure could (has to be) good
> enough for the client.  So what I'm suggesting here is
>
>    C> MFF Create=20040204105005;Modify=20030926053600; some.file
>    S> 213 Create=20030926053600;Modify=20030926053600; some.file
>
> in case the server is not able to set a file's creation time after the
> modification time.  It's now left to the client if this is ok or
> not.  Perhaps a new response code should be defined:
>
>     219 approximate operation: the operation might not have been
>         carried out to the client's full satisfaction, the client
>         should examine the values listed in the response.

Not sure I agree with that 219. I think that a 213 is returned, the
client-PI MUST parse the response and can then at its discretion issues
warnings/messages to the user if the requested and actioned times are very
different.

> P.S.: Anyway, now that I'm thinking about it, why should an FTP draft/RFC
> define that a file's creation time is always newer than it's modification
> time?  Even if there are OSes or filesystems that could (thinking
> of Alun's
> archive example: must or simply does) allow this.  I see this as OS or
> client business, but not as something for an FTP specification.

I think it was an oversight. But I'm not sure if it can be corrected before
draft-ietf-ftpext-mlst-16 becomes an RFC. KRE, any comments on this?

(I seem to have missed Alun's archive example... my mail provider had some
problems and a few messages went missing.)

Regards,

David