Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Matthäus Wander <[e-mail]>]

ARC shows the need for extension data within <record> elements:
<https://datatracker.ietf.org/doc/html/rfc8617#section-7.2.2>

Example from RFC 8617:
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
   <type>local_policy</type>
   <comment>arc=pass as[2].d=d2.example as[2].s=s2
	as[1].d=d1.example as[1].s=s3
	remote-ip[1]=2001:DB8::1A</comment>
  </reason>
</policy_evaluated>

With proper extension support, this example could look like this:
<row>
   <policy_evaluated>
     <disposition>none</disposition>
     <dkim>fail</dkim>
     <spf>fail</spf>
     <reason>
       <type>extension</type>
       <comment>arc=pass</comment>
     </reason>
   </policy_evaluated>
</row>
<auth_results>...</auth_results>
<extensions>
   <arc xmlns="(...)">
     <result>pass</result>
     <sets>
       <as>
         <instance>2</instance>
         <domain>d2.example</domain>
         <selector>s2</domain>
       </as>
       <as>
         <instance>1</instance>
         <domain>d1.example</domain>
         <selector>s3</domain>
         <remote_ip>2001:DB8::1A</remote_ip>
       </as>
     </sets>
   </arc>
</extensions>

An IANA registry could serve as repository of IETF-approved extensions.

It's worth considering whether certain elements should be defined as 
extensible. In the above example, the <arc> element could be placed 
below <auth_results> next to the existing <dkim> and <spf> elements. 
Implementations support this behavior by simply ignoring unknown 
elements. XML Schema supports extensibility in well-defined places with 
the <xsd:any> element.

Regards,
Matt