On Mon, Jul 26, 2021 at 5:00 PM Hubert Tong <hubert.reinterpretcast@gmail.com> wrote:
Apologies for sending this so close to the start of the telecon.

The paper refers to RFC 3808 which established the "IANA Charset MIB" and specifically says:
However, [rfc3808] is from 2004 and has not been updated.

The paper should at least make some reference to the location of the location where the "IANA Charset MIB" is maintained: https://www.iana.org/assignments/ianacharset-mib/ianacharset-mib. As of the document date indicated in P1885R5, the MIB module was last updated in January of the current year (2021). It seems this location was mentioned in passing on the SG16 reflector but with no emphasis on the significance.

Good point, I will update the paper :)

Also, I find the choice of naming the accessor that produces the MIBenum value from the IANA Charset Registry "mib" to be unfortunate. It seems there are unambiguous precedent cases in libraries (including those for other programming languages) using "mib" to refer to MIBenum values, so this does not rise to the level of an objection. I see no reason for the paper to use the term this way in prose though. I do note that RFCs do seem to use the term not only to refer to MIBs but also to MIB modules (but a MIBenum value is neither a MIB nor a MIB module).

I am open to better name suggestions!
Regarding the naming of the enumerator values, I am not fond of excess "invention" here. There are names (beginning with "cs") in the reference documents. Using those names (including the "cs" prefix) makes even the "csUnicode" case "merely following established practice".

Unicode is very problematic and goes back to a time when UCS-2 and Unicode were equivalent terms. I removed the cs prefix because C++ has enum classes making it non necessary.
Regarding the underlying type of the enumeration: The corresponding definition in RFC 3808 uses ASN.1 INTEGER (which does not have a length limit).

Using a specific length ensures forward compatibility - it's basically an abi concerns - i think there was justification for that in the paper otherwise we can explain it better
Regarding the "environment" functions, I think the wording needs more work to address cases where the value of the LANG environment variable is changed.
Do you have specific suggestions? Thanks! 

Thanks for the feedback Hubert!