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