On Sun 29/Dec/2024 01:13:59 +0100 Daniel K. wrote:
On 12/16/24 09:51, Alessandro Vesely wrote:
That's notable and neatly structured. Perhaps /Must contain/'s can be slashes.
Thank you for your input.
I think you meant that it could be wrapped in underscores to be rendered
as italicized, but that only works in the HTML version, and looks messy
in the plain text version.
I opted to remove the words, but feel free to explain better what you
meant if I misunderstood and you want me to try something in particular.
Removing was exactly what I meant. Sorry for the confusion.
There are still several "must contain", though. In particular, mind "A single
report MUST contain data for one policy configuration.", which has changed.
Would a table help to further reduce the "A begat B; B begat C" effect?
Consider https://en.wikipedia.org/wiki/DMARC#Aggregate_reports
I may not fully have caught on here, and how to fix it. The nature of
describing XML in element order necessitates a bit of repetition.
I've experimented quite a bit the previous weeks, and I've prepared a
new render with a few variations.
https://ietf.vendo.no/draft-ietf-dmarc-aggregate-reporting-variants.txt
There's also an HTML version - change the extension if you want to see it.
Curiously, the list version looks nicer in txt than html. The table version is
not the kind of table I meant, but I like it.
Perhaps somewhere we should say that "count" is the only non-key field.
3.1.1.1. Prose version - must contain removed
Basically the same as before, but with the 'Must contain' introduction
removed. That wording certainly got a bit repetitive.
3.1.1.2. Multiple tables version
This is the one I like better. It allows each table to be furnished with
comments common to various fields, e.g. the begin and end ind date_range.
Possibly, each table could be moved to the specific section; for example, (the
remaining part of) Handling Domains in Reports could stay together with the
identifier table.
3.1.1.3. Single table version
3.1.1.4. Single table version 2
The single table versions differ in how they communicate the level or
depth of the element in the XML hierarchy.
As you can see, I've tried a few things, but I think all of the table
variants suffer from the restrictions of tables when it comes to
formatting the details or nuances we describe for a particular element.
Especially 'record' and 'reason' seem to suffer.
OTOH, the REQUIRED/ OPTIONAL column is better recognizable. We could give up
capital case in the table versions, and replace those values with yes/no.
At the end of 3.1.1.3, there's a few paragraphs that did not quite fit
in a particular place in the table. I don't think it fits perfectly at
the end either.
They may make better sense in the multiple tables version.
The tables also lose information on where the order of elements is
mandated by the XSD. There's no room for more columns to describe it.
I suggest we abandon the table-version, as I don't know how it can be
changed to work out.
Hm... How about keeping both?
Best
Ale
--
_______________________________________________
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org
