Charles,
Charles Lindsey wrote:
> Yes, I might do that in due course, but we need to toss the idea
> around here a little bit more first (as we seem to be doing).
Good. I think that that's the right approach (and has the nice
side-effect of being a good check on whether we've done the
pluggability stuff well in base).
If draft-lindsey-dkim-better-c14n were ready for discussion in
Prague or before that'd be about right, IMO.
My concern is that people will tend not to implement stuff that is not
in the base standard. And any c14n has to be implemented at both ends in
order to be of any use.
I understand. However, in the case of xmlsig I think the 2nd c14n
spec (which was demonstrably more useful) basically won out even
though it was done about a year later.
So there is an existence proof that, where there's a real benefit,
then the market moves to use c14n that works.
And in this case, as was pointed out, and I think, agreed by you
above, yours is a late, though interesting, proposal, that needs some
more work, (e.g. in terms of security & performance analysis, field
testing etc.). That's a fairly strong argument for going with the
current proposal in base since that's already been through those
hoops.
Cheers,
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html