RFC document

[finnp]

It might be a bit more credible to have the ndjson spec as an RFC document. @hoegertn, you said a while ago that you wanted to work on it. Do you already know what's nececarry to make this happen?

I think it could be helpful with #19 and #20.

[hoegertn]

Hi, I read some HowTos and it seems to be a non-trivial task. But as the spec is not very complicated it should be possible.

[hoegertn]

How are we making progress on this topic? What is the Roadmap and who will be working on it?

[hoegertn]

@finnp @chrisdew Is there any reason not to write an RFC and register with IANA?

I will start to write it otherwise.

[finnp]

No sounds good, but it would probably be helpful to research the topic a bit again. To see if other standards were established.

[veqryn]

Is there an RFC for this yet?

[hoegertn]

No, not yet. The process to write one seems pretty hard and I did not find the time yet.

[whlavina]

The lack of a definitive IANA Media Type for JSON Lines causes some difficulty for those of us using the format. In the interest of pushing the issue, I took the liberty of starting a conversation: https://mailarchive.ietf.org/arch/msg/json/dWMWD0JDa2HiUYjWjLjrQExeIx4/

Perhaps someone here would like to join that thread?

Disclaimer: I am in no way affiliated with the IANA/IETF. I am merely interested in using the format, correctly.

[hoegertn]

Sounds great. Are you preferring jsonlines over ND-JSON or are you using it more or less as a synonym?

[whlavina]

I understand the only difference is that JSON Lines constrains the encoding to be UTF-8, whereas NDJSON lacks such constraint. Per RFC8259 section 8.1:

JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8

I think this means that, for purposes of interchange, JSON Lines and NDJSON are equivalent, with JSON Lines Rule 1 being redundant outside of a closed system. I'm not sure if the author of JSON Lines wrote that Rule 1 given the historical JSON Specification of RFC7159 (obsolete as of Dec 2017), which was more lax (allowing UTF-16 and UTF-32), or whether Rule 1 is meant to encourage using the full Unicode set rather than limit text to ASCII.

In any case, I believe our applications assume UTF-8 even in a closed system (e.g. files at rest on disk), so for us, JSON Lines is appropriate and more accurate than just NDJSON, but pragmatically, these are synonymous for us.

If JSON Lines vs NDJSON truly are synonymous, as of the RFC7159/RFC8259 specification update, then I'll leave it to the community to clear this up - it's probably a conversation between the respective authors, and if there is a difference, perhaps each respective home page can reference the other and explain the relationship?

If you want my opinion on naming: "JSON Lines" seems more conventional, but "newline delimited" ND-JSON avoids ambiguity with "line delimited" which leads to confusion with "JSON-LD" (Linked Data).

[mattbishop]

I'm pretty sure the encoding of the text is independent of the spec. The ECMA JSON spec does not specify a file encoding either: https://www.ecma-international.org/wp-content/uploads/ECMA-404_2nd_edition_december_2017.pdf

[sqrtroot]

Is there any update on this? If not, I could help writing this. It might be useful to make a branch in this repository to start writing it and then once the community here is agreeing we can pass it on to IETF and then apply for an official IANA Media Type.

[asbjornu]

It may be worth a shot getting the spec adopted by the Building Blocks for HTTP APIs Working Group so more API experts and perhaps, more importantly; proficient RFC editors will get their hands on it. The Working Group is free to join, so please do and raise the issue there. :)