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?)
On Fri, 27 Nov 2020 at 01:44, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
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.
