Drop publicSuffix.DomainOptions.encoding

[kzar]

Since safely displaying Unicode domains to the user seems out of scope for the
publicSuffix API, let's always encode returned registrable domains using
Punycode.

See the discussion here #231 (comment)

[mckenfra]

The Public Suffix API proposal was reviewed and approved by W3C reviewers from Mozilla, Apple and Google. During the formulation of the proposal, reviewers discussed and were supportive of providing an option to return registrable domains encoded as unicode, e.g.:

• 2024-09-12 Timothy (Apple) In favour of a unicode opt-in to facilitate displaying registrable domains to the user.
• 2025-05-17 rdcronin (Google) Proposal: Public Suffix API #676 (review) (click to expand 2nd review comment) As well as optionally encoding returned registrable domains as unicode, suggested the possibility of providing further encoding options in future.

Mozilla plans to make use of this unicode-encoding option in an update to its Multi-Account-Containers extension extension: on the screen showing the domains in the user's containers, the domains will be shown grouped by their registrable domains, which will need to be encoded as unicode since users may be unfamiliar with punycode.

Given the reviewers' support and above example use case for returning registrable domains optionally encoded as unicode, it may not be appropriate to drop this option entirely. However, a solution might be to rename the unicode member of the DomainEncoding enum. Possible alternative names:

• display
• safe-unicode

[kzar]

Thanks @mckenfra , given there's a concrete use case I'm more inclined to keep it like you say, and I agree that if we do keep it, a rename might make sense.

However, I still wonder if the "safe Unicode" encoding of domains would make more sense as a separate extensions (or web) API. I could imagine folks misusing publicSuffix.getDomain just as a way to format a domain for display, without needing to look it up in the PSL - wouldn't it make more sense to expose that functionality for them separately?

[mckenfra]

@kzar It definitely seems like it could be useful to expose a generalised API to convert from punycode to other encodings. If this were to be a webextensions API, then a first step would be to raise an issue containing a high-level proposal of the API: https://github.com/w3c/webextensions/issues

Regarding the publicSuffix API, I am happy to raise a PR to change the name of the option value from unicode to display.

[kzar]

(Marking as a draft for now, since @mckenfra has proposed an alternative approach.)

[Rob--W]

@kzar It definitely seems like it could be useful to expose a generalised API to convert from punycode to other encodings. If this were to be a webextensions API,

The conversion from/to punycode can be implemented entirely in JS libraries.

What is unique to PSL (and "display" encoding) is that browsers may have their own view, which makes it infeasible for a JS library to have a consistent and up-to-date view. That's why we have the publicSuffix API, and why I'm advocating for continuing support for partial unicode encoding (under the "display" name to avoid issues with confusables).

[kzar]

Fair enough, seems like I'm out voted here 😅. Will close this out.