100% agree. If this is the path we decide to go down, we can't really change the protocol for this. It's advice on when/why to deal with X in a particular way. Perhaps I was overly subtle, but that's why I described it as the practical effect. I didn't mean to suggest a protocol change.
Scott K On February 18, 2023 7:52:42 PM UTC, Barry Leiba <barryle...@computer.org> wrote: >I think that changing this to SHOULD is the wrong approach. An >Applicability Statement might well give advice, possibly at the SHOULD >level, that goes beyond this and discusses use cases, but the base >protocol uses MAY for a good reason, and at the protocol level it >should stay that way. > >Barry > >On Fri, Feb 17, 2023 at 8:02 PM Murray S. Kucherawy <superu...@gmail.com> >wrote: >> >> On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman <ietf-d...@kitterman.com> >> wrote: >>> >>> Currently RFC 6376 says, "Signatures MAY be considered invalid". I think >>> the practical effect as described in protocol terms would be to change the >>> MAY to SHOULD under X conditions and SHOULD NOT under !X conditions. Not >>> that I'd expect to see this appear in a protocol document (maybe some kind >>> of applicability statement). >> >> >> Beyond this SHOULD, I think we need to consider whether the caller needs to >> be told specifically when a failure occurs for this reason. Right now an >> implementation might return just a PERMFAIL without noting that it's because >> of "x=" versus the signature failing for some other reason. Should the >> caller be given this extra detail to enhance the decision tree, or will this >> just complicate things? >> >> I think, for instance, libopendkim does identify the reason for the failure, >> but I'm not sure whether any consumers of that API make use of that detail >> beyond maybe logging it. >> >> -MSK > >_______________________________________________ >Ietf-dkim mailing list >Ietf-dkim@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-dkim _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
