I don't have a legalistic definition of interoperability; I want
implementations to, you know, interoperate. When I sign and send a
message, it'd be nice if I could expect recipients to interpret the
signature consistently. If assessors are likely to do inconsistent
things with parts of the signature, if I want my mail to work, I'd better
avoid those parts.
So you are indeed trying to make predictions or assertions about assessors. I
don't think that's possible in any context. The best you can do is make
assertions about verifiers, because then you can at least claim that a deviant
verifier is non-compliant. There's no such thing as compliance when it comes
to assessors since they don't have to follow any particular rules.
Your point about some assessors requring a signed subject is a good
example. It tells me that 4871 section 5.4 is underspecified, and
4871bis should strengthen it to say that you MUST sign the headers that every
message is supposed to have.
Subject: isn't a mandatory header per RFC5322, if you're using that as a
specific example. I think Alt-N's implementation was the first to have as an
option the ability to require that it be signed for a signature to be
considered acceptable, and the basis for that was the notion that it's almost
always a displayed header field.
So it depends on what you mean by "supposed to have". If RFC4871bis says
Subject: MUST be signed, we need to make sure we say why (i.e. "it's usually a
display header") because it would otherwise appear to contradict RFC5322.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html