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

[Dave Cridland <[e-mail]>]

On Fri, 27 Nov 2020 at 01:44, Keith Moore <[e-mail]>
wrote:

> On 11/26/20 5:00 PM, John C Klensin wrote:
>
> I remember when IETF cared about making standards and
> promoting broad interoperability.
>
> Of course, there would be another way to do this, one that would
> create an RFC but not a standard.
>
> Yes, it seems like an Informational document, but one that actually
> describes the rsync protocol in sufficient detail to implement it in a way
> that interoperates, would be a useful service to the Internet community.
> And it should be Informational rather than standards-track.
>
> (Note: It's very important that such a document be accurate.  I remember
> how much breakage RFC 1179 caused, and I suspect that it still continues to
> cause some.)
>
> What I have a hard time with, given that we're supposedly a
> standards-making organization that's trying to promote interoperability, is
> that people who seem to be somewhat prominent in this organization are now
> arguing that we should replace a proven standard protocol that has probably
> hundreds of implementations, with a protocol that may be less functional,
> is not a standard, doesn't have a published spec, and only seems to have a
> small number of implementations.
>
> (If someone isn't into promoting standardization and interoperability, why
> are they participating in IETF?)
>
> Of course, publishing an accurate description of the rsync protocol would
> address at least part of that problem.
>
> There's also the related argument that some people keep making that rsync
> is sufficient not because it's a widely or easily implemented protocol, but
> rather, because there's a program that implements rsync that people can run
> from scripts.   Apparently bits on the wire as a basis for interoperability
> isn't important any more and we can just go back to standardizing APIs?
>
> And whatever happened to the notion that we should eat our own dog food?
> (And if the dog food doesn't taste good, why don't we fix it?)
>
 This was, of course, where I was going with my rhetorical question.

More broadly, we seem to have - as a community, I mean - decided not to
bother with application standardization anymore.

I see this most painfully with XMPP, of course, but I also see no interest
from the vast majority of the community in standards around email, for
example, except where it matters to connect Google to Facebook.

I came to the IETF originally drawn by the work going on in FTPEXT, around
20 years ago. "Retiring" FTP in favour of a newer protocol would be
bittersweet, of course, but retiring it in favour of a broadly proprietary
(albeit open source) file transfer/sync protocol simply doesn't sit right.

Overall, the IETF seems to be sending a clear signal that application layer
interoperability is unimportant, and existing protocols should be retired,
replaced by open source projects or whatever proprietary solution seems
convenient and commonplace.

I understand the convenience, and I understand the need for a commonplace
solution.

But aren't we the very people who make the complicated and bespoke into the
convenient and the commonplace?

Dave.