Re: [apps-discuss] Extentions of IMAP4

Dave Cridland <dave@cridland.net> Fri, 22 July 2011 10:16 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 2E04321F8509 for <apps-discuss@ietfa.amsl.com>; Fri, 22 Jul 2011 03:16:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level:
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 uygIWs74fP0u for <apps-discuss@ietfa.amsl.com>; Fri, 22 Jul 2011 03:16:24 -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 60D8F21F84DD for <apps-discuss@ietf.org>; Fri, 22 Jul 2011 03:16:15 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 5D8001168067; Fri, 22 Jul 2011 11:16:14 +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 FCNffpzShip2; Fri, 22 Jul 2011 11:16:10 +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 207C11168087; Fri, 22 Jul 2011 11:16:10 +0100 (BST)
References: <OFC24805BE.30C38C8A-ON482578D5.002C72D9-482578D5.002D5311@zte.com.cn>
In-Reply-To: <OFC24805BE.30C38C8A-ON482578D5.002C72D9-482578D5.002D5311@zte.com.cn>
MIME-Version: 1.0
Message-Id: <9031.1311329770.120161@puncture>
Date: Fri, 22 Jul 2011 11:16:10 +0100
From: Dave Cridland <dave@cridland.net>
To: "luyan@zte.com.cn" <luyan@zte.com.cn>, General discussion of application-layer protocols <apps-discuss@ietf.org>, "ding.xin@zte.com.cn" <ding.xin@zte.com.cn>, "jiaxw9@chinaunicom.cn" <jiaxw9@chinaunicom.cn>, "SHIH, JERRY \(ATTSI\)" <JS9053@att.com>
Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8Bit
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: Fri, 22 Jul 2011 10:16:25 -0000

On Fri Jul 22 09:12:35 2011, luyan@zte.com.cn wrote:
> [Yan LU] The intention of this draft is to associate multiple  
> identities
> belonging to one user. Thus, after logging in, the user may choose  
> one of
> these associated identities, under each of which there can be an  
> INBOX, a
> SENTBOX and other folders, as shown in the following figure.

OK. In the SASL model, an authentication identifier can have access  
to many authorization identifiers already; so no change is needed  
here.

> > > 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.
> >
> >
> 
> [Yan LU] The reason why we submitted these two drafts separately is  
> that
> the first one can take effect even without implementing the second  
> one. As
> you mentioned, for the second one, the issue can be implemented with
> multiple connections. But from the perspective of the user, it will
> improve the user experience if the user does not have to log in for
> several times.
> 
> Let us focus on the multiple-connection solution. First of all, it  
> will
> increase the burden of the network. Secondly, without the first  
> draft, the
> user has to log in for multiple times to establish all the  
> connections,
> which I don't think is a good idea. With the first draft, why not  
> just
> establish one connection for all associated identities?
> 
> 
Mostly because you're not - you're associating authorization  
identities sequentially, rather than concurrently.

You could build on namespaces, incidentally, to achieve much the same  
goal, by simply defining a standard method for locating other  
authorization identifiers' INBOXes.

But allowing a user to switch authorization identifier mid-flow will  
almost certainly introduce some complex edge-cases within security -  
I've a strong feeling that this opens up possibilities for TOCTOU  
errors.

> [Yan LU] I agree with you that server-initiated commands can be
> complicated. The intention of this draft is to try to find a way  
> for the
> server to terminate session actively. I am wondering if the BYE  
> response
> can be sent out without corresponding to any previous command from a
> client. Could you provide more details?

Technically, you are able to send almost any response at any time.

Use of BYE in this way is discussed in RFC 3501 §7.1.5, and RFC 3501  
§3.4 discusses servers unilaterally closing connections.

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