RE: [lemonade] LEMONADE vs. P-IMAP

[<Zoltan.Ordogh at nokia.com>]

Hi Ben,

>It makes no difference at all to the point I was making: 
>whether it's a client based on any particular draft of P-IMAP, 
>or Lemonade compliant to some level, the point is still true: 
>a Symbian application doesn't need to be concerned with the 
>complexities of receiving an MMS or SMS; that's all dealt with 
>by the platform.
True indeed - I did not wish to engage in discussions on the
notifications, I was merely curious what You mean by "PIMAP client".

>However, to address your point: the Workgroup status page
>(http://tools.ietf.org/wg/lemonade/) references 
>http://tools.ietf.org/wg/lemonade/draft-maes-lemonade-p-imap-12.txt,
>which is "a recommendation for interoperable intermediate 
>implementations awaiting 
>draft-ietf-lemonade-profile-bis-xx.txt" and "the P-IMAP 
>specifications are expected to further converge towards the 
>profile".  Right now, a feasible way to implement a client is 
>to implement it so that it supports P-IMAP, which overlaps 
>with many parts of the Lemonade profiles.  The client can then 
>track the implementation of Lemonade compliance in commercial 
>servers whilst also generating revenue from the installed base 
>of users of those existing P-IMAP servers.
>So yes, there are differences between Lemonade (as expressed 
>in the profile-bis-xx documents) and P-IMAP (as expressed in 
>draft-maes-lemonade-p-imap-xx), but there's more than enough 
>overlap to allow a client to progress towards supporting both. 
> After all, a good general-use client will follow the 
>capabilities of the server, and XPIMAPvX is just a way for a 
>server to declare that it supports a particular set of 
>capabilities; for example, XPIMAPv1r2 means that the server 
>supports PIMAP version 1.2, which includes XPROVISION, 
>XSETPIMAPPREF, XGETPIMAPPREF, XDELIVER, XZIP, XCONVERT, 
>XVFOLDER, XENCRYPTED and BINARY and implies support for 
>LITERAL+.  We're working on a good general-use client, whose 
>first release will include support for servers that speak 
>P-IMAP.  As implementations of other Lemonade-originated 
>features appear in servers, support for those will be added 
>(actually, it's usually already in the client, but until it's 
>been tested with a real commercial implementation, it doesn't count).
>
>Anyway; P-IMAP isn't really proprietary, since the full 
>details are available and anyone could implement it!

Yes, certainly. Anyone can upload drafts and recommendations. Even me
about trash mailbox and move commands :-) but the fact that it is stored
in the repository of an IETF working group does not make it a standard.
Becoming an RFC does.
Please do not get me wrong - I am not saying that P-IMAP is bad - I am
simply saying that it is not a standard.
I have already seen quite a few confused people both internally and
externally - they are talking about P-IMAP and implementing LEMONADE
(and vice versa) -, so my goal here was to clarify that You indeed are
talking about a P-IMAP-based client.

And then again I wonder (per Ned's email about what is in the scope of
the charter and what is not) if P-IMAP actually falls into the charter
since both LEMONADE and P-IMAP intends to solve the exact same problem
with different specs. My history is quite short in IETF, so please
forgive my ignorance but I have to ask: Is it a tradition in IETF to
provide two solutions for the same problem? The answers I got regarding
the move command/trash proposals did not back up this theory. Makes me
wonder... Could someone actually clarify the intention with P-IMAP?
Someone with a lot of experience in this WG, please? Is it going to:
become a standard, is it going to become a separate WG in IETF, etc -
and when exactly.
Thank You.

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade