From: Stephen Farrell
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Hallam-Baker, Phillip wrote:
If you treat messages signed with an algorithm you do not
understand as policy violations you are going to reject
legitimate messages.
Since I don't agree that the premise applies, the rest is moot.
Your argument here is the exact opposite of that made by Jim. You are arguing
for the default to be one way, he is arguing for the default to be the other
way.
Uncovering this type of inconsistency is the purpose of a requirements document.
The outcome of DKIM + Policy is different, it is:
COMPLIANT - The message is in compliance with the
specified policy
NOT-COMPLIANT - The message is not in compliance with the
specified
policy
I think we could argue there, but you're delving into design
now, not requirements IMO.
Since when was the specification of Pre and Post conditions for a module not a
requirements issue?
I have raised a use case and a set of requirements that result from that use
case. That is a requirements issue.
Nobody has objected to the use case. The only argument advanced is that the
current spec meets the use case. This being the case the requirements should be
accepted into the draft.
When I raised the issue during base I was told to wait till policy. I raised
the issue then because I knew that if I did not raise it then I would be told
that I should have raised it in base.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html