Subscription parameters

[toomim]

The spec provides a lot of flexibility in how servers return subscription data:

• The rate of updates
• The granularity of updates
• The format of updates (e.g. patch vs. snapshot; patch-type)
• The versioning system (e.g. version-type) to use
• Whether (and how) patches are rebased
• How to behave if a disconnection happens
  • E.g. How long to hold history for offline clients
• etc.

We would like clients to be able to specify how they'd like this data.

We have left room in the Subscribe: <parameters> header to specify these parameters. This issue is a spcae to design the parameters spec. What options should exist in there? How should they be specified?

See the Structured Headers rfc8941 for reference on how to structure header values in HTTP.

This issue consolidates discussions from: #80 (keep-alive), #92 (rebase mode), #101 (rebase mode), and #115 (rate & format of updates), and should be consider the discussion in #105.

[toomim]

Ah, @CxRes just wrote up a great list of subscription parameters for consideration here: #124 (comment)!

[toomim]

@CxRes also points out that subscription parameters are defined via the Accept-Events: header in his PREP proposal, and we could use that for reference.