RFC 8259
The JavaScript Object Notation (JSON) Data Interchange Format
Standards Track Obsoletes: RFC 7159 December 2017
Abstract: JSON is a lightweight, text-based data interchange format derived from JavaScript. It is the mandatory data format for all 5G SBI API request and response bodies, as specified in TS 29.500.
Canonical source: https://www.rfc-editor.org/rfc/rfc8259
| IETF Datatracker
1. Introduction
▶JSON is a text format for structured data using key-value pairs and ordered lists. It is language-independent but uses conventions familiar to programmers of the C-family of languages.
All 5G SBI APIs use JSON as the payload format (Content-Type: application/json). NF service specifications (TS 29.5xx) define OpenAPI 3.0 schemas for all JSON request/response bodies.
2. JSON Value Types
▶| Type | Example | 5G SBI Usage |
|---|---|---|
| Object | {"key": "value"} | NF profiles, session contexts, subscriber data |
| Array | ["item1", "item2"] | S-NSSAI lists, DNN lists, NF service lists |
| String | "imsi-208930000000001" | SUPI, GPSI, DNN, FQDN identifiers |
| Number | 42, 3.14 | Port numbers, timer values, bit rates |
| Boolean | true, false | Feature flags, capability indicators |
| null | null | Absent/unknown values |
3. Encoding Requirements
▶- Character encoding: MUST be UTF-8 (no BOM). JSON text exchanged between 5G NFs MUST use UTF-8
- No comments: JSON does not support comments — specifications use external documentation
- No trailing commas: Strict JSON parsing required — no extensions
- Number precision: IEEE 754 double precision — integers up to 2^53-1 are safe
- String escaping: Control characters MUST be escaped (\n, \t, \uXXXX)
4. Security Considerations
▶- JSON parsing MUST use a proper parser — never eval() or equivalent
- Large JSON payloads can cause denial of service — NFs should enforce size limits
- Deeply nested JSON can cause stack overflow — enforce depth limits
- Duplicate keys have undefined behavior — parsers should reject or use last-value-wins consistently