On 5/20/2020 12:26 PM, Alessandro Vesely wrote:
I agree we should consider ways to increase the report generators base, but
requiring support for multiple formats goes in exactly the opposite direction.
Although automatic converters exist, having to provide multiple formats can be
a showstopper.
I don't agree this would be show-stopper. Not after all the work that
has to be done
to move from Draft Informational status RFC to DMARC proposed standard
RFC.
Its not complicated at all.
The proposal is to offer a new optional "prf=" tag that provides a
preferred reporting format where the verifier MAY implement (NOT MUST)
and provide to consumers. I would say SHOULD but MAY is fine.
Hector, what are you talking about?
hhmmm, I don't known any other way of describing this simple concept.
Can you show us how does a CSV report look like?
Like a standard format for CSV:
line #1, name of fields, separated by a comma
line #2, transaction #1 values separated by comma
..
..
..
Line #N, transaction #N-1 values separated by comma
A standard csv layout. Most if not all table like "tools" like a
spreadsheet or SQL, support a CSV import, maybe a XML import and if
you are lucky, the JSON format. But XML is older than JSON so you may
see CSV and XML with older tools. But relatively soon, JSON will be
the more common comm I/O technique.
XML, like JSON, support complex template schemata. CSV templates require fixed
columns. I doubt you're talking seriously if you make such claims.
It is possible to have XML and JSON represented in a table-like flat
name space with multiple columns.
Yes, and I am Catherine Deneuve...
Who?
... Can we get back to work, please?
Sorry, but I consider a rude, disrespectful and ignorant statement, to
be saying that.
We are working. If you don't agree or lack the ability to support
anything XML but others can, you should note it and but also not push
your limitations on others.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
