Summary

Change the BSON Vector spec to permit allowing zero-length binary data.

Motivation

For historical reasons (Atlas Search implementation preceded Drivers specification), a BSON binary element with subtype "Vector" (9) may be zero-width, containing none of the bytes specified by the BSON Binary Vector specification. Critically, this omission includes the two vector metadata bytes which the spec currently mandates as always-present.

For backward compatibility, given the server does not reject zero-width binary elements, client libraries should be permitted to allow such zero-length binary data as well. Given how niche this edge-case is, "MAY" is probably sufficient; "SHOULD" or "MUST" is likely unnecessary and may be deferred until real-world customer demands motivate Driver-wide alignment.

Who is the affected end user?

Users working with BSON Vectors.

How does this affect the end user?

May be unable to read a valid BSON binary subtype 9 with empty data (which is an invalid Vector).

How likely is it that this problem or use case will occur?

Unlikely? Quoting comment in NODE-7612: 

Accepting subtype-9 binaries without dtype/padding metadata is intentionally supported behavior that predates finalization of the binary vector spec. Data has already crossed the wire in this shape, so for backwards compatibility we need to keep the existing functionality.

If the problem does occur, what are the consequences and how severe are they?

If a user has a stored degenerate empty subtype-9 binary, this may require another tool to read (and fix) the data.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No?

Is this ticket only for tests?

No.

Acceptance Criteria

• Update specification wording to avoid prohibiting a BSON binary subtype 9.
• Add a prose test for drivers to verify their behavior (expectations may vary based based on whether drivers implement the "MAY" clause).