At 8:43 AM -0700 5/19/06, Michael Thomas wrote:
Paul Hoffman wrote:
At 7:50 PM -0700 5/18/06, Michael Thomas wrote:
I'm fine with this being a SHOULD , fwiw. I was just repeating the original
text that Tony proposed. The key here is that the receiver should know that
the sender prefers one over the other, and hence that's it's an
ordered list. A
receiver is always at liberty to feign igornance.
I don't see the interoperability or security issue that would make
this a SHOULD. The order given shows the signer's preference; the
verifier MAY do whatever it wants.
This seems to match up with the semantics of SHOULD if you ask me:
the receiver
should honor the senders wishes unless it has some overriding reason
why it doesn't
want to do that.
From RFC 2119:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
. . .
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
That rules out using SHOULD to enforce "senders wishes" unless there
is an interop or limit behavior that cause harm. If the latter is an
issue, the signer should not include a way for the verifier to cause
harm.
...which goes to show why having two different formats to say the
same thing is inherently flawed.
That assumes that the two are now and evermore identical. I don't think that's
a very good assumption, which is why SHOULD above makes sense.
Can you give an example of how you think the two might differ in light of:
If there are
multiple query mechanisms listed, the choice of query mechanism
MUST NOT change the interpretation of the signature.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html