There appears to be broad consensus in the group that there is no need for JSON output from aggregate reports, except for one argument that the additional flexibility of allowing JSON would be good for those who work in Javascript. But I haven't heard any group specifically identified that would want to use this.
Can anyone raise their hand, or bring someone to the table, who has a working DMARC implementation that would be improved by a standards track documents which includes JSON support, or has not implemented DMARC solely due to lack of JSON support? Short this, I'll call rough consensus that DMARCbis need not support JSON. Seth, as Chair On Wed, May 20, 2020 at 1:06 PM Scott Kitterman <skl...@kitterman.com> wrote: > > > On May 20, 2020 8:00:34 PM UTC, Hector Santos <hsantos= > 40isdg....@dmarc.ietf.org> wrote: > > > >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. > > Not requiring RFC 1149 support is also a limitation, but I'm fine with > that. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
