On 2017-09-19 17:28, Carsten Bormann wrote:
...
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.
...
I don't see any abuse of UTF-8.
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.
I can only speak for me: I'm justifying the decision because I believe
it was the right one, and I happen to disagree that the negative effects
outweigh the benefits. If you want to convince me that the decision was
wrong, it would be helpful if you gave concrete examples of breakage -
not in theory, but in practice, not for *any* content, but for RFCs in
text/plain format.
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.)
With all due respect, I have no idea what you're talking about.
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)...
Actually, more are coming
(<https://www.rfc-editor.org/cluster_info.php?cid=C326>).
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.
...
Can you please point to *something* that says it's wrong to use the BOM
in UTF-8 encoded documents of type text/plain?
Best regards, Julian