Editing SimTX API/Compatibility and versioning (section)

== Feature registry ==
Optional server capabilities that depend on the deployment rather than on the schema are listed by name in <code>ServerHello.features</code>, and per server in the [[SimTX API/Server directory|server directory]] with <code>?include=features</code>.

{| class="wikitable"
! Feature !! Meaning
|-
| <code>stations.v1</code> || Persistent stations: <code>StationBinding</code> in session starts, station-bound tickets, station entries in the station list.
|-
| <code>pointing</code> || [[SimTX API/Packets/AntennaPointingUpdate|AntennaPointingUpdate]] and <code>Tracking</code> are accepted.
|-
| <code>ephemeris</code> || [[SimTX API/Packets/EphemerisRequest|EphemerisRequest]] is answered.
|-
| <code>passes</code> || [[SimTX API/Packets/PassPredictionRequest|PassPredictionRequest]] is answered.
|-
| <code>kinematics</code> || Satellite motion (orbit, attitude, Doppler) is simulated.
|}

<code>ClientHello.features</code> uses the same names for what the client understands: send <code>stations.v1</code> if the client handles [[SimTX API/Data types#BoundStation|BoundStation]] and station-bound sessions.

Rules:
* Clients ignore feature names they do not know; servers do the same.
* Names are never reused or redefined. A changed meaning gets a new name, such as <code>stations.v2</code>.
* Treat a missing feature as "not available" and hide the user interface for it.
* Prefer feature checks for deployment capabilities and <code>protocol_revision</code> for knowledge of the schema. Avoid checks on <code>server_version</code>.
* The account service mints station-bound tickets only for servers that advertise <code>stations.v1</code>; otherwise it answers <code>409 station_binding_unsupported</code>.