Re: [apps-discuss] Extentions of IMAP4

[[e-mail]]

> On Fri Jul 22 09:12:35 2011, [e-mail] 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:[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.