Subject: Ftp-WG: draft-somers-ftp-mfxx-01

From: "David Somers" <[email-masked]>
Date: Thu, 5 Feb 2004 16:54:56

Dear all,

I have updated draft-somers-ftp-mfxx-00 to incorporate a few changes and
corrections. (The previous draft expired Jan 2003, so it was about time I
updated it - sorry for taking so long!).

I'm quite keen to get this published as an RFC - if only so the whole mess
of setting modification via MDTM can be avoided ;-) - however, it does
rather assume that draft-ietf-ftpext-mlst-16 has been formalized...
otherwise I will just have to repeat (rather than simply refer to) a whole
bunch of stuff from that spec, and I'd rather not do that.

The new draft has been submitted through the usual channels to be published
as an internet-draft.

Meanwhile, it can be grabbed from:

http://www.trevezel.com/downloads/draft-somers-ftp-mfxx-01.html as
prettified HTML,

or

http://www.trevezel.com/downloads/draft-somers-ftp-mfxx-01.txt as plain
ASCII.

Comments and suggestions always welcome.

Regards,

David Somers

---

From: "Anthony R. Gold" <[email-masked]>
Date: Fri, 6 Feb 2004 04:08:39

> updated it - sorry for taking so long!).

Looks great.  Where do I vote?  :)

1) Dave, what MUST servers do when asked to set a modification date which
is earlier than the creation date?

Reply with an Error Code and do nothing?
Automatically set the Creation date equal to the new Modification date?

2) Is a change to the Creation date a Modification?  Right now there is
vagueness as to what changes constitute "Modification" and so call for
changes of Modification dates.  Would it be appropriate to give guidance
on what changes SHOULD call for changes to the Modification date, or is
that to remain outside the scope of this work?

Thanks for the really super effort.

Tony

---

From: Robert Elz <[email-masked]>
Date: Fri, 6 Feb 2004 05:11:04

Date:        Thu, 5 Feb 2004 16:54:56 
    From:        "David Somers" <[email-masked]>
    Message-ID:  <[email-masked]>

  | - however, it does
  | rather assume that draft-ietf-ftpext-mlst-16 has been formalized...

It has been, it is approved - it is just a matter of getting it
published now (which means me finding the time to get the formatting
into an acceptable fashion).   A few more weeks and it should be done
(as in, actually be an RFC in the RFC directories).

kre

---

From: "David Somers" <[email-masked]>
Date: Fri, 6 Feb 2004 06:28:10

> (as in, actually be an RFC in the RFC directories).

I was just about to ask you what was happening with it... I saw that it was
in the RFC Editor Queue "Awaiting Author Action".

I think a lot of people will be happy to see it finally become an RFC after
its many years as an I-D.

Cheers,

David

---

From: "David Somers" <[email-masked]>
Date: Fri, 6 Feb 2004 09:14:19

> Automatically set the Creation date equal to the new Modification date?

How about crash and burn? - just kidding!

I'm not sure whether attempting to set the modification date prior to the
creation date is an error. Sure, it may be silly (or just plain stupid), but
some filing systems allow this condition to happen (I think Windows NTFS
allows it).

How about this:

If MFF is not supported, the client-PI SHOULD issue MFCT (if supported)
before MFMT. This is to avoid the possible situation where the client-PI
could set the modification date to a date before the existing creation date,
which MAY be prohibited by the NVFS. However, it MAY be possible for a
client to attempt to set the modification time prior to the creation time;
this situation may be nonsensical, it may happen, and it is RECOMMENDED that
it not be considered an error by the server-PI.***

*** My feeling is that this is only an issue for Windows users where the
file system has the concept of create and modify facts. Unix/Posix systems
only have modify, so the create fact will never be able to be modified
because MFCT will not be implemented, and MFF will not support the Create
fact. I could be wrong. Comments/Corrections welcome!

> that to remain outside the scope of this work?

OK. I'm thinking of adding the following:

- All facts are to be considered autonomous, and modifying any facts MUST
not cause the server-PI to update the modify fact (unless impossible to
avoid due to the operating environment). The modify fact MUST only be
modified by either MFMT or through the Modify fact to MFF.

- Given the choice, client-PIs SHOULD use MFF in preference to issuing MFCT
then MFMT.

Cheers,

David

---

From: "Anthony R. Gold" <[email-masked]>
Date: Fri, 6 Feb 2004 09:54:14

> fact. I could be wrong. Comments/Corrections welcome!

If it is true that the create time-val can sometimes be later/greater than
the modify time-val, then perhaps something different should be said at
7.5.4 of http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-16.txt
which now states: "About all that can be said about the value returned [by
a query of creation fact] is that it can never indicate a later time than
the modify fact."; indeed it was that comment, and the potential here for
an inconsistency with it, which prompted my question.

Tony

---

From: "Brad Clements" <[email-masked]>
Date: Fri, 6 Feb 2004 12:59:08

> an inconsistency with it, which prompted my question.

I think this is an OS specific issue. What the underlying filesystem allows or not is 
more important. Maybe this condition makes sense for some OS we have not yet 
seen. 

The FTP server is probably not the best place to make this policy decision.

So, if you leave it up to the OS to allow or not, you will need some way of indicating 
an OS failure  in setting the mod time, or the create time, or both. I think the xxx 
return code should be encoded to indicate clearly which time value or option failed to 
be set, rather than leaving it to the expanatory text (unless for MFF you specify that 
the failed option name(s) will be listed)

-- 
Brad Clements,                [email-masked]   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
http://www.wecanstopspam.org/                   AOL-IM: BKClements