[x] Note that this crate implements the URL Standard not RFC 1738 or RFC 3986
Describe the bug
The docs for idna::Config don't explain when and why it might be appropriate not to use the default options. Also, idna::domain_to_ascii_strict does not explain when it's appropriate to call in instead of calling the non-strict variant.
The WHATWG URL Standard's beStrict option is only for checking content for conformance, but tools that need to deal with the names out there shouldn't be setting beStrict and the corresponding idna crate options.
(My context for filing this is that I'm investigating the possibility of developing a build-time option for the idna crate to use icu_normalizer to perform a subset of UTS 46 processing, and I'm trying to figure out what features that are unused in a Web browser are actually relevant to the wider crate ecosystem.)
Describe the bug
The docs for idna::Config don't explain when and why it might be appropriate not to use the default options. Also, idna::domain_to_ascii_strict does not explain when it's appropriate to call in instead of calling the non-strict variant.
The docs should explain the use cases so that callers don't introduce unwanted (from the user perspective) inability to process some names.
The WHATWG URL Standard's beStrict option is only for checking content for conformance, but tools that need to deal with the names out there shouldn't be setting beStrict and the corresponding
idnacrate options.(My context for filing this is that I'm investigating the possibility of developing a build-time option for the
idnacrate to useicu_normalizerto perform a subset of UTS 46 processing, and I'm trying to figure out what features that are unused in a Web browser are actually relevant to the wider crate ecosystem.)