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
