<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 11, 2020 at 8:24 PM Tom Honermann via Unicode <<a href="mailto:unicode@unicode.org">unicode@unicode.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 10/10/20 7:58 PM, Alisdair Meredith
via SG16 wrote:<br>
</div>
<blockquote type="cite">
One concern I have, that might lead into rationale for the current
discouragement,
<div>is that I would hate to see a best practice that
pushes a BOM into ASCII files.</div>
<div>One of the nice properties of UTF-8 is that a valid
ASCII file (still very common) is</div>
<div>also a valid UTF-8 file. Changing best practice
would encourage updating those</div>
<div>files to be no longer ASCII.</div>
</blockquote>
<p>Thanks, Alisdair. I think that concern is implicitly addressed
by the suggested resolutions, but perhaps that can be made more
clear. One possibility would be to modify the "protocol designer"
guidelines to address the case where a protocol's default encoding
is ASCII based and to specify that a BOM is only required for
UTF-8 text that contains non-ASCII characters. Would that be
helpful?<br></p></div></blockquote><div><br></div><div>'and to specify that a BOM is only required for UTF-8 ' this should NEVER be 'required' or 'must', it shouldn't even be 'suggested'; fortunately BOM is just a ZWNBSP, so it's certainly a 'may' start with a such and such.</div><div>These days the standard 'everything IS utf-8' works really well, except in firefox where the charset is required to be specified for JS scripts (but that's a bug in that)</div><div>EBCDIC should be converted on the edge to internal ascii, since, thankfully, this is a niche application and everything thinks in ASCII or some derivative thereof.</div><div>Byte Order Mark is irrelatvent to utf-8 since bytes are ordered in the correct order.</div><div>I have run into several editors that have insisted on emitted BOM for UTF8 when initially promoted from ASCII, but subsequently deleting it doesn't bother anything.</div><div><br></div><div>I am curious though, what was the actual problem you ran into that makes you even consider this modification? </div><div><br></div><div>J</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<p>Tom.<br>
</p>
<blockquote type="cite">
<div><br>
</div>
<div>AlisdairM<br>
<div><br>
<blockquote type="cite">
<div>On Oct 10, 2020, at 14:54, Tom Honermann via
SG16 <<a href="mailto:sg16@lists.isocpp.org" target="_blank">sg16@lists.isocpp.org</a>>
wrote:</div>
<br>
<div>
<div>
<p>Attached is a draft proposal for the Unicode
standard that intends to clarify the current
recommendation regarding use of a BOM in UTF-8 text.
This is follow up to <a href="https://corp.unicode.org/pipermail/unicode/2020-June/008713.html" target="_blank">discussion on the Unicode mailing list</a>
back in June.</p>
<p>Feedback is welcome. I plan to <a href="https://www.unicode.org/pending/docsubmit.html" target="_blank">submit</a> this to the UTC in a week or so
pending review feedback.<br>
</p>
<p>Tom.<br>
</p>
</div>
<span id="gmail-m_-2846571300384305609cid:958C9297-66AC-4D88-8F0B-577B8BA2589E@nyc.rr.com"><Unicode-BOM-guidance.pdf></span>--
<br>
SG16 mailing list<br>
<a href="mailto:SG16@lists.isocpp.org" target="_blank">SG16@lists.isocpp.org</a><br>
<a href="https://lists.isocpp.org/mailman/listinfo.cgi/sg16" target="_blank">https://lists.isocpp.org/mailman/listinfo.cgi/sg16</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
</blockquote>
<p><br>
</p>
</div>
</blockquote></div></div>