On Sep 19, 2017, at 13:09, Heather Flanagan (RFC Series Editor) <rse@xxxxxxxxxxxxxx> wrote: > > The RFC Format Design Team discussed this at length. I'm copying (with permission) the reports on the test that had us agreeing to use a BOM in these files. The end result was that too many apps could not display a UTF-8 file correctly without a BOM. Hi Heather, this is a fine survey, and its result would be imperative if the objective of the RFC series were to maximize the viewing pleasure when using legacy applications. I can understand that a design team tasked with this will arrive at exactly this conclusion. However, the point of the RFC series is not the above, but to make the net work better. BOM pollution does not make the net work better. Worse, you are sending out the following signal loud and clear on behalf of the IETF: It is OK for an application to mistreat UTF-8 input unless it is BOM-polluted. I’m unable to recreate the group dynamics of the design team that led to this unfortunate outcome, but I’m able to sympathize with the group-think focusing on deployability of this solution rather than evolution of the Internet at large. All I intended to do here is point out that there are other considerations than legacy support (and that legacy support, while still relevant in some environments, is going away as a concern with the UTF-8 transition completing and also never really has been a concern for our target audience, which on legacy systems already has to fight with the non-DOS line ends and will mostly use the unaffected Web browsers anyway). 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. Grüße, Carsten