Frame each JSON text
01A sequence encoder surrounds each UTF-8 JSON text with a record separator before it and a line feed after it.
The next object gets its own RS and LF. There is no array wrapper or special final marker.
Source for this drawing: RFC 7464 · Read RFC section 2.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Octet
- One byte.
- Framing
- Marking where each record begins and ends within a sequence.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Encode each record as RS, JSON text, LF.
- JSON text sequences MUST use UTF-8. UTF-16 and UTF-32 MUST NOT be used. A sequence is not itself one JSON text; it can contain any number of separate JSON texts, including zero.
- The encoder grammar repeats RS JSON-text LF. RS is the single byte 0x1E (record separator), and LF is the single byte 0x0A (line feed). These control bytes are shown as labelled cells in the drawing, not the literal letters R and S.
- The media type is application/json-seq, with no required or optional parameters. The format provides no end-of-sequence marker. An open stream is not required to have a known final record count.
Original fictional log example: {"n":1}, then {"n":2}. The encoder writes two separately framed JSON texts, not a JSON array and not merely newline-separated JSON. The drawing is schematic, not byte-width proportional. Pre-encoded JSON should be parsed before it is added, as discussed in §2.2.
Read the RFC section ↗