Re: [Bimi] Alternate proposal

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

Trent,

Many thanks for your response -- it is, perhaps obviously, what
I hope you would say but I was feeling in some need of
reassurance.

Two quick comments: 
 
(1) Consideration of what discussion is most useful and the
timing should, IMO, belong, at least for the present, with you
and your co-authors.  But please consider how you would
determine the right time to switch from picking at the documents
to asking higher-level questions about whether the approach is
right and when/whether other approaches should be considered
(even if only a strawman proposals to encourage more thinking
and even if the assumption is that we will then come back to the
documents). 
 
(2) I can't speak for others but, especially with IETF 114 and
related commitments imminent, I, at least, would welcome you and
your colleagues having a discussion among yourselves, about
what, based on the list discussion so far,   you think the key
issues are and posting a summary of that discussion.  That does
not in any way take away from the open discussion on the list
that we agree is critical -- I'd assume some of the rest of us
might disagree with your conclusions (and, as you have figured
out, few of us are shy).  But I think that such a summary might
usefully focus the discussions without constraining them.  And,
if there are places where you disagree, that is probably an
important area for us to focus on too.

thanks,
   john

--On Thursday, July 21, 2022 18:43 +0000 Trent Adams
<tadams=[e-mail]> wrote:

> 
> For what it's worth - I agree with John's assessment.  And
> that's precisely why I think we need to have all conversations
> about BIMI on this open discussion list.  We need the
> visibility and input from all stakeholders in order to have a
> truly effective discussion.
> 
> So... that being said... I'd suggest that we redouble our
> efforts to review the feedback so far and discuss what's next.
> I know that I sparked the most recent conversational thread
> with questions about the MUA role in BIMI evaluation (a known
> trouble point)... and I honestly think that the conversation
> has been a productive one.  It's not always smooth sailing,
> but that's to be expected.
> 
> In short... I'd like to avoid unnecessary balkanization of the
> effort.  For my part, I'd like to see if we can address the
> suggestions of John and others so far and see where it can
> lead the work.
> 
> My $0.02,
> Trent
> 
> 
> From: bimi <[e-mail]> on behalf of John C Klensin
> <[e-mail]> Date: Thursday, July 21, 2022 at 12:10 PM
> To: Todd Herr <todd.herr=[e-mail]>,
> "[e-mail]" <[e-mail]> Subject: Re: [Bimi] Alternate
> proposal
> 
> --On Thursday, July 21, 2022 11:39 -0400 Todd Herr
> <todd.herr=[e-mail]> wrote: > On Wed, Jul
> 20, 2022 at 10:16 PM John C Klensin > <[e-mail]>
> wrote: > >> As promised in my recent "Radical
> 
> 
> 
> 
> 
> 
> --On Thursday, July 21, 2022 11:39 -0400 Todd Herr
> 
> <todd.herr=[e-mail]> wrote:
> 
> 
> 
>> On Wed, Jul 20, 2022 at 10:16 PM John C Klensin
> 
>> <[e-mail]> wrote:
> 
>> 
> 
>>> As promised in my recent "Radical critique" note, a
>>> suggestion
> 
>>> about a completely different way to approach the BIMI
>>> problem,
> 
>>> one that would be far less complex and problematic.  This is
> 
>>> just an outline with many details left to be filled in -- my
> 
>>> purpose in sending the note is to encourage people to think
> 
>>> differently about the issues and see if there is interest in
> 
>>> further discussion.
> 
>>> 
> 
>>> [snip]
> 
>>> 
> 
>>> Would something along those lines make any sense at all?
> 
>>> 
> 
>> 
> 
>> I can't answer your question, but I do know that there is
> 
>> already running code for BIMI, written against the draft spec
> 
>> as it currently exists.
> 
>> 
> 
>> It would be up to the implementers to decide if they're
> 
>> willing to scrap their currently running code and start over
> 
>> with something new.
> 
> 
> 
> Todd,
> 
> 
> 
> <rant>
> 
> My very first task when I became Apps AD a very long time ago
> 
> was to explain to what were, then, some very significant
> 
> implementers that, while the IETF could not prevent them from
> 
> implementing on the basis of an I-D, they had no right to
> 
> complain if the IETF's work evolved in a different direction.
> 
> Many things have changed in the last (nearly) 30 years, but I
> 
> think that, if the IETF is going to remain meaningful as a
> 
> standards body, the underlying theme has to be preserved.
> 
> Nothing prevents a group of implementers from getting together,
> 
> doing whatever they want to do, writing a description of it up,
> 
> and posting that as an I-D.  However, if they want IETF
> 
> endorsement for what they are doing (or have done), that
> implies
> 
> seeking community consensus that what they are doing is worth
> 
> doing, that it is the right way to do it and, presumably, a
> good
> 
> faith intent to accept that consensus, whatever it might turn
> 
> out to be.
> 
> 
> 
> The oft-cited "running code" principle was never intended to
> 
> imply "we did this together, we implemented it, it works in our
> 
> controlled and cooperating environments, so the IETF has to
> 
> accept and standardize it".  If things ever reach that point,
> 
> one has to wonder what the point of the IETF would be: the ISE
> 
> is perfectly capable of publishing documents of the flavor of
> 
> "ABC Company's Way To Do X" and "XYZ Consortium's Way to Do Y"
> 
> documents and has a long history of doing so.  Because those
> 
> documents are explanatory and descriptive, not normative and
> 
> with claims of community consensus, getting them published is
> 
> normally much quicker and far less painful than getting the
> IETF
> 
> to agree.
> 
> </rant>
> 
> 
> 
> So, what I have seen here, in addition to many suggestions
> about
> 
> improving editorial and terminology quality, are multiple
> 
> concerns about functionality and interoperability.  Many of
> them
> 
> have been raised by people with several decades of experience
> 
> trying to make email work in an interoperable way, a few of
> whom
> 
> even having had reputations of having almost never agreed about
> 
> anything over that period.  Nothing makes them (us)
> 
> authoritative but the concerns, especially those based on prior
> 
> bad experiences, should probably be taken seriously.
> 
> 
> 
> And not only have those concerns been raised, but I believe I
> 
> have seen several exchanges in which someone (other than me)
> has
> 
> made a point, gotten a message in response, and pointed out
> that
> 
> the message did not respond to the original point  (sometimes
> 
> with more than one iteration on the same point/issue).
> 
> 
> 
> With the understanding that I believe the authors and
> 
> implementers are sincerely interested in moving this work
> 
> through the IETF and getting IETF input and consensus and have
> 
> seen no evidence to the contrary so far (even though I think
> 
> there have been some communications difficulties), my two notes
> 
> were prompted by a pair of questions: (1) whether there is
> 
> actually growing agreement that hard questions (not just
> 
> questions about fine-tuning) are being asked, and should be
> 
> asked, about the proposals and their operation and
> 
> applicability, and (2) whether, if and when we reach the point
> 
> that a radically different approach == perhaps one based on
> MIME
> 
> facilities rather than mail header fields-- seems to be in
> 
> order, that is possible to consider going in that direction?
> If
> 
> the answer to the first question is "no", then I hope someone
> 
> will help persuade me, possibly offline so as to not waste time
> 
> on the list.   If the answer to the second is "no", then I
> 
> suggest starting to recast the documents as "this is what it is
> 
> and how we do it" descriptions rather than specifications to be
> 
> processed in the IETF.
> 
> 
> 
> Those, of course, are just personal suggestions: I claim no
> 
> authority here, just that I think it has gotten to be time to
> 
> ask the questions.
> 
> 
> 
>    best,
> 
>      john
> 
> 
> 
> 
> 
> --
> 
> bimi mailing list
> 
> [e-mail]
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi
> nfo/bimi__;!!ORgEfCBsr282Fw!uuANg5bLiKQquUjZ55P1eDJEyycLqGfcKN
> V9peswRJBw9pfpstRCSPQoF08oGvTR-4hdCeG3K6i64zmKyA$