Describe response meta header's goal and responsibility

[carpawell]

It has true optional things (like X-Headers, as defined in their description), and at the same time it has things that do not look like optional helpers: epoch, and API version, but in practice they may not be set, and everything works.

Is your feature request related to a problem? Please describe.

I'm always frustrated when we have undefined behaviour.

Describe the solution you'd like

One of:

1. make every field required and make it clear in the spec
2. make them fully optional, and make it clear in the spec that every request may define its meaning depending on the requirements this request has (e.g. object/GET: allow to fetch exact EC part in GET request #393)

Describe alternatives you've considered

-

Additional context

nspcc-dev/neofs-sdk-go#822

[cthulhu-rider]

seems related to #213

whatever behavior is defined, it shouldn't give the server freedom. Each fixed request should lead to the same response (in a consistent state i mean)

passing server's epoch and API version is senseless to me. They are dedicated RPC for them. And client cannot toggle the demand for this data on a per-request basis, which mainly results in the transport of unused data

[carpawell]

We may deprecate them then.

[roman-khimov]

What we have there is:

• version --- which can only be useful if server responds with version lower than request had (old server, new client), optional otherwise (new server should respond in a compatible manner to old client anyway)
• epoch --- theoretically interesting to detect out of sync states for clients, but we're relying less and less on epochs and it's never used practically, so optional as well
• ttl --- has no real meaning now
• x-headers --- optional by definition, API-specific by nature
• origin --- also meaningless now
• status --- useful, but even this one is optional to me if it's all OK (but not worth changing at the same time)