On Mon, Jan 27, 2025 at 9:22 PM Murray S. Kucherawy <[email protected]> wrote:
> > > On Sat, Jan 25, 2025 at 10:12 AM Richard Clayton <[email protected]> > 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. -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
