Subject: [Uta] consensus call on K/V vs JSON

From: Leif Johansson <[email-masked]>
Date: Fri, 21 Jul 2017 13:10:36 +0200

We had a (less than spirited) discussion in Praha about the K/V vs JSON.

There was no clear consensus for switching from JSON to K/V based on
the proposal from the spec authors sent to the list last week.

Victor expressed his views clearly and I'll not ask him to repeat
himself. I will attempt to summarize the discussion - feel free
to correct me!

The situation is that of the active participants that are also
implementors one (postfix - Victor) has said that he does not believe
that postfix will ship with a standard JSON-based implementation but
that this doesn't preclude third-party plugins.

The other major implementor who is also an active participant (google)
has stated that they have a JSON implementation but that they are
also eager to close this issue. One more implementor (Chris) has stated
no preference but also said that his (native) JSON parser is somewhat
smaller than his K/V one.

Based on this and falling back to the IETF WG process as chair I would
conclude that there isn't enough consensus to make a change and that
we are staying with JSON.

I would prefer to have more opinions (implementors in particular) but
we are also going to get past this. In particular I would like to hear
from implementors who (like Victor) have a problem living with either
choice.

Please provide your feedback by EOB 1st of August.

	Cheers Leif

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 21 Jul 2017 13:39:08 +0200

> On Jul 21, 2017, at 1:10 PM, Leif Johansson <[email-masked]> wrote:
> 
> 

I don’t have an opinion on the two choices but in the past when I’ve needed to do JSON work in “C’, I’ve used this library which made it very painless.

https://github.com/DaveGamble/cJSON <https://github.com/DaveGamble/cJSON>

The license is very permissive (MIT) and the author even suggests just including two files cJSON.[ch] directly in your project if you wish.

Tom

---

From: Claus Assmann <[email-masked]>
Date: Fri, 21 Jul 2017 04:50:46 -0700

> I would prefer to have more opinions (implementors in particular) but

There's no way I would add JSON support to sendmail.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 21 Jul 2017 13:58:59 +0200

> There's no way I would add JSON support to sendmail.

Does that also mean you are ok with the current K/V proposal?

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 21 Jul 2017 12:59:51 +0100

> I would prefer to have more opinions (implementors in particular) but

There's no way I would add JSON support to exim.
-- 
Jeremy

---

From: Anders Berggren <[email-masked]>
Date: Fri, 21 Jul 2017 16:49:50 +0200

> On 21 Jul 2017, at 13:10, Leif Johansson <[email-masked]> wrote:
> ...

Although we (an MTA with a draft STS implementation) would prefer JSON (because it's an established web format), we don't have a problem with switching to the proposed K/V format.

---

From: "tom p." <[email-masked]>
Date: Fri, 21 Jul 2017 17:34:14 +0100

Leif

K/V

Not something that I would expect to implement but rather my views are
based on tracking the work of NETCONF and RESTCONF, the latter being
JSON.  I see the difficulties encounterd in the definition of RESTCONF
and am very clear that JSON as a language is incomplete and somewhat
loosely defined, sloppy even.  I do not see the availability of
libraries as affecting this - if the underlying technology is incomplete
and loosely defined, then what a library that implements just that
technology has to offer will perforce be incomplete and loosely
defiined.

K/V I find precise and unambiguous.

Tom Petch

----- Original Message -----
From: "Leif Johansson" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 21, 2017 12:10 PM
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Jul 2017 22:16:05 +0200

Hi Tom,

> On 21 Jul 2017, at 18:34, tom p. <[email-masked]> wrote:
> 
> Leif
> 
> K/V
> 
> loosely defined, sloppy even.

Without taking a position on K/V versa JSON: I thought draft-ietf-jsonbis-rfc7159bis-04 was fairly complete and can be implemented without relying on any other documents. Yes, there are some interesting corner cases, but I doubt they will affect MTA STS use.

>  I do not see the availability of

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 22 Jul 2017 07:53:12 +0000

> There's no way I would add JSON support to sendmail.

I'll chime in with no plans to add a JSON dependency to Postfix.
The current KV proposal is fine.  I would have avoided the
superfluous ":" characters after the keys:

	mx foo.example.com

rather than:

	mx: foo.example.com

but I don't care enough to make this an issue.  The authors are
free to drop the unnecessary ":" if they agree.

The K/V would then be a sequence of lines, with one K/V per line,
with each line of the form:

    <KEY><whitespace><VALUE><optional trailing whitespace><EOL>

<EOL> is whatever goes for EOL in HTTP text/plain content types,
which IIRC is <CRLF>.  Client implementations MAY be liberal and
also allow <LF>, but server implementations SHOULD only use <CRLF>.

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 22 Jul 2017 09:56:14 +0200

Thx for your feedback,

Keep the reviews coming - until next Monday when we'll close this issue.

Skickat från min iPhone

> 22 juli 2017 kl. 09:53 skrev Viktor Dukhovni <[email-masked]>:
>

---

From: "Dr. Pala" <[email-masked]>
Date: Sat, 22 Jul 2017 10:44:48 +0200

Hi all,

+1 for the K/V solution. Adding JSON dependencies does not seem a good 
idea to me too :-)

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 22 Jul 2017 11:14:56 +0200

Hi,
If we end up going the K/V route:

> On 22 Jul 2017, at 09:53, Viktor Dukhovni <[email-masked]> wrote:
> 

This has a nice property that I can reuse a generic header field parser.

> which IIRC is <CRLF>.

Yes.

>  Client implementations MAY be liberal and

No bare LF please, CRLF only.

Best Regards,
Alexey