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

On 6/5/2021 12:21 AM, John C Klensin wrote:
> --On Friday, June 4, 2021 16:14 -0700 Dave Crocker
> <[email protected]> wrote:
>> You appear to be asking how it would be helpful to have the
>> specification reflect extensive field experience.  But maybe
>> not?
> 
> No.  I am asking a much more pragmatic question or pair of
> questions: (i) whether making a change in this area (see below)
> is worth, at this particular point, opening up RFC 6531 and/or
> 6532 (and reviewing whether other documents in the SMTPUTF8
> collection to see if they need similar adjustments) would be
> worth the trouble and (ii) whether there is the energy to do
> that and to do it well.

Oh?  On re-reading your previous two postings, I'm still not finding 
those questions.

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.


> I think it is particularly important to ask the second question
> because the apparently  underwhelming speed at which EMAILCORE
> is converging on 5321bis and 5322bis does not support the
> hypothesis that there is a lot of energy to do work like this
> and because there are i18n issues associated with what the right
> solutions might be and there appears to be even less energy in
> the IETF for that kind of work.

Seems like a good reason for a) decoupling the larger task from the 
immediate, narrower one, and b) deferring the larger task until more 
immediate concerns are addressed.


> And, finally, while I am personally convinced, at least at this
> moment, that changes to the relevant text would be appropriate
> if we had the collective time and energy, it is much less clear
> to me that swapping MAY for SHOULD is the correct change to
> make.  If, in the long term and when SMTPUTF8 is ubiquitous,
> U-labels were really the better answer for this case, then the
> test ought to explain why that is the right target even while
> explaining why A-labels may be appropriate during the transition
> period (however long that lasts). 

Your 'if' is problematic.  You are invoking a desirable but indefinite 
-- and, based on history, a discouraging -- future state as a reason to 
refrain from making a simple, practical change, responding to 
established reality.



  Simply saying "everyone who
> has spoken up about implementations is using A-labels" is
> actually not a sufficient reason to change the spec.

Oh? Really?  Why is that?


>  And I
> again note that the people who were represented in the WG with
> the strongest perceived need for non-ASCII email addresses do
> not appear to be represented on this list. 

The IETF has established practice of making decisions based on those who 
show up.  It's not as if this is a hidden activity.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net