Representing Namespace and Track Names

There is often a need to render namespace tuples and track names for purposes such as logging, representing track filenames, or use in certain authorization verification schemes. The namespace and track name are binary and need to be converted to a safe form.

The following format is RECOMMENDED:

Each of the namespace tuples are rendered in order with a hyphen (-) between them followed by the track name with a double hyphen (--) between the last namespace and track name.
Bytes in the range a-z, A-Z, 0-9 as well as _ (0x5f) are output verbatim, while all other bytes are encoded as a period (.) symbol followed by exactly two lowercase hexadecimal digits.

This format allows many common names to be rendered in an easily human readable form while still supporting binary values. Note that while the character set is chosen to be generally both filename and URL safe, filename safety is platform specific; for instance, on case-insensitive filesystems, track names can collide.

1.5.1. Parsing Serialized Names

When parsing a serialized namespace or track name back to its binary form, implementations MUST apply the following rules to ensure a canonical encoding:

A period (.) MUST be followed by exactly two hexadecimal digits. A trailing period or a period followed by fewer than two hexadecimal digits is invalid.
The hexadecimal digits following a period (.) MUST be lowercase (a-f). Uppercase hexadecimal digits (A-F) are invalid and MUST cause parsing to fail.
Bytes that can be represented literally (a-z, A-Z, 0-9, _) MUST NOT appear in their hex-encoded form. For example, .61 is invalid because a must be represented as the literal character a. A parser MUST reject such redundant encodings.

These rules ensure that the encoding is bijective: every binary value has exactly one valid serialized representation, and every valid serialized string maps to exactly one binary value. This property simplifies comparison of serialized names without requiring full deserialization.

Implementations that receive an invalid serialized name SHOULD treat it as an error. The specific error handling behavior is application-defined.

Example:

example.2enet-team2-project_x--report
  Namespace tuples: (example.net, team2, project_x)
  Track name: report