Let me get this straight? You want to repeat all the header values on each row for each record? How is that better than XML?
CSV is just not a format that we can use here, it just isn't. I bet that there are people that would like the reports in D64 or MP3 format, but for obvious reasons that is just as unrealistic. Personally I would prefer JSON over XML, but I do not see a benefit to having multiple formats, and since we already have XML, I suggest we keep it that way. I don't think 'consumers' would want to read DMARC reports anyway. Reading DMARC reports is one thing, understanding them is something else. If a consumer is willing to read DMARC reports, and understands them, they would have no problem reading XML or converting them to something that fits their needs. --- Freddie -----Oorspronkelijk bericht----- Van: Hector Santos [mailto:hsan...@isdg.net] Verzonden: woensdag 20 mei 2020 22:01 Aan: dmarc@ietf.org Onderwerp: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? On 5/20/2020 2:43 PM, Alessandro Vesely wrote: > Transaction? I thought we were talking about aggregate reports. So am I. > There are no transactions there. Really? Each SMTP session can be considered a transaction. You are provided results on the these DMARC processed transaction. > I mean, what is the CSV format of the following report, that I sent > yesterday for this list: Sorry, if I ignored it. Forgetting fact that you can your report easier to read for consumers, these would be an example of the CSV field headers. CSV headers: report_metadata.org_name, report_metadata.email, report_metadata.report_id, report_metadata.date_range.begin, report_metadata.date_range.end Policy_Published.domain, Policy_Published.adkim, Policy_Published.aspf, Policy_Published.p record.row, record.row.source_ip.record.count. record.row.policy_evaluated, record.row.policy_evaluated.disposition, record.row,policy_evaluated.disposition, record.row.policy_evaluated.dkim, record.row.policy_evaluated.spf Note: You don't have to stick to redundant "name space" field names. >>> ... Can we get back to work, please? >> >> Sorry, but I consider a rude, disrespectful and ignorant statement, >> to be saying that. > > > No personal attack intended. I'm being rude because I have the > impression that you are not defending a concrete, well defined need, > but instead find new arguments opportunistically to pursue a vague sense of > format fashion. That's a personal attack. If you don't understand the proposal, you should back off or ask for clarification. > You > shifted from an asserted necessity of producers to a possible desire > of consumers. I did no such thing. I won't repeat it, but it appears you didn't understand the proposal. >Now you introduce formats like CSV which make no sense in DMARC >context. I disagree. See above. > I hold that CSV cannot satisfy DMARC requirements. Hold it all you want. You know it would not be true. See above. ? Please do contradict me by > showing us how an aggregate report in CSV would look like, as well as > some ideas for defining the corresponding template, similar to what > Appendix C of RFC 7489 specifies for XML. Ok, I won't but if you don't understand the proposal, you should ask for clarification. CSV can work, so can JSON. Limiting it and locking it down to XML only would be a limitation. You can agree or not agree with that. -- HLS _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
