On Mon, Jan 26, 2009 at 9:03 PM, Dave CROCKER <[email protected]> wrote: > Eliot Lear wrote: >> Please say more because this is not at all clear to me. Why are more >> TLAs (or in this case FLAs) there? Also, you've defined another term: >> Identity Assessor. Why? > > There is real and substantial confusion in the community about these two tag > values. Confusion that affects interoperability. (I tend to use the cliche' > about watches: if you have one, you know what time it is; if you have two, > you > are never quite sure.)
I would support Eliot's point about introducing new terminology into an errata document rather than a -bis RFC as a followup to this one. Especially as a lot of work has already been done on this, it might be appropriate to produce both this errata document as well as a -bis based on broader feedback from the IETF community. Speaking entirely for myself, I always thought d= and i= are quite clear concepts by themselves, on what they denote and what they authenticate. There is, of course, substantial difference in opinion exist on their actual real life use cases, and on what reputation model can reasonably be layered on top of this authentication (or combinations of d= and i= some of which may be possible in more based on these. I personally dont see how differences in opinion on the use cases and reputation model are going to be resolved by this new terminology, but if some consensus has already been achieved on the FLAs, I give my qualified support to this changed nomenclature - based on any previous consensus that it makes the distinction between d= and i= clearer. Conversely (and I thank Eliot for raising this issue), if there is enough consensus that the FLAs can be dispensed with, I dont mind either. In either case, the next step I would suggest is an operational "use case" document, which takes off where > 9. Section 6.3. Interpret Results/Apply Local Policy leaves off by simply stating that this is beyond the scope of this RFC. The use case document can certainly describe scenarios (from both sides of the d=i=vide) where d= and i= are used to [a] authenticate an email (where there is little or no controversy] [b] layer a reputation model on top of this authentication [which is the bone of contention between the d= and i= camps, though possibly out of scope for this RFC or any use case document strictly based on DKIM as a framework for authentication]. Finally, whether or not the new FLAs are adopted or the old nomenclature is retained, in my view, the errata document serves its purpose by emphasizing the primacy of d= over i= (or in this case, their new FLA equivalents). Dave's analogy in the errata, about him being d= as the primary author of this RFC while the other contributors are i= is particularly apt in this case. Oh by the way, Dave, if you introduce new terminology for d= and i= .. might be reasonable to follow it in the entire document? :) > A. Acknowledgements [...] > although the final wording of the submitted draft is the sole responsibility > (d=) of the listed author. regards --srs _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
