Re: [apps-discuss] Extentions of IMAP4

[[e-mail]]

Dear Dave Cridland,

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

Regards,

Yan LU

Dave Cridland <[e-mail]> 写于 2011-07-21 18:19:41:

> On Thu Jul 21 10:40:25 2011, [e-mail] 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:[e-mail] - xmpp:[e-mail]
>   - 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.