Summary

The current extended JSON spec discusses parsing of extended JSON $uuid but seems silent about generating that format.

It would be advantageous for drivers to privilege that format when serializing BSON as extended JSON; thus, the spec should probably mention $uuid’s priority.

Motivation

Who is the affected end user?

Humans who read extended JSON (e.g., log files)—support, developers, etc.

How does this affect the end user?

The base64 format is harder to parse. Oftentimes it’s necessary to paste it into `base64 -d | xxd` in order to get hex to compare against something else that serializes the same UUID to hex.

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

Almost every successful mongosync log probably has this problem. I can’t speak to its prevalence elsewhere.

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

Minor annoyance at a log message.

Is this issue urgent?

Not urgent.

Is this ticket required by a downstream team?

No, but it may affect things that expect $binary.

Is this ticket only for tests?

no

Acceptance Criteria

The extended JSON spec should mention generating $uuid, e.g.:

• Drivers MAY generate either $uuid or $binary. They MAY expose a control to allow callers to choose one output or the other.
• Drivers SHOULD generate $uuid. They MAY expose a control to generate $binary instead, with appropriate discouragements in documentation.
• Drivers MUST generate $uuid.