> -----Original Message-----
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Hector Santos
> Sent: Thursday, May 05, 2011 9:41 PM
> To: dcroc...@bbiw.net
> Cc: ietf-dkim@mipassoc.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
