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
