Represent time and binary data explicitly

Representation conventions improve predictability; they do not supply authentication or authorization.

• Time/date data items are RECOMMENDED as ISO8601 strings as specified by RFC3339, with uppercase letters, an explicit timezone and seconds included even when00 (§4.3). The chosen timestamp2026-10-24T12:30:00+00:00 has those properties. Uppercase Z is another timezone spelling; UTC/Z is not the only permitted offset.
• Durations are also RECOMMENDED to follow the duration production in RFC3339 AppendixA, with the applicable additional restrictions (§4.3). PT30S is a chosen duration of30seconds, not a timestamp or an absolute date. The small shape helper does not validate every calendar date, leap-second event, ISO8601 duration or business rule.
• Arbitrary binary content is RECOMMENDED as a base64url-encoded JSON string (§4.4, RFC4648§5). Chosen bytes fb ff become "-_8=". The URL-safe alphabet uses - and _ instead of + and /; this is encoding, not encryption. RFC4648§3.2 requires padding unless the referring specification explicitly permits omission; no such unpadded protocol exception is assumed in this example.
• The application must know which strings represent timestamps, durations, identifiers or binary content. Ordinary JSON strings have no built-in type tag assigning those meanings. The illustrated field names are fictional choices, not standard I-JSON members.
• JSON security considerations still apply (§5, originally RFC7159; current JSON RFC8259§12). I-JSON removes some unpredictable idioms but supplies no signatures, encryption, freshness or access control. A valid {"op":"peek"} still needs the surrounding application’s independent permission check. JCS/RFC8785 is a separate canonicalization scheme, not an automatic feature or formal update of RFC7493.