Re: [apps-discuss] Extentions of IMAP4

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

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