Murray S. Kucherawy schrieb: > > My vote: > >> >> a) The erratum I-D [1] is ready to go. Process it. >> >> >> > > If there is indeed a requirement to conform to the concept that a protocol > > must specify its payload, I believe this is the right way to go. At > > present, a new API implementor has no clear indication of what a minimal > > DKIM implementation has to provide to be compliant. > > > That's correct. As a summary of what I've read in the last mails with inclusion of the experience I made with data collection, evaluation and publishing in www.dkim-reputation.org:
- the UAID definition in draft-ietf-dkim-rfc4871-errata-02 is suitable; as far as I can see Jim's proposal of r= was made having a higher identifier stability in mind. IMHO, concerning stability, with r= nothing more can be reached as with the definition of the UAID in the errata document. Reasons for that: Jim was talking about the indirect transition of reputation by the referring r= identifier. I think the following trust hierarchy is correct in principle: "author -> author identifier -> signing domain -> DNS". I consider the lower part of the hierarchy "signing domain -> DNS" as the trust anchor in DKIM. I see no auto+technical+trustworthy means to provide a transition of reputation beyond this trust anchor --> transition aspect fails. The idea of a 1*r= : N*identities relation reverses the hierarchy --> not usable. The result is: r= is conceptual equal to i= (it doesn't really matter if i= contains d=, it's still opaque). Did I miss something? - I confirm the rare use of i=; the errata clarifies some misunderstanding but it won't lead to a broader use 'cause the advantages of the additional effort to include i= are unclear at the moment. But: thinking about a higher identifier precision in reputation systems (I just refer to good signers, bad signers will try to trick the rep-systems anyway) I'd absolutely appreciate if in the errata doc, "Section 3.5 The DKIM-Signature Header Field" the sentence "The syntax is a standard email address where the Local-part MAY be omitted." could be replaced by "The syntax is a standard email address where the Local-part SHOULD be set to a user unique value". Coming back to the last discussion: in my view a reputation system has to deal with arbitrary UAID values, I am missing the requirement that lead to the "protocol" discussion (?) Regards, Florian _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
