Yeah, I'm not particularly picky on the solution as long as we agree on a solution that works. I believe that parameter usage is pretty rare in the wild right now, so I think we have time to come to a consensus about what the right behavior is, and document it via fixing examples or errata or whatever *before* the problems that Ilari rightly points out bite us in practice.
There is a precedent for putting approved errata directly into the BRs to avoid "diversity of interpretations", which generally causes problems. I'd prefer to not have to be liberal on expectations, and indeed would support policy proposal at CABF to require rejection and non-issuance in the case of non-compliant or ambiguous CAA tags. It's safer. -Tim > -----Original Message----- > From: Acme [mailto:[email protected]] On Behalf Of Salz, Rich > Sent: Tuesday, July 17, 2018 11:39 AM > To: Ilari Liusvaara <[email protected]> > Cc: [email protected]; Roland Shoemaker <[email protected]> > Subject: Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for > ACME-CAA discussion at 102) > > > - Change reference to RFC6844bis. > > A standards-track document cannot reference a draft. So either we wait, or'm > we wait for an errata to be written and accepted, or we do this: > > > - Fix examples (and other text) to be consistent with the RFC6844 > grammar (which pretty obviously splits on space/tab according to > the grammar). > > We could also add text saying "be liberal in what you expect" as the > community is migrating, I suppose. > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
