To summarize,

We'd like to see extensions available both below the "feedback" and "record" 
elements.  The -02 draft only has it below the "feedback" element.  I agree 
that all elements, each time they are utilized, should mention a reference as 
to how they are to be utilized.

We'd also like to have extensions go through an IETF process, however, we also 
understand that we cannot exclude third parties from defining/deploying their 
own extensions.  I suppose we could tell report receivers they "MUST" ignore 
any extensions which are not IETF-approved, though that seems a bit 
heavy-handed.

So, a sample report may look something like:

   <feedback>
     <version>2.0</version>
     <report_metadata>
       <version>2</version>
       <org_name>Sample Reporter</org_name>
       <email>report_sen...@example-reporter.com</email>
       <extra_contact_info>...</export_contact_info>
       <report_id>3v98abbp8ya9n3va8yr8oa3ya</report_id>
       <date_range>
         <begin>161212415</begin>
         <end>161221511</end>
       </date_range>
     </report_metadata>
     <policy_published>
       <domain>example.com</domain>
       <p>quarantine</p>
       <sp>none</sp>
       <pct>100</pct>
     </policy_published>
     <record>
       <row>
         <source_ip>192.168.4.4</source_ip>
         <count>123</count>
         <policy_evaluated>
           <disposition>quarantine</disposition>
           <dkim>pass</dkim>
           <spf>fail</spf>
         </policy_evaluated>
       </row>
       <identifiers>
         <header_from>example.com</header_from>
       </identifiers>
       <auth_results>
         <dkim>
           <domain>example.com</domain>
           <result>pass</result>
           <selector>abc123</selector>
         </dkim>
         <spf>
           <domain>example.com>
           <result>fail</result>
         </spf>
       </auth_results>
        <extensions>
          <extension_name definition="url">
             .........
          </extension_name>
       </extensions>
     </record>
    <extensions>
       <extension_name definition="url">
        ....
       </extension_name>
    </extensions>
   </feedback>

The goal being to allow extensions to live either at the reported-IP level, or 
at the domain level.

Does this seem reasonable?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Matthäus Wander
> Sent: Saturday, June 5, 2021 7:56 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback
> Requested
>
> Alessandro Vesely wrote on 2021-06-04 11:26:
> > Second, I'm not sure we need an <extensions> container.
> > I'd go for an example like, say, so:
> >
> > [...]
> >     <extension_metadata name="bimi"
> > xmlns="http://ietf.org/xml-namesapaces/bimi-xml?/1.0";>
>  > [...]
> >        <extension name="bimi"
> > xmlns="http://ietf.org/xml-namesapaces/bimi-xml??/1.0";>
>
> If we use an attribute for the extension name, then we don't the container
> section.
> As the current schema does not use attributes at all, I'm more inclined to 
> define
> the extension name in a different way for consistent non-use of attributes. 
> But
> that's a minor detail.
>
> >> 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.
>
> +1
>
> Regards,
> Matt

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to