Re: [apps-discuss] Extentions of IMAP4

[[e-mail]]

> 
> --On Friday, July 22, 2011 11:16 +0100 Dave Cridland
> <[e-mail]> wrote:
> 
> > 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.
> 
> Let me add one much more general observation to Dave's specific
> ones:
> 
> IMO, IMAP is arguably already much too big and too complicated,
> at least partially due to the addition of features that provide
> different ways to do the same thing.  In principle, adding more
> optional features should not be a problem, but they make it very
> hard for a user to predict what will be available from different
> combinations of clients and servers.  That situation, in turn,
> makes easy movement among clients on multiple devices less
> likely and more difficult.
> 
> The LEMOMADE effort was supposed to improve on that situation.
> As far as I can call, it did not succeed in that particular
> goal; some would claim it made things worse.
> 
> To me, the best evidence for "much too big and too complicated"
> is the very small number of available, well-designed, IMAP
> clients that are fully-conformant to the protocol and up-to-date
> on the majority of current features and extensions.  Some years
> ago, an important contributor and developer of IMAP and other
> email protocols observed that "all IMAP clients suck, <xxx>
> sucks less than the others" (name omitted to avoid a distracting
> side discussion).   If one adds the criterion that they be
> tracking the efforts in the EAI WG that will require
> modifications for, e.g.,  non-ASCII addresses, the number goes
> down even further.
> 
> So, for whatever it is worth, I think the community should be
> looking only at additional IMAP changes and extensions for which
> there is a compelling need for a large number of users -- a need
> that is compelling enough that we can assume that a large
> fraction of client and server implementers will actually support
> the proposed feature.   I believe the EAI i18n changes meet that
> criterion.  These two proposals do not, not just for the reasons
> Dave mentions, but because we haven't seen much evidence a huge
> number of such users, because there are other ways around the
> issue in IMAP (as Dave notes), and because a slightly different
> organization of mailboxes and folders on the server (and a
> competent client) can accomplish almost exactly the same thing
> without any protocol changes at all.   I have some evidence for
> the latter: I've been doing things that way, with standard IMAP
> (and without a requirement for any of the very recent
> extensions), for 15 years or so now.
> 

[Yan LU]Well, as the members of OMA, we are focusing on services provided 
for the normal users. Market needs are driving us to propose these drafts. 
Furthermore, we have encountered issues since this feature has not been 
supported by IETF yet. I can provide some examples.
1)According to OMA CPM (Converged IP Messaging) specifications, a CPM 
client consists of a SIP client and a IMAP4 client, and a CPM user will 
use SIP client to realize communications of various forms, e.g. instant 
message, multimedia call or file transfer; a CPM user will also use IMAP4 
client to manage conversation history recorded during the communications. 
The CPM Group introduced 3GPP implicit registration into CPM,that is to 
say, when a user is registered, he/she only has to be registered once for 
his multiple identifiers. After registration, he can choose and use any of 
these identifiers freely. Unfortunately, the user has to log in for 
several times when he/she accesses his storage server. To make it even 
worse, although a user can switch his multiple identifiers when he/she 
communicates with others (using SIP ), he can only use one identifier to 
manage the stored conversation history (using IMAP4). We hope we can 
provide the same user experience in these two procedures.
2)Now we meet the same problem in OMA EVVM. 
3)This feature can be used in some kind of converged email services.It is 
quite possible that one user can have multiple internet email addresses. 
As far as I know, China Telecom has already released their enterprise 
standard in which a mobile user with a IMAP4 client can connect with a 
IMAP4 proxy to access multiple email accounts.

>     john
> 
> 


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