Dave CROCKER wrote:
>>> I don't think this is correct. The signer creates and signs the i= value,
>>> so it's not "garbage",
> ....
>> By "garbage", I mean "not guaranteed to have any useful meaning".
> ....
>> So, I believe, it's essentially meaningless as far as the protocol can
>> stipulate. Assertions of its semantics thus fall outside of the base DKIM
>> spec.
>
> It's worth noting that Murray said 'could be'.
>
> But Murray's final paragraph has the essential points: within the scope of the
> DKIM Signing specification, the receive-side has no way to determine what the
> semantics of i= are, as we discussed at great length when formulating the
> Update
> RFC.
>
> But, then, folks on the list already know that.
"We have here is a failure to communicate." - Cool Hand Luke
Dave,
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.
In order for this to work, your 3.9 Output Requirement MUST expose
those two parameters at the very least. There is no assertions or
opinions - thats the protocol you defined.
Now, when you begin to exclude it, then you mixing up implementation
desires with subjective conclusion that really is not part of the
protocol defined. There is some subjective information notes about
the value, but that has nothing to do with the protocol you defined.
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
This is what happens when you add something in the last minute without
any consensus. It was just added - no consensus.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
