Subject: [Uta] json vs kv in draft-ietf-uta-mta-sts

From: Leif Johansson <[email-masked]>
Date: Thu, 29 Jun 2017 00:45:10 +0200

This issue has been dragging out for too long and I'm party to blame
for that. In Chicago there was a discussion about the relative merits
of json vs key-value (kv) format in draft-ietf-uta-mta-sts. The current
draft specifies json and since this is a WG draft we require WG
consensus to change it to something else. In Chicago the room was
roughly split on the issue. This however means there is currently /no/
consensus for changing json to kv (or anything else for that matter).

There is also no clear alternative text on the table. In order to get
to a conclusion on this draft we'll do the following: If anyone wants
to argue for kv (or anything else) please present either a draft or
a PR in github against the current draft so we have something to
discuss. If the chairs don't see either of those two materialize
before Prague we'll do a WGLC by Prague on draft-ietf-uta-mta-sts-06
as is which means sticking with json.

	Cheers Leif

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Jun 2017 23:54:23 +0100

On 28/06/17 23:45, Leif Johansson wrote:
> sticking with json

FWIW, as a non-implementer who has chatted with folks
currently implementing sts, I think json is good enough.

While I understand and sympathise with Viktor's argument
for kv, I don't think that argument ought be blocking as
the differences seem to me to mostly relate to the sets
of libraries already linked to mta implementations, which
doesn't seem to me like a winning argument, as ymmv.

Which is maybe just a long-winded way of agreeing with you
WG chairs :-)

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 29 Jun 2017 09:02:53 -0400

> On Jun 28, 2017, at 6:54 PM, Stephen Farrell <[email-masked]> wrote:
> 

The point is not so much about this or that library, but about
needless complexity and bloat.  JSON, XML, ASN.1, ... are much
too general and complex for the task at hand.

Good engineering is about making things as simple as possible
(and no simpler), and JSON fails the test.  It is, and remains,
entirely unnecessary for STS.

BTW, I did suggest a few candidate KV encodings upthread.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Jun 2017 14:23:58 +0100

Hiya,

> too general and complex for the task at hand.

The library point is relevant because some people
will already have json support, at which point there
is no additional complexity, for them. (That said, I've
always been neutral in religious debates about data
definition language fashions, but do realise that a
lot of people have much stronger feelings. In any
case, the use of terms like "bloat" etc doesn't
convince me of anything:-)

> entirely unnecessary for STS.

I don't see any new argument there. In fact, it
seems like a pretty old, worn out and overly generic
argument to me;-)

> BTW, I did suggest a few candidate KV encodings upthread.

Given that it seems nobody else is jumping on board
with that, maybe now it's time to just move on?

Having spoken with the folks behind this spec, I am
very sure that above all else they want to get done
and are finding the lack of closure on this particular
aspect very very frustrating. And all the moreso as
they would've happily used kv if that were the clear
consensus. As-is, they have come and some deployment
with the json stuff (IIUC), so ISTM that in the
absence of any spec'd out alternative the right thing
for the WG to do is clear. (Even if it's a pity that
that right thing is not what you'd chose for postfix.)

Cheers,
S.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 29 Jun 2017 22:27:25 +0200

> BTW, I did suggest a few candidate KV encodings upthread.

Please format one of them as a PR against the current draft
so we have something concrete to evaluate.