Re: [Json] Advice on registering JSON Lines (not JSON) as IANA Media Type

> Am 30.12.2020 um 20:03 schrieb Douglas Crockford <douglas@crockford.com>:
> 
> 
> Anything that is not JSON should not be called JSON. It should have a less confusing name.
> 
> 
> 
> On 2020-12-30 8:58 AM, Hlavina, Wratko (NIH/NLM/NCBI) [E] wrote:
>> Hello, Mr. Crockford and Mr. Williams,
>>  
>> I understand you are listed as the authors for the "application/json" and "application/json-seq" IANA Media Types, respectively.
>> I would like to ask for your advice/help with a related file format, JSON Lines:
>>  
>> https://jsonlines.org
>>  
>> I think there is value in having this format registered as a Standards Tree IANA Media Type.
>> Per the RFC6838 process, this requires Expert Review and IETF/IESG approval.
>> Not being a member of those organizations, how can I encourage such registration?
>>  
>> Motivation:
>>  
>> Unfortunately, JSON Lines is not valid JSON (technically) and is different from JSON Text Sequences.
>> However, JSON Lines is a frequently used file format; for example, it is used by many database products, including Cloud services like AWS Athena, Snowflake, and others.
>>  
>> Since it is not valid JSON, using "application/json" as media type leads to processing failures and mishandling.
>> Since it uses the newline as separator, without RS Unicode Information Separator Two record separators, "application/json-seq" is not a substitute Media Type, and the ecosystem of tools do not, in general, support JSON Text Sequences format.
>>  
>> In principle, good JSON programming libraries should allow streamed processing of JSON content, both in emitting it and in reading it, but in practice, libraries for JSON tend to require an entire JSON object to be held in memory.
>> Since HTTP emits one response per request, this implies only a single JSON object per response, if using "application/json" as Media Type; this is problematic for large data.
>>  
>> In my experience, JSON Lines has become a very useful and conventional file format, since it interoperates well with Unix text utilities while remaining highly interoperable with many JSON tools.
>>  
>> Cf.:
>> RFC6838
>> https://www.iana.org/assignments/media-types/application/json
>> https://www.iana.org/assignments/media-types/application/json-seq
>> https://www.iana.org/assignments/media-types/application/ld+json
>> https://stackoverflow.com/questions/51690624/json-lines-mime-type
>> https://github.com/wardi/jsonlines/issues/9
>>  
>> --
>> Wratko HLAVINA
>> Sequence Curation, Organization, Enhancements (Technical Program Manager)
>> NCBI Building 45 Floor 4 Room AS13D-121
>> Slack: whlavina / Phone: 301-402-9730 / FAX: 301-480-2484 / Calendar: https://bit.ly/2QU2EGB
>>  

Well, this is JSON texts separated by newline characters.
I think the original JSON sequences proposal started exactly like this (with newlines)
this is how I remember our e-mail discussions - and then the not too surprising practical ivory tower like discussion waves injected the long forgotten RS into the picture. 

Reading the RFC again I suggest to not reuse the json-seq media type in this case, as that specification  assumes skipping to RS tokens between JSON texts which these newline separated JSON streams will not offer.

I suggest to rather request a new media type from IANA and would not object having it start with text/json-

Please enjoy all a healthy and wonderfully non-semantic Year version 2021,
Stefan
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json