On Thu, Nov 23, 2017 at 5:39 AM, Seth Blank <s...@sethblank.com> wrote:
> Bumping this, too. All items below are still open. > > On Fri, Oct 6, 2017 at 8:27 PM, Seth Blank <s...@sethblank.com> wrote: > >> Questions 1, 2, and 4 as they relate to the text I suggested are still >> open - and I don't believe the text that was pulled into -09 is correct >> until these questions are answered. >> >> On Tue, Sep 5, 2017 at 5:52 PM, Seth Blank <s...@sethblank.com> wrote: >> >>> <elided> >>> >>> Open questions: >>> >>> 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 >>> >> Has there been any traction on the idea of modifying 7601 to implement this partitioning (bis)? Or should we bake in our own "hotwire" of the existing spec? --Kurt
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
