> 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
