Closed josephg closed 3 years ago
Cheers for making things simple! I agree this is a step forward. Further constraining what the server can/can't do with regard to keeping information around for various durations can be up to applications or other specs.
Thanks @josephg and @canadaduane for this work. I think it's a very nice improvement.
I found a couple lines that I think should also be deleted, but I suspect you'll agree with them, and once those are done, I'm in favor of this PR being merged.
This also opens up the question of whether we want an empty Subscribe
header, which becomes a lot more prominent now that we've moved options from it. After merging this, we might want to think about other ways for a server and client to say that they are creating a subscription.
Thanks for the review Mike! I’ll see if I can update the PR with your comments today. (And merge it?)
Sweet.
I'm ok with just merging it, but it might be better to finish the PR, and then write a note here (and/or on the mailing list) saying "Duane, Mike, and I seem to have found consensus at <link>
to remove these options from the Subscribe header. Any objections?" Then wait a bit, and if nobody raises any, then say "looks like there are no objections" and merge.
To help us mature our consensus process, I've been researching the IETF process and keeping notes here: https://braid.org/consensus
The previous language was ambiguous about whether subscriptions must be remembered forever by the server, or if they can be stateless. (It was said they were optional in 3.4 but that stateful subscriptions were mandatory in the introduction.)
After talking with Mike, no other features of the current braid specification depend on persistent subscriptions. This PR removes the ability for subscriptions to outlive their HTTP connections entirely, simplifying the specification.