Removed the ability for subscriptions to outlive connections

[josephg]

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.

[canadaduane]

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.

[canadaduane]

I still think it's weird to have either a "blank header" or a keep-alive as possibilities here. Does a blank header mean anything different than keep-alive? Also, is keep-alive the right word to use? (it's a little bit better now that it means "keep alive for current connection" but I had opened this for discussion here: https://groups.google.com/g/braid-http/c/iamJIcLdsag/m/ojGeT3aVAgAJ)

[josephg]

Yeah I have no idea what the semantic difference is supposed to be either. @toomim

[toomim]

The distinction is:

• Subscribe: subscribe until the connection is closed
• Subscribe: keep-alive: subscribe and remember history forever
• Subscribe: keep-alive=<seconds>: subscribe and remember history until <seconds> after the connection closes

That was supposed to be clear in the text that's being deleted in this PR. Was something about the writing ambiguous?

[toomim]

Also, I think you want to delete the Subscribe: keep-alive variant as well, since that is also a subscription that outlives the connection.

[canadaduane]

That was supposed to be clear in the text that's being deleted in this PR. Was something about the writing ambiguous?

I meant "Does a blank header mean anything different than keep-alive" now that we've removed the ability to "hold on to" a connection as we've done in this PR.

[toomim]

Oh! Ok, that clears it up. Thank you.

[toomim]

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.

[josephg]

Thanks for the review Mike! I’ll see if I can update the PR with your comments today. (And merge it?)

[toomim]

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.

[toomim]

To help us mature our consensus process, I've been researching the IETF process and keeping notes here: https://braid.org/consensus

[josephg]

So the one remaining issue here is what to do with this part of the spec:

       Subscribe
  or   Subscribe: keep-alive

Edit: But it looks like Duane has opened a new issue for this. If there's no other objections, I'll merge this next week.