Re: [apps-discuss] Extentions of IMAP4

luyan@zte.com.cn Tue, 26 July 2011 09:29 UTC

Return-Path: <luyan@zte.com.cn>
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 5ED4021F8C19 for <apps-discuss@ietfa.amsl.com>; Tue, 26 Jul 2011 02:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.538
X-Spam-Level:
X-Spam-Status: No, score=-101.538 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
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 N-94VprP1lLF for <apps-discuss@ietfa.amsl.com>; Tue, 26 Jul 2011 02:29:21 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFC121F8C16 for <apps-discuss@ietf.org>; Tue, 26 Jul 2011 02:29:20 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131321193944097; Tue, 26 Jul 2011 17:20:29 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.3634574820; Tue, 26 Jul 2011 16:36:39 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6Q8aVSF043542; Tue, 26 Jul 2011 16:36:31 +0800 (GMT-8) (envelope-from luyan@zte.com.cn)
In-Reply-To: <9031.1311329770.120161@puncture>
To: Dave Cridland <dave@cridland.net>
MIME-Version: 1.0
X-KeepSent: 39FC2C3F:DFBBB156-482578D9:002E6203; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF39FC2C3F.DFBBB156-ON482578D9.002E6203-482578D9.002F850F@zte.com.cn>
From: luyan@zte.com.cn
Date: Tue, 26 Jul 2011 16:36:35 +0800
X-MIMETrack: S/MIME Sign by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-26 16:39:02, Serialize by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-26 16:39:02, Serialize complete at 2011-07-26 16:39:02, S/MIME Sign failed at 2011-07-26 16:39:02: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-26 16:36:33, Serialize complete at 2011-07-26 16:36:33
Content-Type: multipart/alternative; boundary="=_alternative 002F850C482578D9_="
X-MAIL: mse02.zte.com.cn p6Q8aVSF043542
Cc: "SHIH, JERRY \(ATTSI\)" <JS9053@att.com>, "jiaxw9@chinaunicom.cn" <jiaxw9@chinaunicom.cn>, "ding.xin@zte.com.cn" <ding.xin@zte.com.cn>, General discussion of application-layer protocols <apps-discuss@ietf.org>
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: Tue, 26 Jul 2011 09:29:22 -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.
> 

[Yan LU] As we know, implicit registration has already been supported in 
3GPP IMS. However,so far, I haven’t found any RFCs where an 
authentication identifier is allowed to be bound with multiple identifiers
. Could you tell me the specific documents?

> > > > 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] Actually, the idea in the proposed draft is quite similar with 
implicit registration in 3GPP, where it has already been standardized. So, 
we think it is better for the IETF to support the same mechanism.


> > [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.
> 
[Yan LU] I have to admit I neglected these descriptions. I believe BYE can 
meet our requirement. Thanks for the information.

> 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
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.