Use of in-field metadata not preferred

[aphillips]

6.4.2. Language and Direction Encoding
https://www.w3.org/TR/webauthn-2/#sctn-strings-langdir

The first encodes a language tag with the code point U+E0001 followed by the ASCII values of the language tag each shifted up by U+E0000. For example, the language tag “en-US” becomes the code points U+E0001, U+E0065, U+E006E, U+E002D, U+E0055, U+E0053.

The above mechanism was introduced in this version of webauthn to address I18N's comment (#1526) about the need for language/direction metadata. It would be preferable to introduce separate metadata fields. It's unclear if this mechanism is a good idea vs. doing nothing, since presumably implementations might be created and thus constitute a backwards compatibility issue.

[equalsJeffH]

See also issue #1646

[equalsJeffH]

See also similar issue in secure-payment-confirmation: w3c/secure-payment-confirmation#93

[aphillips]

In our visit to your meeting at TPAC 2024, we discussed the various open I18N issues. This comment is to record what we said the resolution would likely be and I18N's reaction to it. I will add comments linking to this one to the other issues we have open, all of which relate to the same general problem.

---

In our meeting we discussed that inventing a new language/direction metadata serialization was undesirable, especially since no implementations currently have coded it or support decoding it. If any implementation did start to use this encoding, the result would be the addition of gibberish to values displayed in all other implementations on the Web.

Instead, we discussed that you would remove the additional serialization. For existing fields that antedate standardization, there appears to be no way to introduce field-specific metadata. For new fields that you add to Webauthn, you will follow the single language localizable text field best practices in String-Meta.

It occurred to me after the meeting to suggest providing a resource-wide default would be a way to possibly address the existing fields. These would be additional optional new fields in authentication request/response structures such as AuthenticatorResponse that allow the locale and direction of any contained natural language strings to be indicated without placing a burden on existing systems.

In any case, if you remove the lang/dir serialization from the spec and close this (and related issues), I18N will not object to your progressing.