Re: Should we update an RFC if people refuse to implement parts of it ?

--On Saturday, June 5, 2021 09:21 -0700 Dave Crocker
<[email protected]> wrote:

> At any rate, it appears that you are suggesting expanding the
> proposed, very simple, very narrow, very pragmatic and
> entirely experience-based proposal into a larger and more
> generic activity.
> 
> While the latter might be worth considering, there is nothing
> about the current issue that requires coupling it to the
> larger task.

Except that 

(1) Your "very simple, very narrow, very pragmatic, and entirely
experience-based proposal" may also be very wrong.  I don't
personally think it is, but I believe that deciding to make that
change by, e.g., the discussions on this list in the last few
days, would be inappropriate because it gives little or no voice
to those who have the strongest interest in in a fully
internationalized email system.    And no matter how often you
insist that your proposal is a very simple and pragmatic change
--presumably with no side effects--  will alter that exclusion
and the possibility those people identifying long-term side
effects we have not identified.

(2) At the risk of being even more pragmatic about your "very
pragmatic" proposal, I know of no way to make an authoritative
change in a standards track RFC -- whether one word or a few
paragraphs -- without generating an I-D, having it discussed in
the community, going through IETF Last Call, and publishing a
new RFC.    That is not a lightweight process even if the change
is "very simple and very narrow".  It seems to me that asking
the question of whether, given limited resources and energy and
other priorities, it is worth doing... and reaching a tentative
"no" conclusion.  John Levine's recent note suggests to me that
this issue is not a big problem and that, if we are inclined to
put more energy into the SMTPUTF8 collection, those resources
are better spent elsewhere.

    john