Given that this work is specificall for the benefit of DMARC/ARC, it
makes sense to me to do the work on this list/in this group.
Ned
> On Fri, Jan 19, 2018 at 10:49 AM, Dave Crocker <[email protected]> wrote:
> > On 1/18/2018 11:14 PM, Murray S. Kucherawy wrote:
> >
> >> -01 will be up soon, incorporating the suggested changes in prose and
> >> ABNF discussed previously on this list.
> >>
> >
> >
> > If I missed this, I apologize, but would it be possible to post a message
> > which summarizes the nature/goals of the changes that are planned?
> >
> > I'm not challenging the work, but just wanting to make sure the wg is in
> > synch about how the doc should be adjusted.
> >
> > Thanks.
> >
> > d/
> The intent is outlined in high level within the -10 version (section 5.2)
> of the protocol doc. The better explanation is in Seth's email from
> September (
> https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0):
> 1) The optimal ABNF for AAR would inherit the A-R payload ABNF from 7601.
> Unfortunately, authres-header was defined in a way that makes this
> difficult. Is there a better way to say that the AAR inherits the A-R
> payload, and if anything modifies the definition of authres-header in 7601,
> the AAR also needs to inherit this change?
> To be super specific, this is the current authres-header ABNF from 7601:
> authres-header = "Authentication-Results:" [CFWS] authserv-id
> [ CFWS authres-version ]
> ( no-result / 1*resinfo ) [CFWS] CRLF
> Optimally, there would be:
> authres-payload = [CFWS] authserv-id
> [ CFWS authres-version ]
> ( no-result / 1*resinfo ) [CFWS] CRLF
> And then we could have:
> arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
> authres-payload
> --Kurt
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
