--On Wednesday, August 26, 2020 20:33 +0200 Florian Weimer <fw@xxxxxxxxxxxxx> wrote: >... >> If the charset name code you are interested in registering is >> defined in an RFC, you are presumably want the first, but it >> would be helpful for you to confirm that. > > The charset is currently unnamed, as far as I can see: it's > the UTF-7 variant in section 5.1.3 of RFC 3501. I have not been following IMAP work carefully in recent years (others here may be able to easily fill in the blanks) but my impression is that, as Unicode encoded in UTF-8 has taken over as the generally preferred form for transmission of non-ASCII characters over the Internet, UTF-7 has generally fallen out of use even if it has not been explicitly deprecated. In particular, its use is strongly discouraged in fully internationalized email contexts ... see the discussion in RFC 6855 for IMAP and RFC 6530ff for the more general case. >> They both have the same expert reviewers and both reviewers >> are still active in the IETF. Neither page lists a contact >> mailing list (perhaps an omission that should be created). >> There is a contact address listed in RFC 2978, >> "ietf-charsets@xxxxxxxx". If that address is no longer >> working, I recommend you contact iana@xxxxxxxx and ask them >> what it going on as doing so will generate a ticket in the >> appropriate system. > > Yes, I think this is already being taken care of. Yes. And I have copied Ned Freed, the lead Designated Expert on charset registrations, as a precaution. >> Second, allow me to ask a substantive question: at the time >> the registry was created, there were many charsets in use >> (and more being added). Today, there is little excuse for >> using anything but Unicode in one of its three standardized >> encoding forms. Unless there are circumstances I don't >> understand, adding and using an additional charset is likely >> to decrease >> interoperability, not increase it. So, while RFC 2978 is >> quite permissive and you only need to convince the experts, >> in the interest of interoperability, could you explain which >> RFC is involved and a bit about what is going on here? > > The charset is already defined and widely implemented. It's a > transformation format of Unicode. But a transformation form that was invented in the IETF, more or less specifically for one particular element of IMAP, not one standardized or recognized by the Unicode Consortium. That might be hair-splitting except for the problem below. > It's just presently unnamed. > Having a standardized name for it would help implementing > support in the POSIX iconv framework. Ah. Up to you -- and something to be worked out with the designated experts and on the appropriate lists (once it is sorted out) -- but some free (and maybe worth what you pay for it) advice: you'd get much better support and interoperability by dropping UTF-7 and converting the relevant applications to use UTF-8. That is particularly important because there are apparently several web applications and form processors that will ignore the charset parameter (either entirely or with any values they don't recognize) and try to deduce the charset or encoding form heuristically. And they will not accurately detect UTF-7 for reasons that should be obvious. So, while some of us are a bit nostalgic about UTF-7, I think the best strategy at this point would be to drop it, switch to UTF-8, and move on rather than trying to arrange more structure to encourage its use. Just my opinion, however: if you have what seem to you to be good reasons for making the registration, go for it. best, john
