Sorry, just one more message from myself, because Murray Kucherawy said in a moderator message exchange
Nobody is asking that you leave. After i said it was my last message (except that the draft needs one more iteration). But in the meantime i have read (via web archive) that it was said that the other delta algorithm is a good thing. And noone spoke up against that. So then i do, one last time. The other approach is not good, despite all the non-real-life and blindingly dressed up examples that always can be seen. My first remark on message (part) reencoding from when it was posted first is still valid, and will remain so. And this is not only about entire MIME parts, it is also for individual headers. For example, the IETF lists themselve post, without any technical reason, Subject: [art] Re: [Json] ECMA and JSON Schema as Subject: =?utf-8?q?=5Bart=5D_Re=3A_=5BJson=5D_ECMA_and_JSON_Schema?= which is maximally suboptimal in several aspects (encoding not needed, plain 7-bit ASCII encoded as 7-bit clean 8-bit UTF-8). Now, if a technically not totally worn down MUA responds it'll say Subject: Re: [art] [Json] ECMA and JSON Schema without any MIME at all. Given that so many Python based software is on the way, which "D(ocument)O(bject)M(odel)" any emailish via the Python email machinery, i would bet such changes happen naturally. It is a bet, but a good one. I won't test now. But in reality changes happen much more often and for much more trivial conditions, compared to the blindingly good examples. In addition content needs to be checked so that the delta algorithm syntax does not clash with header content, so that possible base64 (i think) encoding can be applied (i think). Each and every snippet. And there can be plenty. Then possibly must be encoded for the reasoning of syntax protection only. (And if only comma, equal-sign, semicolon, i have not looked at latest variant.) Please compare this with what the mailman[23] mailing-list manager does, and with all the headers that players like Microsoft and Google produce, and things like IronPort. These headers (and parts) are practically all base64 per se. I am surely not that wrong when i interpret this in parts with "why spent a single thought, just go the safe way, period". Again the IETF comes over with an overengineered and overly complicated approach to a simple problem, with a new algorithm noone has asked for. Compare this fact alone with the ACDC approach, which makes use of Colin Percival's BSDiff algorithm, which is excellent and its core being used by so many parties and purposes for such a long time. And simply stores this compressed, and always encoded as base64. It may be a little bit larger due to the always required base64 overhead in not few cases, but as soon as real changes have to be tracked, things change quickly. And then this is always the same, sort the headers in stack order, as you need to for generating or verifying a DKIM signature, and pass it into the algorithm, and you get back the same, in and out. Maybe later, in all all-8-bit-Unicode email environment, such things do no longer matter. But this likely will take decades. Despite the many languages which pay a size-overhead price for the always necessary encoding of their character data. S/MIME and PGP require encoding due to normalization patterns anyhow. MBOX file content protection based "From_" quoting can only be circumvented by applying a MIME encoding, too. I do not know. In my opinion thus the delta algorithm of what the IETF wants to adopt is worth of criticism. *Too*, that is, *too*. So, but now, except for another iteration of an error i introduced, as not expecting any discussion anyway, and hoping that the next IETF meeting plan will not include my name no more, Good bye from Germany. P.S.: we need SMTP/TLS, except for TUHS *all* connections i have is via TLS, discovery via SRV is an easy thing to do, and native to SMTP servers, as they need MX lookups anyway, etc etc etc. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
