[dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

https://trac.ietf.org/trac/dmarc/ticket/69 Aggregate reports are only sent in XML format. There's been some discussion (that's also related to https://trac.ietf.org/trac/dmarc/ticket/42 about expanding reporting functionality beyond mailto:), of adding additional reporting formats, specifically JS

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Friday, May 15, 2020 2:26:32 PM EDT Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/69 > > Aggregate reports are only sent in XML format. There's been some discussion > (that's also related to https://trac.ietf.org/trac/dmarc/ticket/42 about > expanding reporting functionality beyon

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Fri, May 15, 2020 at 1:16 PM Scott Kitterman wrote: > If this were a green field effort and we were trying to decide on a report > format, I would probably think JSON was a great choice, but it's not. > Trying > to support multiple formats is going to be a lot of work for little to no > real >

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 5/15/2020 3:09 PM, Murray S. Kucherawy wrote: +1, unless there are known cases where the XML payload size is a problem that switching to JSON would solve. For any interesting specification, there are many ways to improve it.  The question is whether the improvement is worth the effort. S

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

In article you write: >-=-=-=-=-=- >Should we consider adding JSON formatting to DMARC? What Scott said, no. Report processors will always have to be able to decode the existing XML so adding more options just adds more complexity with no more function. Apropos ticket #29 we might consider resu

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

In article you write: >+1, unless there are known cases where the XML payload size is a problem >that switching to JSON would solve. It's gzipped, do I doubt it would make much difference. Gzip is really good at compressing the boilerplate strings that make XML bigger than JSON. Also, FWIW, in

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 5/15/2020 2:26 PM, Seth Blank wrote: Should we consider adding JSON formatting to DMARC? Protocols should be flexible. Adding it doesn't mean replace. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 5/15/2020 9:54 PM, Hector Santos wrote: Protocols should be flexible. Adding it doesn't mean replace. Explain the need. Convince plenty of folk that it is necessary enough that they are inclined to write the code, deploy it, and use it.  Adding things is expensive. Flexibility that does

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Fri 15/May/2020 20:26:32 +0200 Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/69 > > Aggregate reports are only sent in XML format. There's been some discussion > (that's also related to https://trac.ietf.org/trac/dmarc/ticket/42 about > expanding reporting functionality beyond mai

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 2020-05-16 11:38, Alessandro Vesely wrote: Please let's not even air such hypothesies. There is still people who send zip rather than gzip... and still people that does not use sid-milter, opendkim, openarc, opendmarc, all of them wait for software updates or precompiled problems to be

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 15 May 2020, at 23:54, Hector Santos wrote: On 5/15/2020 2:26 PM, Seth Blank wrote: Should we consider adding JSON formatting to DMARC? Protocols should be flexible. Adding it doesn't mean replace. Flexible sometimes means less interoperable. You've already got to get the XML right. Adding

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 5/16/2020 11:49 AM, Pete Resnick wrote: On 15 May 2020, at 23:54, Hector Santos wrote: On 5/15/2020 2:26 PM, Seth Blank wrote: Should we consider adding JSON formatting to DMARC? Protocols should be flexible. Adding it doesn't mean replace. Flexible sometimes means less interoperable. You'

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 5/16/2020 2:41 AM, Dave Crocker wrote: On 5/15/2020 9:54 PM, Hector Santos wrote: Protocols should be flexible. Adding it doesn't mean replace. Explain the need. Convince plenty of folk that it is necessary enough that they are inclined to write the code, deploy it, and use it. Adding thi

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Fri, May 15, 2020 at 7:20 PM John Levine wrote: > In article < > cal0qlwaskzdyeqnjs-bj4ttfdgevfc8gaukmvnost0wj3ge...@mail.gmail.com> you > write: > >+1, unless there are known cases where the XML payload size is a problem > >that switching to JSON would solve. > > It's gzipped, do I doubt it w

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

Hatless, as a data point: at Valimail we see reports that are hundreds of megabytes in size, and sometimes push close to a gigabyte. These reports continue to increase in size month over month as sending volume, geographic footprint, deployed third party services, and fraudulent mail attempting to

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 05/15/2020 11:26, Seth Blank wrote: https://trac.ietf.org/trac/dmarc/ticket/69 Aggregate reports are only sent in XML format. There's been some discussion (that's also related to https://trac.ietf.org/trac/dmarc/ticket/42 about expanding reporting functionality beyond mailto:), of adding a

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 05/15/2020 13:16, Scott Kitterman wrote: When there is only one report format, there's no need to discover a common format between report senders and report receivers. As soon as there are two, then to be interoperable, then either both report formats are required or there has to be some kin

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Sat 16/May/2020 20:45:43 +0200 Seth Blank wrote: > On Fri, May 15, 2020 at 7:20 PM John Levine wrote: >> In article >> you >> write: >>> +1, unless there are known cases where the XML payload size is a problem >>> that switching to JSON would solve. >> >> It's gzipped, do I doubt it would ma

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Sat 16/May/2020 19:48:25 +0200 Hector Santos wrote: > > One can suggest XML is also complex to get right. The direction has been with > JSON for a number of years, especially with the JavaScript developers using > established tools and platforms based JSON. The APIs are readily available. Yet

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 2020-05-18 10:27, Alessandro Vesely wrote: Best Ale -- could you remove empty lines in your signature ? lets see dmarc fail, dkim invalid test in spamassassin ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Mon, May 18, 2020 at 1:31 PM John Levine wrote: > There are vast numbers of sites producing and consuming XML reports. > They interoperate. It works. There is no problem to be solved here. > Can we stop now and work on something else? > The working group's consensus appears to be that aggrega

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 5/18/2020 8:25 PM, Seth Blank wrote: On Mon, May 18, 2020 at 1:31 PM John Levine mailto:jo...@taugh.com>> wrote: There are vast numbers of sites producing and consuming XML reports. They interoperate. It works. There is no problem to be solved here. Can we stop now and work on som

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On May 20, 2020 12:23:37 AM UTC, Hector Santos wrote: >On 5/18/2020 8:25 PM, Seth Blank wrote: >> On Mon, May 18, 2020 at 1:31 PM John Levine > > wrote: >> >> There are vast numbers of sites producing and consuming XML >reports. >> They interoperate. It works. T

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 5/19/2020 8:46 PM, Scott Kitterman wrote: Please don't. This is a large stack of protocol and implementation complexity for little or no gain. Rhetorically, I feel the same about reporting. What is gained from it? But that is just my opinion since the proposed ideas for reporting cam

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Wednesday, May 20, 2020 8:49:13 AM EDT Hector Santos wrote: > On 5/19/2020 8:46 PM, Scott Kitterman wrote: > > Please don't. This is a large stack of protocol and implementation > > complexity for little or no gain. > Rhetorically, I feel the same about reporting. What is gained from > it? Bu

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Fri, May 15, 2020 at 6:14 PM John Levine wrote: > In article zmn0oxmgns0cspywu58hqlaw7wvvbh1442yu4e...@mail.gmail.com> you write: > >-=-=-=-=-=- > >Should we consider adding JSON formatting to DMARC? > > What Scott said, no. Report processors will always have to be able to > decode the existi

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 5/20/2020 8:29 AM, Kurt Andersen (b) wrote: Agree 100% This looks like it has a strong constituency against the proposal, a much smaller constituency in favor of it, and little or no offered benefit.  Yes? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net __

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 5/20/2020 10:01 AM, Scott Kitterman wrote: So, from a product design standpoint, for immediate consumer "pay off," at the very least, csv should be the default option, not XML. You're several years too late on deciding a default. DMARC is informational, not a proposed standard. My confuse

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 2020-05-20 17:49, Dave Crocker wrote: This looks like it has a strong constituency against the proposal, a much smaller constituency in favor of it, and little or no offered benefit.  Yes? if the mouse have 2 holes to select from, it will be 50% fails in 50% reports, this is why postfix ke

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On 5/20/2020 11:49 AM, Dave Crocker wrote: On 5/20/2020 8:29 AM, Kurt Andersen (b) wrote: Agree 100% This looks like it has a strong constituency against the proposal, a much smaller constituency in favor of it, and little or no offered benefit. Yes? Just like DKIM Policy had a "strong con

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

Thanks Scoot, I hope all is safe for you and family. argg sorry about that, Scott. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Wed 20/May/2020 14:49:13 +0200 Hector Santos wrote: > On 5/19/2020 8:46 PM, Scott Kitterman wrote: >> >> Please don't.  This is a large stack of protocol and implementation >> complexity for little or no gain. >> > > Rhetorically, I feel the same about reporting.  What is gained from it?  But >

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

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.

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Wed 20/May/2020 18:51:32 +0200 Hector Santos wrote: > On 5/20/2020 12:26 PM, Alessandro Vesely wrote: >> >> 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 f

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 mea

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On May 20, 2020 8:00:34 PM UTC, Hector Santos 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 ar

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

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 wa

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

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 transact

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

On Wed 20/May/2020 22:00:34 +0200 Hector Santos wrote: > On 5/20/2020 2:43 PM, Alessandro Vesely wrote: > >> 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

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

As Chair, I'm closing ticket #69 and recording consensus as remaining with XML for report formatting. This consensus may be revisited if https://trac.ietf.org/trac/dmarc/ticket/42 opens a new reporting mechanism for which JSON is optimal, but the group's current consensus is that even in that case

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? No.

In article <492288f0-3fc3-f85e-26c0-eda418de6...@tana.it> you write: >Since receivers have to verify report correctness and trustworthiness, /they/ >deserve the right to decide what language they want reports to be written in. There is lots of freely available code to parse DMARC XML reports and p