Re: draft-gahrns-imap-language-01

Mark Crispin <MRC@cac.washington.edu> Mon, 04 October 1999 18:53 UTC

Received: by mail.imc.org (8.9.3/8.9.3) id LAA13666 for ietf-imapext-bks; Mon, 4 Oct 1999 11:53:37 -0700 (PDT)
Received: from Tomobiki-Cho.CAC.Washington.EDU (seung@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA13662 for <ietf-imapext@imc.org>; Mon, 4 Oct 1999 11:53:36 -0700 (PDT)
Date: Mon, 04 Oct 1999 11:25:22 -0700
From: Mark Crispin <MRC@cac.washington.edu>
Subject: Re: draft-gahrns-imap-language-01
To: Alexey Melnikov <Alexey.Melnikov@messagingdirect.com>
cc: Mike Gahrns <mikega@microsoft.com>, ietf-imapext@imc.org
In-Reply-To: <EXECMAIL.991004112112.C@chagall.MessagingDirect.com>
Message-ID: <MailManager.939061522.302.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
Sender: owner-ietf-imapext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Although I understand the motivation for the TRANSLATION extension to
NAMESPACE, I feel that there is a major problem with it.

The example shows a namespace called "Other Users/" with a translation of
"Autres Utilisateurs/".  Leaving aside the bogosity of the missing "#"
(particularly in light of the personal namespace), this example is going to
give certain individuals a strong feeling that "Autres Utilisateurs/" is a
valid namespace name.  This, in turn, implies that it is valid to use it in
URLs.

I strongly oppose localization of strings that could appear in a mailbox name
and/or a URL.  It's enough of a problem that they can be internationalized.

I suggest instead that we add a field in namespace called COMMENT or
DESCRIPTION, and that this new field can be localized.  This opens the
possibility for this field to be English; #public/ and #shared/ are very two
different things in my server, but that fact is not obvious from those names.

Since this no longer changes the namespace names, the draft can be simplied
and the troublesome rules between LANGUAGE and NAMESPACE can be deleted.

This has another desirable effect.  It may break client implementors of the
deplorable habit of treating the NAMESPACE command as simply another level of
hierarchy to a common root.  I've learned not to underestimate the grim
determination of certain client vendors to do the wrong thing in the face of
intense pressure from the specification otherwise. ;-)  But, maybe by having
the localized string as a comment, it may tip the balance towards treating
namespaces as independent hierarchies.