Well, I don't wish to be the pessimistic one. The changes only makes
us happy. So we passed the buck to external processes to make sure a
message is RFC5322/4409 ready. Doesn't change the fact that
something, someone has to do it and depending on the implementor, they
will be proactive about it or not. From a Product Development
standpoint, it is prudent the standalone API vendor deals with it. The
integrator will also be aware it needs to be dealt else where,
especially if the API vendor is ignorant about it.
As I reflected over our lunch meeting, all this doesn't matter when
the basic fundamentals about the overall DKIM payoff is still
questionable. I still have a difficulty in "selling" DKIM to our
customers - what/how will they benefit? All we are doing is producing
an AuthRes - Whoopie!!
I don't think anyone can describe DKIM in lay terms in one or two
sentence that doesn't even involve the AUTHOR DOMAIN interest or
rather doesn't make him scratch his head about how they should use
DKIM in a way they can "feel and touch" a payoff.
When the answer to the question, is NO:
Does a Author Domain have an controls over who is allowed
to sign his mail?
Its hard to see payoffs with DKIM.
Anyway, for the sake of the WG, lets get this done already. I don't
think it will alter current implementors but I do question if future
readers will be able to implement dkim from these specs. Its a
complex beast. But completing it, at the very least, I can use the
"official completion announcement" as part of our marketing.
PS: We resolved the overhead issues with DKIM signing so we are now
ready to go. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Barry Leiba wrote:
The 4871bis draft was on this past Thursday's IESG telechat, and
mostly passed, but for a strongly held DISCUSS position from one AD,
Pete Resnick. Pete had particular complaints about sections 8.14 and
8.15, along with some other issues, and was willing to block the
document until they were resolved. The editors and the AD together
worked diligently for resolution, and in the end came up with an
updated version that they can all accept, and that we think the
working group can as well -- at least to the extent that we had agreed
before; these changes will not make Charles and Doug happy, but I
think they retain the essence of the rough consensus of others.
Because of the extent of the changes, though, the chair (I) thinks it
needs to come back to the working group for another review. So the
working group is now asked to look over the diffs, noting that in a
few cases blocks of text were moved to other sections without being
changed. ONLY diffs are in scope for reconsideration at this point,
and we'll be looking for confirmation that the changes are acceptable,
as well as complaints about the changes. Complaints SHOULD come with
specific suggestions for alternatives. Pete apologizes for not having
been involved with this earlier, promises to closely follow the
mailing list thread on this, and will participate in any text
negotiation that's necessary in order to get this right.
We have a week. Murray will be posting the update (-14) very soon.
Please review and comment by 11 July.
Barry, as chair and document shepherd
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html