On Mon, Jan 26, 2009 at 9:03 PM, Dave CROCKER <dhc(_at_)dcrocker(_dot_)net>
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