Re: [ftpext] COMB command IETF draft proposal

[" Ángel González " <[e-mail]>]

Robert Oslin wrote:
>
> "Any submission to the IETF intended by the Contributor for 
> publication as all or part of an IETF Internet-Draft or RFC and any 
> statement made within the context of an IETF activity is considered an 
> "IETF Contribution".
>
> It only took me 10+ years, but here's my contribution the FTP ext 
> community (attached).
>
I still have some cuteftp binary ~12 years old :)

> Essentially an early draft to ratify the commonly used COMB command 
> for support of multi-part (a.k.a accelerated) uploads. I welcome 
> comments/questions from the community. Ideally redlining the document 
> (or via comments in the doc). I will resubmit using formal IETF draft 
> (in ASCII) once I've addressed all comments/questions in the MS Word 
> version (hope that's ok and doesn't break and IETF rules).
>
Libreoffice opens it fine, but the Table of contents is garbled, and 
there's a footer 'Oslin Expires 
666666000000FailFailFailFailFailFailDecemberDecemberDecemberDecemberDecemberDecember 
9/06/11 6201192009201020102011' which I doubt is present in the original 
file.


I would change the text
>
> in the rare case COMB is used as an append rather than a create 
> operation, which is why a single (source) part pathname is supported.
>
to
 > in such case COMB appends the partial pathnames to the existent file.

Regardign the Client or Server delete question:
a) Which is the behavior of current implementors?

b) IMHO "The client MUST check that no partial files are left after they 
are no longer needed."
Note that some interrupted upload could have left temporary files, so 
the client should always check. I'd suggest in the rfc using some 
specific pattern that the can application can easily recognise, maybe 
even containing the hash of what's supposedly there.

So if connecting a new session, the client detects a file called 
partial-8418bfdb63bc5d6ccc434b33d6017cd4.tmp it could prompt the user 
about deleting temporary files it has found. But also, on resuming a 
temporary upload, that same file could be reused without needing to 
reupload it (eg. the connection dropped when uploading the 7th piece, on 
next run it can skip the first 6 blocks), by knowing which piece it is 
(from the hash) and verifying that the content indeed matches (with HASH 
command).
Another option would be basing the temporary names on the target name, 
eg: mybigfile.iso.1 mybigfile.iso.2... Same resuming capabilities are 
available, by knowing the file sizes (and the block size it uses when 
splitting) and usage of the hash command.

I would provide the server the ability of deleting files after COMB, 
specially in cases where copying the final file would exceed the quota, 
in which case it COULD generate the big file and remove the partial ones.

I think there should be an error code for "I won't perform the action in 
this mode (text)" for cases where combining would involve some kind of 
transliteration.