IMO the main hurdle with key-value format is that we do not have a standard
format, and by extension off-the-shelf library support. So the question is -
whether to write custom kv parsers or use a standard format - JSON.
Thanks,-binu
From: Daniel Margolis <[email protected]>
To: [email protected]
Sent: Sunday, 23 April 2017 5:48 AM
Subject: Re: [Uta] smtp-sts-04 JSON
In the interests of not looking like I'm ignoring your mail, just to reiterate,
I have no personal feeling about this. My read at the meeting in Chicago was
that consensus was not totally obvious, but I'm really happy to defer to the
chairs here on what the consensus seems to be or how to unblock this.
As I have said before, while this is certainly an issue people have
legitimately strong feelings about, it's not really a fundamental issue, and,
speaking personally (and I think for the other authors), I would be happy with
any resolution in any direction--the main point here is to provide some
additional security to email-in-transit, not to provide security to
email-in-transit by leveraging JSON. ;)
Dan
On Sun, Apr 23, 2017 at 4:58 AM, Viktor Dukhovni <[email protected]> wrote:
> On Apr 22, 2017, at 1:35 PM, Daniel Margolis <[email protected]> wrote:
>
> That does not jive with relatively easy to parse...
>
> JSON supports comments, elements that are integers, strings,
> arrays or associative arrays (nested JSON objects). JSON
> strings are UTF-8 and allow embedded NUL octets.
>
> Your JSON reference is to the obsolete RFC4627, the non-obsolete
> reference is RFC7159.
So any compelling arguments for JSON from MTA implementors?
A much simpler format would be a block of lines (CRLF terminated),
with each line either a boolean propery name, or a name value pair.
version STSv1
mode report
max_age 8640000
mx mx1.example.com
mx mx2.example.com
...
Line length is limited to the usual 1000 bytes including the
terminating CRLF.
This simplifies parsing, because a simple line-orienter parser
can now process the entire policy. It is no longer possible
to have multiple policies, as with JSON, because there is no
way to express multiple objects. The JSON format is much
too general for the needs at hand.
--
Viktor.
______________________________ _________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/ listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
