Add notes regarding label usage, provided by i18n review (#841)

As suggested by @xfq, add additional details about operator labels,
clarifying that they are not intended to be natural language strings.
And include an advisement that use of developer-provided labels is
subject to spoofing, and implementations should sanitize them.

Co-authored-by: Anssi Kostiainen <[email protected]>

Author: inexorabletash

index.bs

@@ -701,8 +701,6 @@ A key part of the {{MLGraphBuilder}} interface are methods such as {{MLGraphBuil
 
 An [=operator=] has a <dfn for=operator>label</dfn>, a string which may be included in diagnostics such as [=exception=] messages. When an [=operator=] is created its [=operator/label=] is initialized in an [=implementation-defined=] manner and may include the passed {{MLOperatorOptions/label}}.
 
-Note: Implementations are encouraged to use the {{MLOperatorOptions/label}} provided by developers to enhance error messages and improve debuggability, including both synchronous errors during graph construction and for errors that occur during the asynchronous {{MLGraphBuilder/build()}} method.
-
 ISSUE(778): Consider adding a mechanism for reporting errors during {{MLContext/dispatch()}}.
 
 At inference time, every {{MLOperand}} will be bound to a tensor (the actual data), which are essentially multidimensional arrays. The representation of the tensors is implementation dependent, but it typically includes the array data stored in some buffer (memory) and some metadata describing the array data (such as its shape).
@@ -1575,6 +1573,12 @@ Implementations may impose a more restricted lower bound and/or upper bound on t
         Optionally provided when an [=operator=] is created using {{MLGraphBuilder}} methods that create {{MLOperand}}s. The implementation may use this value to initialize the [=operator=]'s [=operator/label=].
 </dl>
 
+Note: The label is not intended to be a natural language string. It is a language-independent identifier, analogous to a variable name or error code, like `"mul#1234"`.
+
+Note: Implementations are encouraged to use the {{MLOperatorOptions/label}} provided by developers to enhance error messages and improve debuggability, including both synchronous errors during graph construction and for errors that occur during the asynchronous {{MLGraphBuilder/build()}} method.
+
+Advisement: When displaying labels provided by developers via {{MLOperatorOptions/label}} in debugging tools, logs, or error messages, implementations should sanitize the output to prevent security risks, such as injection of malicious Unicode sequences (e.g. <a href="https://www.unicode.org/reports/tr36/#Bidirectional_Text_Spoofing">Bidirectional Text Spoofing</a> [[UTR36]], <a href="https://www.unicode.org/reports/tr55/tr55-5.html#Spoofing">Source Code Spoofing</a> [[UTS55]] and other concerns). For example, implementations should escape or filter control characters (e.g., U+202A to U+202E, U+2066 to U+2069) or use a safe rendering mechanism to neutralize potential spoofing.
+
 ### Creating an {{MLOperand}} ### {#api-mloperand-create}
 The {{MLOperand}} objects are created by the methods of {{MLGraphBuilder}}, internally using the following algorithms.
 
@@ -10309,6 +10313,8 @@ Thanks to Jiewei Qian for Chromium implementation review and feedback.
 Thanks to Dwayne Robinson, Joshua Lochner and Wanming Lin for their work investigating and providing recommendation for transformer support. Additional thanks to Dwayne and Wanming for providing reviews of operator conformance and web-platform-tests implementation.
 
 Thanks to Feng Dai for his continuous contributions that keep web-platform-tests evolving alongside the specification.
+
+Thanks to Fuqiao Xue and the W3C Internationalization Activity for reviews and suggestions.
 <pre class="biblio">
 {
   "Models": {