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.
- Re: draft-gahrns-imap-language-01 Alexey Melnikov
- Re: Prohibitting enumaration of languages when sp… Alexey Melnikov
- Prohibitting enumaration of languages when specif… Mike Gahrns
- Re: draft-gahrns-imap-language-01 Mark Crispin
- Re: draft-gahrns-imap-language-01 Alexey Melnikov
- Re: draft-gahrns-imap-language-01 Mike Gahrns