On 1/28/25 7:38 PM, Wei Chuang wrote:
On Mon, Jan 27, 2025 at 9:22 PM Murray S. Kucherawy
<superu...@gmail.com> wrote:
On Sat, Jan 25, 2025 at 10:12 AM Richard Clayton
<rich...@highwayman.com> wrote:
>> * Identify message mutations made by any handling agent; and
>
>I suspect this means identification of common mutations,
rather than all
>mutations, since there is no limit to the latter. This text
needs elaboration,
>for clarity and precision.
I didn't think "clarity and precision" were required for a
charter,
merely an indication of what was or was not in scope.
Identifying all
mutations is clearly in scope ... being able to "undo" them
may be too
complicated to consider (and self-defeating --- an
intermediary that
redacts sensitive information or removes malicious attachments
will not
wish a recipient to be able to undo their changes)
I think both are true: Clarity and precision about what is [not]
in scope is a requirement.
I suggest that all transformations are describable, otherwise
software couldn't do them. But not all transformations are
reversible (e.g., compression, or anything else that's lossy). I
think we're only interested in reversible ones.
So does the working group want to spend time exploring the notion
of "any possible reversible transformation", or would we rather
confine ourselves to a small (perhaps extensible) set of common
ones known to be reversible? The latter group is constrained and
certainly tractable; the former group is infinitely larger and a
general solution will require more time to nail down (or decide we
can't).
I would propose that the latest charter has latitude to try both the
broad and narrow approaches for "reversible transformation", and I
believe that's a good thing. I would like to see both directions
pursued as each has their pros and cons, and some of the cons might
not be so apparent till some operation experience is acquired. Or at
the least, there should be a meaningful technical discussion of the
proposals and merits after this step because of the prohibition
against technical discussion currently. Basically I'm saying let's
not rule anything out because we don't know what the proposals and
their merits are.
I mean, we're basically talking about ~diff(1), right? It's certainly
tractable in that context, but what may be problematic are maximum
header sizes in implementations. But realistically the things that would
implement this (eg, mailing lists) probably aren't going to be doing
something horrible like re-encoding an mp4 file or something like that
where you'd end up with gigantic header.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
