Re: [apps-discuss] Extentions of IMAP4

luyan@zte.com.cn Fri, 22 July 2011 08:27 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 9291C21F85B8 for <apps-discuss@ietfa.amsl.com>; Fri, 22 Jul 2011 01:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.736
X-Spam-Level:
X-Spam-Status: No, score=-99.736 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 UoI0bLTv-r7b for <apps-discuss@ietfa.amsl.com>; Fri, 22 Jul 2011 01:27:19 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E46B221F8540 for <apps-discuss@ietf.org>; Fri, 22 Jul 2011 01:27:18 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641193944097; Fri, 22 Jul 2011 16:25:29 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.3634574820; Fri, 22 Jul 2011 16:12:39 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6M8CXIU009648; Fri, 22 Jul 2011 16:12:33 +0800 (GMT-8) (envelope-from luyan@zte.com.cn)
In-Reply-To: <9031.1311243581.256116@puncture>
To: Dave Cridland <dave@cridland.net>
MIME-Version: 1.0
X-KeepSent: C24805BE:30C38C8A-482578D5:002C72D9; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OFC24805BE.30C38C8A-ON482578D5.002C72D9-482578D5.002D5311@zte.com.cn>
From: luyan@zte.com.cn
Date: Fri, 22 Jul 2011 16:12: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-22 16:15:03, Serialize by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-22 16:15:03, Serialize complete at 2011-07-22 16:15:03, S/MIME Sign failed at 2011-07-22 16:15:04: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-22 16:12:36, Serialize complete at 2011-07-22 16:12:36
Content-Type: multipart/alternative; boundary="=_alternative 002D530F482578D5_="
X-MAIL: mse02.zte.com.cn p6M8CXIU009648
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: Fri, 22 Jul 2011 08:27:20 -0000

Dear Dave Cridland,

Thank you for your comments. Please see our reply in-line.

Regards,

Yan LU

Dave Cridland <dave@cridland.net> 写于 2011-07-21 18:19:41:

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

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

User--+--Identity1---+---INBOX
      |         | 
      |         +--- SENTBOX
      |                |
      |         +--- OTHER FOLDERS
      | 
      | 
      +--Identity2---+---INBOX
                       | 
                       +--- SENTBOX
                       |
                       +--- OTHER FOLDERS


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


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

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

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