Re: [Bimi] Bimi Goals (was: Re: Thoughts about MUA/BIMI)

[John C Klensin <[e-mail]>]

--On Friday, August 12, 2022 14:40 -0700 Dave Crocker
<[e-mail]> wrote:

> On 8/12/2022 10:58 AM, Brotman, Alex wrote:
>> My apologies, I was not trying to suggest that other options
>> cannot be considered.  I was noting how the document/spec is
>> currently designed, and that both goals are important
>> (perhaps independently).  It's entirely possible that we
>> could alter the method to work as you'd suggested a few weeks
>> ago, and the independent MBP can impose their own
>> restrictions which could include any manner of things
>> including DMARC.
> 
> Alex,
> 
> Your note seems to suggest the idea of parallel mechanisms, as
> alternatives.  In my experience, those don't work.  It was,
> in fact, a hallmark of the excessive complexity created in
> some/many of the OSI specifications.
> 
> If you don't mean that, then I'm not clear what you mean,
> concretely.
> 
> Note that while some of my posting(s) today do cite inherent
> limitations of basing Bimi on DMARC, et al,  at least one
> other posting discusses an add-on, for interacting with
> unaffiliated MUAs, that does not require any changes in the
> existing DMARC dependency.
> 
> The larger point I've raised is, really, not a new one,
> although apparently came up fairly recently in Bimi
> discussion:  Namely the need to carefully consider the larger
> operational context that is to be supported and development of
> very -- very -- clear understanding of the needs of that
> context and the reasons for excluding any plausible cases,
> including threats, operational challenges, semantic challenges
> -- such as loss of rights to use of the image -- etc.
> 
> One can easily imagine making a set of choices that only suit
> a very limited set of platform providers.  In business terms,
> narrowing the market segment to be served is hardly unusual.
> 
> But to the extent that this work is being done in public --
> and especially since the discussion here is hosted on an IETF
> platform -- the lack of clarity about those choices should be
> remedied, IMO.

Alex,

Just for clarification, while Dave is approaching the issues
differently than I am and consequently is identifying and
explaining different issues (or versions of them), I am in
almost complete agreement with what he wrote below. Stepping a
bit aside from the technical issues, I would put special
emphasis on his last two paragraphs above.  If the goal is to
design a system that will work well for a limited set of
platform (or other providers) then things get much easier for
those providers but this is, for multiple reasons, the wrong
place to be holding the conversation.  By contrast, if you want
to open it up to a broad range of providers and have the
conversation here, most, if not all, of the issues and
alternatives that Dave, myself, and others have brought up,
especially those that reduce changes to working protocols or
otherwise reduce complexity, deserve careful attention.

best,
   john