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
- [apps-discuss] Extentions of IMAP4 luyan
- Re: [apps-discuss] Extentions of IMAP4 Dave Cridland
- Re: [apps-discuss] Extentions of IMAP4 luyan
- Re: [apps-discuss] Extentions of IMAP4 Dave Cridland
- Re: [apps-discuss] Extentions of IMAP4 John C Klensin
- Re: [apps-discuss] Extentions of IMAP4 luyan
- Re: [apps-discuss] Extentions of IMAP4 Dave Cridland
- Re: [apps-discuss] Extentions of IMAP4 luyan
- Re: [apps-discuss] Extentions of IMAP4 luyan