Re: documenting rsync, or, what are we here for anyway? (was: Re: what is rsync)

[Joseph Touch <[e-mail]>]

> On Nov 27, 2020, at 11:56 AM, Salz, Rich <[e-mail]> wrote:
> 
> Note that I am *not* commenting on the proposal to remove FTP.  Joe’s note just brought up some questions.
>  
> FWIW, although that may be true for this use case, it’s useful to keep in mind that FTP encodes a large body of experience
>  
> I thought FTP stopped evolving in like 2005 with RFC 4217, about how to use TLS.  Am I missing something?

Everything that HTTP continues to reinvent that was in FTP before there was an HTTP.

> that, in some ways, HTTP continues to try to evolve to replicate (like letting IP be the multiplexing unit and automatically avoiding HOL blocking).
>  
> Does FTP do multiplexing?  How?  Which RFC?

Yes; it opens a connection per exchange and let’s IP multiplexing do its job. As far back as the mid-90s I noted that HTTP was headed towards reinventing that muxing at the app layer and it now does. That creates a problem of layered multiplexing and how the two interact, esp. for DSCP tagging, among other things.

> FTP isn’t quaint in that regard. It remains the gold standard in many ways and has many lessons still to offer.
>  
> Such as?

Don’t reinvent multiplexing, for one. Have a common data encoding or support translation. Separate the control channel from the data channel. Support transfer restart. Support parallel transfers without HOL blocking. Support transfers with record boundaries.

Some people, IMO, incorrectly claim that HTTP fixed the bugs in FTP; AFAICT, it’s the been converse.

Joe