Re: [Bimi] Alternate proposal

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

--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