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?)
Keith
