Hi Eliot, At 00:30 22-03-2009, Eliot Lear wrote: >This would be reaching goals for the sake of reaching goals. I >would note that an update isn't in the charter at all. I'm not >saying don't do it. I'm saying that I would rather
Without goals, we don't have a clear path stating what we want to achieve. I don't think that we should reach goals for the sake of reaching them. >the group re-examine its goals and decide what the right approach >is. Is there a dependency on the proposed changes to get ADSP out >the door, for instance? What about the readability of the document >series? Can one simply write an update that attempts to cut and >paste from the original without adding confusion? I'll skip your question about ADSP for now. Before doing any change, we should take into account its effect on the document series. >And now that this is going to be a full blown update or -bis effort, >what can be revisited? For instance, the approach I proposed, and >many of my objections to the approach Dave and others proposed, was >based on the notion that we were discussing an errata document and >not a standards-track I-D. If we are to have a standards-track I-D, >as I wrote quite some time ago, we have more leeway in changing >DKIM. For instance, what is the proper way to deal with i= as a >component of the standard? Should we deprecate it? I agree with your point about having more leeway if we are discussing a Standards-Track I-D. There has been discussions about making DKIM leaner by dropping some components. If we drop i=, then we introduce a change that affects ADSP. >This, by the way, is one of the problems I have with the chairs' >approach. We (those who opposed the draft) were asked to tweak >specific lines in the doc, while at the same time being told that >the draft's final disposition is being changed by the AD. I won't question the Chairs' approach. >I still have other concerns. Ultimately I think there is a downside >to being too constraining (the argument that John made earlier), >that people will ignore the constraints. For instance, in this >case, it's pretty clear that many people will ignore some of the >terminology and just take d=, Sender:, From:, and potentially l= and >the length, as inputs to identity assessment. And then they will >use i= anyway. >Saying otherwise, IMHO, *is* premature. Whatever. You're >attempting to standardize secret sauce. Here's news: some people's >secret sauce tastes bad (I always disliked Burger King's myself). In my opinion, people will take whatever input they view as useful for an assessment. There is nothing we can do about that except to say "don't do it". John Levine made a good point about interoperability. Regards, -sm _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
