-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Thursday, May 05, 2011 9:41 PM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
This approach you have is an implementation conclusion. It is not
part of the protocol. The protocol clearly says in 3.11:
Upon successfully verifying the signature, a receive-side DKIM
verifier MUST communicate the Signing Domain Identifier (d=) to a
consuming Identity Assessor module and MAY communicate the Agent or
User Identifier (i=) if present.
Therefore with no subjective consideration, no assertions, no
philosophies, the protocol defines a process model of:
trust = TrustIdentityAssessor(SDID [,AUID])
There is NO opinion about this! That is your DKIM Trust Protocol Model
with a Mandatory SDID input and an optional AUID input.
Actually, using your notation, it's:
trust = TrustIdentityAssessor(SDID[, AUID[, s=[, t=[, l=[, x=[, ...]]]]]])
How far do we really need to go here?
In order for this to work, your 3.9 Output Requirement MUST expose
those two parameters at the very least.
By saying "MAY ... other", I maintain that it already does.
To be consistent you have three protocol design tech writing choices:
1) Remove the second clause in that 3.11 3rd paragraph - problem fixed.
2) Add AUID to 3.9 as an optional output
3) Remove section 3.9
...or the solution I'm beginning to like:
4) Alter 3.11 to match 3.9.
This is what happens when you add something in the last minute without
any consensus. It was just added - no consensus.
After a short scan of the tracker item (#22) and the discussion thread, I found
three people worked on the specific text and at least five (including those
three) said they liked the result, versus one or two that disagreed. That
sounded like rough consensus to me and we were still within the WGLC deadline,
so I incorporated the change.
Again, the Chair has the final say.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html