Stephen Farrell wrote: > I don't believe this discussion is necessary in order to progress the ADSP > draft, which, for better or worse, is where the WG's rough consensus ended > up.
Stephen, Happily, a community learns things about specifications as time progresses. Sometimes that learning uncovers problems and the problems get resolved. For example, that's was RFC Errata are for. In the current case, this is a rather fundamental and persistent confusion in the community about DKIM's "output". The Signing specification states: > 1. Introduction > > DomainKeys Identified Mail (DKIM) defines a mechanism ... > permitting a signing domain to claim > responsibility ... > Message recipients can ... confirm that the > message was attested to by a party in possession of the private key for the > signing domain. and > 1.1 Signing Identity > > DKIM separates the question of the identity of the signer of the message from > the purported author of the message. In particular, a signature includes the > identity of the signer. Verifiers can use the signing information to decide > how they want to process the message. The signing identity is included as > part of the signature header field This language declares that the result of a DKIM verification is an identifier that declares some responsibility. The question, now, is which string represents that identifier? The fact that there are serious, knowledgeable folk who declare it is the d= tag and other, equally serious and knowledgeable folk who declare that it is the i= tag, and that there are substantial numbers of each means that we have a real and basic problem: The community does not currently have consensus about where to find the one value that is DKIM's output! This is not something that can get resolved by fiat, Steve, such as saying that a prior decision by the working group resolves the matter. And it is not something that gets resolved by one or another person pointing to some other language in the Signing spec and declaring that it provides the one true answer. If the real world has competing interpretations of the spec, then the spec will not be used in a consistent matter. And it's difficult to find a more serious problem with a specification, since it means that the core semantic has ambiguous interpretation. What we are seeing, now, is that work on ADSP is (again) surfacing this basic confusion. Approving ADSP, in the absence of resolving this basic confusion about what value to use, merely entrenches the confusion further. It doesn't actually resolve it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html