Editorial: Add note about when ToASCII = ASCII lowercase

Many implementations currently skip ToASCII if domain is ASCII-only, but
as discovered in [1] and [2], this can result in some undesirable
behavior. Adding a note prevents implementors from making the mistake of
thinking ToASCII is a no-op if the input is ASCII, and also provides a
recommendation on how to properly optimize the ToASCII step.

[1]: whatwg#267
[2]: whatwg#309 (comment)

url.bs

@@ -528,11 +528,17 @@ decisions made, i.e. whether to use the <a>same site</a> or <a>schemelessly same
 <var>domain</var> and an optional boolean <var>beStrict</var> (default false), runs these steps:
 
 <ol>
- <li><p>Let <var>result</var> be the result of running <a abstract-op lt=ToASCII>Unicode ToASCII</a>
- with <i>domain_name</i> set to <var>domain</var>, <i>UseSTD3ASCIIRules</i> set to
- <var>beStrict</var>, <i>CheckHyphens</i> set to false, <i>CheckBidi</i> set to true,
- <i>CheckJoiners</i> set to true, <i>Transitional_Processing</i> set to false,
- and <i>VerifyDnsLength</i> set to <var>beStrict</var>.
+ <li>
+ <p>Let <var>result</var> be the result of running <a abstract-op lt=ToASCII>Unicode ToASCII</a>
+ with <i>domain_name</i> set to <var>domain</var>, <i>UseSTD3ASCIIRules</i> set to
+ <var>beStrict</var>, <i>CheckHyphens</i> set to false, <i>CheckBidi</i> set to true,
+ <i>CheckJoiners</i> set to true, <i>Transitional_Processing</i> set to false,
+ and <i>VerifyDnsLength</i> set to <var>beStrict</var>.
+
+ <p class=note>If <var>beStrict</var> is false, <var>domain</var> is an <a>ASCII string</a>, and
+ <a>strictly splitting</a> <var>domain</var> on U+002E (.) does not produce any
+ <a for=list>item</a> that <a for=string>starts with</a> "<code>xn--</code>", this step is
+ equivalent to <a>ASCII lowercasing</a> <var>domain</var>.
 
  <li><p>If <var>result</var> is a failure value, <a>validation error</a>, return failure.