Re: [apps-discuss] Extentions of IMAP4

Dave Cridland <dave@cridland.net> Thu, 21 July 2011 10:20 UTC

Return-Path: <dave@cridland.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C098C21F88B7 for <apps-discuss@ietfa.amsl.com>; Thu, 21 Jul 2011 03:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0l6KH+HY4Sj8 for <apps-discuss@ietfa.amsl.com>; Thu, 21 Jul 2011 03:20:00 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 63CCF21F86DF for <apps-discuss@ietf.org>; Thu, 21 Jul 2011 03:20:00 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id F145D1168087; Thu, 21 Jul 2011 11:19:57 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N4iCUZPY3LS; Thu, 21 Jul 2011 11:19:41 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 452D61168067; Thu, 21 Jul 2011 11:19:41 +0100 (BST)
References: <OF4F51A3D2.3CA76CBD-ON482578D4.0034CD7E-482578D4.00355DBD@zte.com.cn>
In-Reply-To: <OF4F51A3D2.3CA76CBD-ON482578D4.0034CD7E-482578D4.00355DBD@zte.com.cn>
MIME-Version: 1.0
Message-Id: <9031.1311243581.256116@puncture>
Date: Thu, 21 Jul 2011 11:19:41 +0100
From: Dave Cridland <dave@cridland.net>
To: "luyan@zte.com.cn" <luyan@zte.com.cn>, "jiaxw9@chinaunicom.cn" <jiaxw9@chinaunicom.cn>, "SHIH, JERRY \(ATTSI\)" <JS9053@att.com>, "ding.xin@zte.com.cn" <ding.xin@zte.com.cn>, General discussion of application-layer protocols <apps-discuss@ietf.org>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [apps-discuss] Extentions of IMAP4
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2011 10:20:04 -0000

On Thu Jul 21 10:40:25 2011, luyan@zte.com.cn wrote:
> https://datatracker.ietf.org/doc/draft-jia-imap-multiaccount-authentication/

This one is distinctly hand-wavey, to the extent I have no clear idea  
what it means.

I *think* it means to say that multiple authzids may be associated  
with a single authentication identifier, and these may be active  
concurrently - what this in turn means in terms of, for example, what  
"INBOX" now means is beyond me, though.


> https://datatracker.ietf.org/doc/draft-lu-imap-multi-account/

This one appears to build on the above, except it, too, confuses  
authentication and authorization.

I'm reasonably convinced that the first draft is entirely redundant,  
and this one's utility is limited. In particular, it's not clear to  
me why you'd want this instead of just using multiple authentication  
identifers and multiple connections, and no rationale is given in the  
document.


> https://datatracker.ietf.org/doc/draft-shih-imap-server-logout/

IMAP4rev1 already allows servers to unilaterally terminate the  
session with a * BYE. Introducing server-initiated commands is far,  
far beyond a simple draft like this.

A sensible alternative would be to have servers issue a different  
untagged response (* TERMINATE, perhaps?) in order to encourage  
clients into logging out quickly, if we want to have a more graceful  
termination of client sessions. This would need to be signalled with  
an ENABLE, though.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade