Re: [dispatch] A State Synchronization Working Group

[Michael Toomim <[e-mail]>]

Joe Touch wrote:
> Hi, Michael,
>
> How is this not exactly what all stateful protocols all already do?

Sure! Let's distinguish a *stateful* protocol from a *state 
synchronization* protocol, because these are totally different things.

First, not all stateful protocols do synchronization. Consider the 
stateful protocol FTP:

    $ ftp exmaple.com
    ...
    cwd docs
    mkd ietf-2023
    cwd ietf-2023

These commands change the server state, but don't affect the client 
state. The client doesn't know what the current working directory is, 
nor what's on the server's filesystem.

A state /synchronization/ protocol ensures (or tries to ensure) that 
both peers end up with the same state. For instance, a FTP client can 
download a file from a server:

    get braid-http.txt

...but if the file changes on the server, FTP has no mechanism to 
automatically update the client. And if the file changes on the client, 
FTP does not automatically update the server. And if both client and 
server change the file simultaneously, FTP has no way to automatically 
merge those edits. And if the connection dies, FTP does not 
automatically re-establish the connection and the current working 
directory—the user has to do all of this manually. Thus, FTP is a /state 
transfer/ protocol, not a /state synchronization/ protocol, and it 
happens to do this /statefully/./
/

As a rule of thumb, state synchronization protocols tend to have one or 
more of these keywords in them:

    - Publish / Subscribe
    - Notify / Notification
    - Event, Event Types, State, Updates
    - Diffs, Patches, Merges
    - Synchronization

See https://www.rfc-editor.org/rfc/rfc4533.html for an example that is 
currently open in a browser tab on my computer.

Michael