On Sep 19, 2017, at 16:29, Paul Hoffman <paul.hoffman@xxxxxxxx> wrote: > > On 19 Sep 2017, at 4:22, Carsten Bormann wrote: > >> My disappointment is in that these considerations apparently were overruled by trying to please everyone. >> This is not representative for the IETF that I want to work in. > > The drafts leading to the document that specified this action, RFC 7994, was discussed on an active mailing list with lots of members. The IESG asked, on this list, for people to review the set of documents that included this one and asked people to send input to the IAB before the drafts were turned into RFCs. Yes, and it is of course my fault for not paying attention. (I’m not making a process appeal here or anything. I’m just trying to make more people aware that this is not a good way forward.) But then, “be liberal in abusing UTF-8” wasn’t one of the stated objectives of the work, so maybe I can be forgiven for paying close attention to the details only now, and for being disappointed in what I found. > Maybe the IETF that you want to work in doesn't let the IAB publish its own documents, even after soliciting review on this list, but that is the IETF you have been working in for as long as we have known each other. We publish many documents and we make many mistakes while doing so. That is a result of running an organization with humans. And of course the IAB can publish its own documents, and is as entitled to make its own mistakes as anyone else here. The IETF I have been working for (and the IAB I have been working with) generally has been way above the average of other SDOs in deflecting the reflex of justifying past decisions and instead fixing what needs to be fixed. I wonder why justifying the past decision is taking so much more room here than thinking about the issue and the effects of this decision. The IETF also has been reasonably effective in thinking about the signals its decisions send. This hasn’t worked so well here. (Maybe its a matter of thinly spread experience — maybe too few people here work with implementers that will soak up this signal giddily as their future excuse for not doing the work.) Anyway, there is very little that can be done about this right now, except maybe for noting the issue. RFC 8187 is published in its present form and cannot be changed. RFC 7994 will probably be considered the specification in force until it is superseded (thankfully, we have a moratorium for beyond-ASCII RFCs for other reasons). But maybe it has become clear that there is at least a vocal minority here that thinks using UTF-8 right not just in our protocols but even in our documents is way more important than minimizing the theoretical amount of mojibake for the largest number of people that enjoy viewing plain text RFCs while employing legacy software for that. Grüße, Carsten