Well, thank you for all yout thoughtful responses. I see that we are rehashing [the 2014 discussion](http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2014/006929.html), and probably others. Thanks @ethanrd for finding that. There are good arguments pro and con there, and it is worth reading.
The difference is that only 4 extra characters were proposed in 2014. I simply want to legalize all the other 137 thousand! > Is there a user asking for this extension, a particular use case that needs > addressing? CF has generally tried to avoid extensions that seem like a good > idea but don’t have a current use case. No, I do not have a current use case. This is a recurring issue, so I thought this comprehensive approach would be beneficial. Past use cases were mentioned or implied in the 2014 discussion, and in [trac 157](https://cf-trac.llnl.gov/trac/ticket/157). NetCDF developers put some care into expanded name capability, 12 years ago. However, CF restrictions are copied virtually unchanged from 25 year old COARDS rules, which were probably based on ASCII only. CF is overdue to allow the full naming range for creative purposes by all scientific users. Name quoting is generally easy and well supported in most modern programming languages. This takes care of UTF-8, math symbols, and other active characters. IMO, naming freedom should outweigh exactly matching names of program variables. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579516163 This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
