[bp-i18n-specdev] DOMString and protocols (#152)

martinthomson has just created a new issue for https://github.com/w3c/bp-i18n-specdev:

== DOMString and protocols ==
In the guidance on strings, the [advice for DOMString](https://www.w3.org/TR/international-specs/#char_string_dom) says (emphasis mine):

> Use a [DOMString](https://webidl.spec.whatwg.org/#idl-DOMString) when defining document formats or **the wire format of a protocol**, or for any process pertaining to the [[DOM](https://www.w3.org/TR/international-specs/#bib-dom)], or which defines strings as opaque values whose individual character contents are not meant to be evaluated.

My experience with protocol development is that when carriage of strings is necessary, then bytes are needed.  In that case, UTF-8 is overwhelmingly preferred to other encodings.  The current text would seem to imply that UTF-16 is desirable, though it doesn't address the byte order issue that is absolutely essential for protocols.  That makes the advice incomplete, even if byte ordering issues are pretty easy to catch.

It's possible that the "protocols" you had in mind are either the exchange of `DOMString` values using a substrate that transparently handles any necessary conversions.  For example, [WebSocket.send`](https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/send) happily takes a string ... though you have to decode your own UTF-8 on receipt, which is gross ... a better example might be Fetch's `Response.text()`.

I would suggest that the right answer here is UTF-8 and `TextEncoder`/`TextDecoder` to form to and from `Uint8Array` if there is any need to send something somewhere.

Yes, this would mean that your advice on `USVString` as the natural thing to use when there is a need to use UTF-8 would need to be revised to match.

Please view or discuss this issue at https://github.com/w3c/bp-i18n-specdev/issues/152 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 19 February 2025 03:42:09 UTC