Dave,
I'm okay with your proposed approach. I agree that errata is a bit
vague, but since they don't always get read, and sometimes aren't even
known about, the next rev seems apt.
Eliot
Eliot
On 1/26/09 4:33 PM, Dave CROCKER 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 regularly hear someone explain their particular, reasonable and
sophisticated intent behind using one or another of the two values, as
if there is some magic by which the organization running the other
side of the DKIM exchange is going to a) be motivated, and b) be
knowledgeable enough, to incorporate that intent into their use of
DKIM. In fact, the other participant has no way of knowing about that
intent, and scaling limits make it impossible to incorporate all the
different intents.
What is missing is the thing that has always been at the core of
successful Internet protocol interoperability: a small, common, core
of semantics. The DKIM community disagrees about which of the two
values is that common, core, semantic output.
Creating distinctive names for the two makes a reference that uses one
of them unambiguous; clarifying the role and relationship of each
makes the meaning of each unambiguous. That's goodness. It's also
essential for interoperability.
Finally, I'll add one more comment, and then I'll withdraw. There
are a lot of errata filed for 4741. This is a good indication that
it's probably time for another version, and I would view this as good
news because it demonstrates a lot of work has occurred,
Good point.
So I'll suggest that we considered this proposed Errata as an Errata
entry, first and by itself, and *then* pursue generating a revised
dkimbase RFC.
That way we focus on the proposed Errata narrowly, and reach consensus
on it, before expanding the scope to an entirely new RFC.
Tony's suggestion that we pursue Draft status at the same time makes
sense to me. I had forgotten there were all those other errata.
d/
ps. I can't find any documentation that says anything about Errata
scope other than it covers 'errors'. Beyond that legalistic point,
the proposed change is, in fact, quite narrow and it merely fixes the
technical ambiguity about the output that the document says is its
primary goal.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html