Florian, Hi.
If you meant this posting, on Thursday, to be a vote in the consensus call, I do not see your explicitly choosing one. I think you are indicating support for choice (a) or (b), but it's important that you post a statement that says exactly what your choice is. d/ Florian Sager wrote: > 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 > -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
