Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07

Barry Leiba <barryleiba.mailing.lists@gmail.com> Thu, 10 September 2009 22:49 UTC

Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: ima@core3.amsl.com
Delivered-To: ima@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D8F3A67E7 for <ima@core3.amsl.com>; Thu, 10 Sep 2009 15:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Level:
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJLJHUTZ275p for <ima@core3.amsl.com>; Thu, 10 Sep 2009 15:49:38 -0700 (PDT)
Received: from mail-yw0-f195.google.com (mail-yw0-f195.google.com [209.85.211.195]) by core3.amsl.com (Postfix) with ESMTP id 9FFC83A6861 for <ima@ietf.org>; Thu, 10 Sep 2009 15:49:38 -0700 (PDT)
Received: by ywh33 with SMTP id 33so829759ywh.18 for <ima@ietf.org>; Thu, 10 Sep 2009 15:50:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fSGZb6FyApDN2rYKRqXeco5LZ+RDSALc1ErfBiyvjyk=; b=aS3KlqZzH0pDGUkM2b5DSovbsSJZVvaYYAooSvjdca+AU29r3xjlfh73e3wKP5mL7g RzuswYzS3wClBj9cMP0rQWx8zpGmDX8X+XCyMLXT9RR39kaZS0tfGkJqWVmzGTlJqk34 2gNYwzao/+up7lRyAdUoIrjn56yxcqzFB69a0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=aK0X3ncOWxlWjYjLSb6qpLKW3t1GA73xLIK3lDl1QeCIkD5ABLkx43ppUUek3QOiuY 3DN9iPZBFeJMgefr3Y7wPXgnTrtmbK0HzTqqt9sEp5bk/Em5HujSWjHisDtt0Yh4UWG6 f/qaFmXyzCaR+QBfW3Mn+ErDH3F7y0WvZIhqw=
MIME-Version: 1.0
Received: by 10.150.61.18 with SMTP id j18mr3689811yba.184.1252623009633; Thu, 10 Sep 2009 15:50:09 -0700 (PDT)
In-Reply-To: <4AA96B90.7070007@isode.com>
References: <6.2.5.6.2.20090830222724.034fdb30@elandnews.com> <6c9fcc2a0909010725m9f1a4c2x159fb13d05df5f91@mail.gmail.com> <4A9D9878.7010302@isode.com> <p06250105c6c5c5428ce9@172.16.1.8> <6c9fcc2a0909031518v3e826ff2je1b622a6acfdd59a@mail.gmail.com> <4AA96B90.7070007@isode.com>
Date: Thu, 10 Sep 2009 18:50:09 -0400
Message-ID: <6c9fcc2a0909101550i13d01c93tca7be5bccbf1c0b6@mail.gmail.com>
From: Barry Leiba <barryleiba.mailing.lists@gmail.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Pete Resnick <presnick@qualcomm.com>, EAI WG <ima@ietf.org>
Subject: Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: barryleiba@computer.org
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2009 22:49:39 -0000

> (As the responsible AD) After rereading various pieces of the document, I
> agree this is not clear.
>
>
> (As a WG participant) Here is my understanding how things should work:
>
> UTF8=USER is useful by itself, so I think it should be independent of all
> other UTF8* capabilities. For example it should be possible to only support
> UTF8=USER (non EAI IMAP server, but which accepts UTF-8
> usernames/passwords), or support all other EAI functions, without supporting
> UTF-8 username/password (e.g. a legacy authentication database).
>
> I think UTF8=APPEND should be independent of other UTF8* capabilities.
> Allowing for EAI APPEND might require quite a bit of extra work.
>
> Both UTF8=ALL and UTF8=ONLY are related to UTF8 capability. We can either
> define them as implying UTF8, or say that if one of them is advertised, then
> UTF8 MUST also be advertised. Moreover, I think UTF8=ONLY implies UTF8=ALL.
> One can also argue that UTF8=ONLY implies UTF8=APPEND. I would be Ok either
> way, but one way or another this needs to be stated explicitly.

The more I think about it, the more I think that having a "UTF8"
capability string as well as "UTF8=xxx" strings creates a confusing
situation, particularly when one or more of the others implies the
former.  Here's what I suggest:

Define the capability as "UTF8=x,y,z", where the bit after the "="
(let's call them "UTF8 subcapabilities") can be some combination of
ACCEPT, APPEND, USER, ALL, and ONLY.  Put this definition into a
section that goes between the current sections 2 and 3, and say that
the UTF8 subcapabilities are defined in the sections below, and that
some of them may imply others.

Note, too, that this does not extend the grammar for capability
strings.  RFC 3501 defines "capability" to be "atom", and the ","
character is permitted in an atom.  it may require a small tweak to
the registry, though.

Now, section 3 (now section 4) will start with this:

   4. "ACCEPT" UTF8 Subcapability

   The "ACCEPT" UTF8 subcapability indicates the server supports UTF-8
   quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8
   responses from the LIST and LSUB commands.

The old section 3.1 gets this change:

   string sent by the client.  When the IMAP server advertises the
   "ACCEPT" UTF8 subcapability, it informs the client that it supports
   native UTF-8 quoted-strings with the following syntax:

...and so on, for the other instances of "UTF8 capability".
References to "the UTF8=ALL capability" would similarly change to 'the
"ALL" UTF8 subcapability', and so on.

And we add this:

   The "ACCEPT" UTF8 subcapability may be specified on its own, or
   with any combination of other subcapabilities.  It is implied
   by the "ALL" and "ONLY" subcapabilities, and MAY be omitted in
   the presence of one of those.


In '5. "APPEND" UTF8 Subcapability', we add this:

   The "APPEND" UTF8 subcapability may be specified on its own, or
   with any combination of other subcapabilities.  It is implied
   by the "ONLY" subcapability, and MAY be omitted in the presence
   of "ONLY".

In '6. "USER" UTF8 Subcapability', we add this:

   The "USER" UTF8 subcapability may be specified on its own, or
   with any combination of other subcapabilities.  It is not implied
   by any of the other subcapabilities.

In '7. "ALL" UTF8 Subcapability', we add this:

   The "ALL" UTF8 subcapability may be specified on its own, or
   with any combination of other subcapabilities.  It is implied
   by the "ONLY" subcapability, and MAY be omitted in the presence
   of "ONLY".

   The "ALL" UTF8 subcapability implies the "ACCEPT" subcapability,
   and "ACCEPT" MAY be omitted in the presence of "ALL".

In '8. "ONLY" UTF8 Subcapability', we add this:

   The "ONLY" UTF8 subcapability may be specified on its own, or
   with any combination of other subcapabilities.  It implies the
   "ACCEPT", "APPEND", and "ALL" subcapabilities, and those MAY
   be omitted in the presence of "ONLY".

We might add examples, such as these:
   UTF8=ACCEPT,USER,APPEND
   UTF8=ACCEPT,ALL
   UTF8=ALL       ; Note, same as above
   UTF8=ACCEPT,USER,APPEND,ALL,ONLY
   UTF8=USER,ONLY ; Note, same as above

---

I think this makes everything clear and easy to parse.

Comments?

Barry