Subject: Reviving a dormant IANA registry

From: Florian Weimer <[email-masked]>
Date: Tue, 25 Aug 2020 12:30:54 +0200

What's the process for reviving an IANA registry where the contact
mailing list for additions is dead?

It's for the charset registry.  It requires expert review only, and I
want to see a charset defined in an RFC added to it because that part
was apparently missed when the RFC was written.  (The point is to get
an official name for the charset, to increase interoperability among
implementations.)

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Aug 2020 12:58:51 +0200

Contact the IESG.  They are responsible for assigning expert reviewers.

> On 25 Aug 2020, at 12:30, Florian Weimer <[email-masked]> wrote:
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 25 Aug 2020 07:01:21 -0400

Florian,

A good place to start are the relevant ADs, see section 5.2.1 of RFC 8126.

Cheers,
Andy

---

From: tom petch <[email-masked]>
Date: Tue, 25 Aug 2020 12:22:01 +0100

> A good place to start are the relevant ADs, see section 5.2.1 of RFC 8126.

Or you could go to IANA.  I see on the IANA website
Character Sets Mailing List Information
with an IANA address and if you mean that that address is unavailable, 
then that is a defect in the IANA website that needs fixing by IANA; 
which, in my experience, IANA are rather good at.

Tom Petch

---

From: John C Klensin <[email-masked]>
Date: Tue, 25 Aug 2020 07:34:53 -0400

--On Tuesday, August 25, 2020 12:30 +0200 Florian Weimer
<[email-masked]> wrote:

> What's the process for reviving an IANA registry where the
> contact mailing list for additions is dead?
> 
> It's for the charset registry.  It requires expert review
> only, and I want to see a charset defined in an RFC added to
> it because that part was apparently missed when the RFC was
> written.  (The point is to get an official name for the
> charset, to increase interoperability among implementations.)

I'm a little confused by your question.

First, there are actually two registries that can be referred to
as charset registries, both defined in RFC 2978:

 * The "Character Sets" list at
	https://www.iana.org/assignments/character-sets/character-sets.xhtml
	
 * The "Character Set Registrations" list for codes that
	are in use but not defined by RFCs, listed at
	https://www.iana.org/assignments/charset-reg/charset-reg.xhtml

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.

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, "[email-masked]".
If that address is no longer working, I recommend you contact
[email-masked] and ask them what it going on as doing so will
generate a ticket in the appropriate system.

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?

thanks,
   john

---

From: Michelle Cotton <[email-masked]>
Date: Tue, 25 Aug 2020 15:00:29 +0000

Hello Florian,

I'm taking a look at the mailing list information to see what needs to be fixed.

There are experts for the character set registry.  We will follow the RFC's guidance for any requests sent to IANA.

I see that others have provided helpful information and questions for you as well.  

Please let us know if there is anything we can do to assist.

Best regards,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services

On 8/25/20, 3:31 AM, "ietf on behalf of Florian Weimer" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Florian Weimer <[email-masked]>
Date: Wed, 26 Aug 2020 20:33:44 +0200

> I'm a little confused by your question.

Sorry, it looks like I was confused as well.

> 	https://www.iana.org/assignments/charset-reg/charset-reg.xhtml

Thanks for the clarification.

> 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.

> generate a ticket in the appropriate system.

Yes, I think this is already being taken care of.

> 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.  It's just presently unnamed.
Having a standardized name for it would help implementing support in
the POSIX iconv framework.

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Aug 2020 16:07:21 -0400

--On Wednesday, August 26, 2020 20:33 +0200 Florian Weimer
<[email-masked]> wrote:

>...
> 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,
>> "[email-masked]". If that address is no longer
>> working, I recommend you contact [email-masked] and ask them
>> what it going on as doing so will generate a ticket in the
>> appropriate system.
> 

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?
> 
> 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

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2020 17:42:41 -0400

In article <EA8AA46EB86616943490A217@PSB> you write:
>use even if it has not been explicitly deprecated.  ...

Everything you say is true, but I can say from experience that even
though the RFC 6855 UTF-8 character encodings are a lot better than
the mutant UTF-7 in RFC 3501, in practice hardly anyone implements the
UTF-8 encodings yet, but everyone has the old UTF-7.

Since that this bad encoding is well defined and widely implemented, I
can't object to giving it a name. Perhaps UTF-7UGH.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Aug 2020 19:06:36 -0400

--On Wednesday, August 26, 2020 17:42 -0400 John Levine
<[email-masked]> wrote:

>> characters over the Internet, UTF-7 has generally fallen out
>> of use even if it has not been explicitly deprecated.  ...
> 
> Everything you say is true, but I can say from experience that
> even though the RFC 6855 UTF-8 character encodings are a lot
> better than the mutant UTF-7 in RFC 3501, in practice hardly
> anyone implements the UTF-8 encodings yet, but everyone has
> the old UTF-7.

That is obviously the knowledge I lacked.  If it is use in
situations in which having a defined charset code would help,
then go for it.

> Since that this bad encoding is well defined and widely
> implemented, I can't object to giving it a name. Perhaps
> UTF-7UGH.

Perhaps that is one of the more mild ways of sending a useful
signal. UTF-7-IsBadNews also comes to mind :-(

And we should probably consider formally deprecating the thing,
not because it will cause faster adoption of UTF-8 but because
it would give us a place to explain why it is not a very good
idea going forward.

    john

   john

---

From: [email-masked]
Date: Wed, 26 Aug 2020 16:40:43 -0700 (PDT)

I used utf-7-imap. FWIW.

				Ned