I agree with Alessandro's suggestions, and really like the flexibility of
self-labeled elements so they can be located where appropriate rather than
forcing all extensions into a single bucket.
My $0.02,
Trent
On 6/4/21, 3:27 AM, "dmarc on behalf of Alessandro Vesely"
<dmarc-boun...@ietf.org on behalf of ves...@tana.it> wrote:
On Thu 03/Jun/2021 14:47:21 +0200 Brotman, Alex wrote:
>
> During our interim call last week the topic of extensions within the
DMARC aggregate report came up. There was a discussion about how to best
introduce these, but also how they might be best used. I noted three cases
that I could see today; ARC, PSD, and BIMI. And indeed we have tickets
relating to the first two. The original thought was that the aggregate draft
would allow a place for extensions, and then additional drafts would define
those within the IETF. When -02 was originally being worked on, there was a
thread about how we might like to see this, though not many responses. The
result is in section 4 of the -02 draft [1].
I have some comments about that attempt. First, it shows extensions right
below <feedback>, while it seems more useful to have them as child of <record>.
Second, I'm not sure we need an <extensions> container. I'd go for an example
like, say, so:
<feedback
xmlns="https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/dmarc-xml/1.0__;!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKqvwSJvF$
">
<report_metadata>
...
</report_metadata>
<policy_published>
...
</policy_published>
<extension_metadata name="bimi"
xmlns="https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?*1.0__;Lw!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKvQ2pQn-$
">
...
</extension_metadata>
<record>
<row>
...
</row>
<identifiers>
...
</identifiers>
<auth_results>
...
</auth_results>
...
<extension name="bimi"
xmlns="https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?**A1.0__;Py8!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKtkFNC6p$
">
...
</extension>
</record>
<record>
...
</record>
</feedback>
Third, we need to grasp how XML grammars can be composed, and insert it in
Appendix A.
> At the time, I didn't intend to limit the extensions to IETF-approved
extensions, though wasn't sure how else this might be used by reporting
entities (I mentioned domain reputation-ish things during the call). I'd
consider that if we don't enforce IETF-registered extensions, the receivers
could still ignore extensions they don't want to handle.
I assume no one reads the XML directly, except for debugging. If report
consumers don't know about an extension, its content will never reach human
eyeballs. Extension existence will have to be advertised, and a IANA page
could be a decent means of doing that.
> I'm also aware this could bloat a report in terms of size, though we've
already indicated we don't seem overly concerned with the size of the XML body.
A few things I'd like to see the group reach consensus on are:
>
> 1) Extensions in their own section (as it is now) or within each <row>
element
Both, and both optional. An extension can have some data to add in some
<record>, but not necessarily in all of them.
> 2) Must extensions be IETF-approved
We cannot stop non-registered extensions. Yet, developers may want to see
an RFC before implementing code that extracts a given extension's content.
> 3) If (2) is true, do we want to define any during the DMARCbis process
(essentially a demonstration of how it is to be done)
It would be a good way to show how to define them. Not our primary task,
though.
Best
Ale
--
> 1:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02*section-4__;Iw!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKtSg8JaH$
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKn_Uzf5Y$
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
