Subject: RE: [lemonade] extended error reporting

From: Randall Gellens <[email-masked]>
Date: Sat, 1 Dec 2007 19:09:46 -0800

At 2:33 PM -0800 11/26/07, Mark Crispin wrote:

>  Saying "it will reduce service calls" is like saying "it's for the 
> children".  Such statements are nothing more than strawmen to 
> stifle debate ("you want there to be more service calls, you evil 
> person you").

I think it is possible to disagree as to if a change will reduce 
service calls without saying that all such arguments are fallacies.

>  The only situation in which error messages to the end user are 
> useful are when the end user can do something about the condition.

Or in the case of a temporary failure, if the error message clearly 
says something along the lines of "Oops!  This can't be done just at 
the moment.  Please try again later <or even 'in ten minutes'>."

Separately from the question of end user behavior is the issue of 
client behavior.  If a client should behave differently, such as 
retrying the exact same command later, or giving up, then different 
error responses are useful.

If neither the client nor the end user is likely to behave 
differently, then there isn't a lot of benefit to different error 
responses other than debugging.

>>  and I see the demand for two tier
>>  storage, and the like increasing rather than decreasing.
>
>  Who?  Where?

It does seem that IT departments are fond of email management systems 
that give IT extreme control over email, such as the ability to move 
messages to secondary storage based on their own criteria, as well as 
permanently delete or prevent the deletion of messages.  Needless to 
say, a lot of this sort of functionality violates the way IMAP works, 
and some of it could be better accomplished within IMAP (such as 
using different mailboxes).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
1.  People to whom you are attracted invariably think you
    remind them of someone else.
2.  The love letter you finally got the courage to send will
    be delayed in the mail long enough for you to make a fool
    of yourself in person.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Sat, 1 Dec 2007 22:09:00 -0800 (PST)

On Sat, 1 Dec 2007, Randall Gellens wrote:
>>  The only situation in which error messages to the end user are useful are 
>> when the end user can do something about the condition.
> Or in the case of a temporary failure, if the error message clearly says 
> something along the lines of "Oops!  This can't be done just at the moment. 
> Please try again later <or even 'in ten minutes'>."

I hope that nobody seriously suggests that IMAP start issuing such errors 
for FETCH or even URLFETCH.

> If neither the client nor the end user is likely to behave differently, then 
> there isn't a lot of benefit to different error responses other than 
> debugging.

My point exactly.  We should not add new error responses unless they lead 
to different behavior from a client or end user.

> It does seem that IT departments are fond of email management systems that 
> give IT extreme control over email, such as the ability to move messages to 
> secondary storage based on their own criteria, as well as permanently delete 
> or prevent the deletion of messages.  Needless to say, a lot of this sort of 
> functionality violates the way IMAP works, and some of it could be better 
> accomplished within IMAP (such as using different mailboxes).

Which is why Exchange and outsource webmail is rapidly replacing IMAP 
everywhere.  One of the reasons why I am trying to calm down this mad rush 
to add unbounded new features to IMAP is that much of this effort seems to 
be a waste that will only hasten IMAP's demise.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Peter Coates <[email-masked]>
Date: Sat, 01 Dec 2007 23:10:37 -0800

There is a good error reporting mechanism in CONVERT.  And there it is
called for as all sorts of things can be wrong.  URLFETCH has no error
reporting mechanism.  URLs can request conversion, so the same sorts of
errors than can occur in CONVERT can occur in URLFETCH.  That seems just
plain wrong to me.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
Crispin
Sent: December 1, 2007 22:09
To: Randall Gellens
Cc: Peter Coates; [email-masked]; 'Ned Freed'
Subject: RE: [lemonade] extended error reporting

-- Mark --

http://panda.com/mrc

---

From: Ned Freed <[email-masked]>
Date: Sun, 02 Dec 2007 07:13:41 -0800 (PST)

> to different behavior from a client or end user.

But if that's the case then we should consider adding them if a case can be
made (and IMO it has been) that the added information will change behavior.

> be a waste that will only hasten IMAP's demise.

OK, so let me see if I have this right. Because of various missing
functionality in IMAP people are moving in droves to other solutions with
better functionality. And the way to solve this is by keeping IMAP "pure" and
not adding the features users are demanding to it?

More generally, conspicuously missing from what most people seem to want these
days is a desire for things to be simple, especially when that means less
capable. Those same droves are also delightedly writing and deploying stuff
based on AJAX, JSON, increasingly elaborate web services, and using toolkits
designed around object models so complex that their own designers cannot
explain them. This stuff is all vastly more complex than anything proposed for
IMAP.

This is not to say simpler isn't better. It is. (That's why I've been
advocating using a capabilities response to indicaate what's enabled - it's the
simpler way to do it.) But there's a point past which simplicity is no longer a
virtue.

We need to follow Einstein's advice and keep things as simple as possible, but
no simpler. If we can offer a ways for people to do the stuff they want to do
but still keep the protocols as clean and simple as possible we have a valid
value proposition here. (OK, OK, so this ignores marketing. But that's outside
our area of competence.)

				Ned

---

From: Mark Crispin <[email-masked]>
Date: Sun, 2 Dec 2007 09:18:16 -0800 (PST)

> not adding the features users are demanding to it?

No.  People are moving away to other solutions because IMAP is too damn 
complicated.  The big vendors refuse to implement even all of the base 
specification, much less all of these bizarre extensions.

-- Mark --

http://panda.com/mrc

---

From: Ned Freed <[email-masked]>
Date: Sun, 02 Dec 2007 10:37:08 -0800 (PST)

> complicated.

I'm sorry, but I think this is quite simply wrong. As I pointed out, people
have zero problem embracing vastly more complex solutions on both the client
and the server, and indeed the things pepople are switching to from IMAP are
almost without exception far more complex than IMAP.

  The big vendors refuse to implement even all of the base
> specification, much less all of these bizarre extensions.

But the reason for that is that they don't see any reason to implement those
things. And this is a real problem: How do you get a vendor who believes
certain parts of IMAP aren't useful to them to do the right thing and
implement them anyway?

I think the only solution to this problem that's available to us is to make the
entire IMAP story more attractive. And that means adding additional
capabilities people want. By making the overall IMAP story more appealing we
broaden the user base. And if that broader user base runs into issues with some
vendors not implementing stuff they will exert pressure on those vendors to
clean up their act. That's pressure we cannot possibly apply ourselves.

But regardless, it definitely isn't helping that IMAP is seen as not offering
sufficient value in its present form. You cannot solve the problem of getting
complete implementations when there's nothing compelling to keep people using
IMAP.

In fact I'll go so far as to say that if anything is going to kill IMAP it is
this continued intransigence towwards enhancements.

				Ned

---

From: Randall Gellens <[email-masked]>
Date: Sun, 2 Dec 2007 11:00:48 -0800

At 10:23 AM +0000 11/27/07, Dave Cridland wrote:

>>>  Taking this specific example, mobile devices aren't always aware 
>>> of the correct time, and a client trying to generate, then use 
>>> (via BURL) an IMAP URL which has a tight expiration is perfectly 
>>> capable of finding a largely opaque error coming back from the 
>>> submission server, purely because the clock is wrong. (And 
>>> sometimes, it's wrong because the GSM network is helpfully 
>>> broadcasting the wrong time).
>>
>>  That scenario suggests that the correct protocol fix is to have a 
>> relative expiration date/time for the client doing the GENURLAUTH, 
>> and have the returned URLAUTH replace that relative expiration 
>> date/time with an absolute value.  For example,
>
>  Well, I'm not sure that helps, and more importantly I suspect that 
> this would be a more radical change than Peter's proposal anyway. 
> BURL/URLAUTH are deployed technologies [ie, not just Polymer], and 
> the simplest way of handling this deficiency without breaking 
> existing implementations would be to have the BURL command produce 
> more useful diagnostics.

Just playing Devil's Advocate, but if the problem is that the client 
is on a device that has the wrong time, and hence the client 
calculated an expiration time that has already passed or is otherwise 
not far enough in the future to be useful, a detailed error message 
would only help the developer, not the end user (unless the 
time-to-expiration is user-settable, which would probably not be 
something most users would understand).

I suppose you could code the client so that if it gets the detailed 
error report from a BURL extended response code, it could react by 
automatically increasing the expiration time.  But that seems 
difficult.

A relative expiration time in the GENURLAUTH does seem simpler in this example.

>  Besides which, there are other cases, including any case which 
> involves server-side manipulation of a body part during the 
> URLFETCH. My proposal of BINARY-mode is one such (consider bogus 
> base64), and any similar proposal involving CONVERT-in-URLFETCH.

Yes, this makes sense.

-------------- Randomly-selected tag: ---------------
Corollaries:
    1.  Nobody whom you ask for help will see it.
    2.  The first person who stops by, whose advice you really
        don't want to hear, will see it immediately.

---

From: Mark Crispin <[email-masked]>
Date: Sun, 2 Dec 2007 11:16:27 -0800 (PST)

> almost without exception far more complex than IMAP.

Why does Exchange not implement any of the optional facilities of the base 
specification, much less any extensions?

Why does Gmail not implement all of the mandatory facilties of the base 
specification, much less any extensions?

If you want to fix IMAP to add the functionality that people really want, 
you need to have things as contact management, task management, and 
calendaring.  The IETF has failed miserably on all points.

Nobody cares about email-only applications any more.  Email is a small 
part of the overall picture, yet you guys are focusing on how to create 
the Email Protocol From Hell.  Not only that, but email itself is a dying 
means of communication, and you can't blame IMAP for that.

-- Mark --

http://panda.com/mrc

---

From: Ned Freed <[email-masked]>
Date: Sun, 02 Dec 2007 11:23:40 -0800 (PST)

> specification, much less any extensions?

Now you're changing the subject, which was whether or not protocol simplicity
is seen as a virtue, not whether or not some alternative solution chooses to
implement some part of the IMAP base.

So let's consider Outlook/Exchange. Have you looked at the protocol they use to
talk to each other? IMAP is simplicity personified by comparison.

> specification, much less any extensions?

Same response: Have you looked at the complexity of the web pages and such
gmail uses? 

Now, as for the question of why they don't implement certain parts of the base
specification, I already answered that in my previous message.

> calendaring.  The IETF has failed miserably on all points.

I agree 100% that people want this functionality and providing a
standards-based way to get it has to be part of our overall value proposition.
But people do not care in the slightest if it is provided by IMAP or by some
other protocol. They just want it to work.

I also agree that the IETF's history in the area is nothing short of dismal. We
defined both an addressbook and calendar format but then let both of them lie
fallow for much too long (vCard especially) and did nothing useful in the area
of defining protocol level access to them. (Yes, I'm well aware of the ICAP
work, but I stand by my assessment.)

But this is finally starting to change. Soon we'll have caldav and carddav and
ical is being cleaned up. I think vCard is going to be a tougher nut to crack,
but I think it can be done.

The real question is whether it can happen in time. But one things for sure:
Sitting around wringing our hands and moaning about unnecessary complexity
isn't helping.

> the Email Protocol From Hell.

No, we're trying to add the capabiites to email that it needs in order to
survive as a useful component of a much larger set of colaborative tools. The
fact that there are lots of problems that cannot be solved by email is not a
reason to ignore the subset of problems that can be solved through email.

> Not only that, but email itself is a dying

And therefore we should leave it along and let it die in peace? I'm sorry,
but this is nothing short of absurd.

				Ned

---

From: Mark Crispin <[email-masked]>
Date: Sun, 2 Dec 2007 12:18:12 -0800 (PST)

On Sun, 2 Dec 2007, Ned Freed wrote:
> The real question is whether it can happen in time.

I don't think that it will.

> But one things for sure:

Nor does it help to add complexity that is not widely implemented.

I have had vendors (note the plural) tell me that they are NOT going to do 
the trio, and that their mobile device strategy does not involve Lemonade 
(or much of IETF).

> survive as a useful component of a much larger set of colaborative tools.

I don't see how the current set of extensions, much less all the stuff 
that is being proposed for addition now, in any way assists in that goal.

Extensions by their very nature are flawed.  A client implementor can not 
rely upon a server offering it; nor can a client necessarily assume that 
the extension will be correctly implemented by the server even if it is 
offered.

Case in point: METADATA, which was ANNOTATEMORE, which was the less 
wide-eyed way of doing ANNOTATE.

I can't imagine building a new messaging product that uses anything but 
the most basic aspects of IMAP.  In fact, a POP3 that had the POP2 FOLD 
command would do equally as well.  There's just too much deployed software 
that doesn't even do the base specification right.

Yes, it was a cool idea to have the server do header/MIME parsing; I use 
that capability all the time and love it.  But it has been so badly 
misimplemented (especially in MIME parsing) that no client can reasonably 
rely upon it.

And now you claim that servers will do complex conversions correctly?  I 
am deeply skeptical.  I have good reason.

> but this is nothing short of absurd.

Blaming me, one person, for "killing IMAP by obstructing progress" is what 
is absurd.  I can't obstruct anything.

Like it or not, few people under 30 use email as a daily tool, especially 
the under-25s.  I don't see how any of this addresses that problem.

You're adding complexity in an attempt to keep email from dying.  I don't 
see any clear or coherant plan to save email, rather a frantic effort to 
try every possible notion in the hope that one of them works.

Letting it die in peace be the best thing.  We should instead think about 
what is replacing email and what we can contribute to that technology 
based upon the lessons that we learned from 35 years of email and news.

Or, rather, we should think about what will replace email; I think that 
the technology that will put the final nail in email's coffin hasn't shown 
itself yet.  But it is coming.

-- Mark --

http://panda.com/mrc

---

From: Mark Crispin <[email-masked]>
Date: Sun, 2 Dec 2007 12:24:16 -0800 (PST)

On Sun, 2 Dec 2007, Ned Freed wrote:
> So let's consider Outlook/Exchange. Have you looked at the protocol they 
> use to talk to each other? IMAP is simplicity personified by comparison.

It's also a single-vendor protocol, and that vendor has absolute 
dictatorial power over it.  The protocol is thus architected towards a 
single, unified vision and purpose.  Such protocols can have considerable 
complexity yet retain their strength.

IETF protocols lack the luxury of a dictator who says "no" and whose word 
is unquestioned and final.  IETF protocols are a compromise between many 
conflicting factions.  The compromise frequently results in a bunch of 
cruft added to satisfy a small constituency and/or something that nobody 
really likes (IMAP hierarchy comes to mind).

Not that there aren't strengths to IETF protocols.  The strengths come in 
when the compromise process leads to cutting away cruft, especially cruft 
that is hard for some to implement.

IETF does a great job when it strives towards simplicity in all things, 
and it does a wretched job when it allows complexity to take over.

-- Mark --

http://panda.com/mrc

---

From: Ned Freed <[email-masked]>
Date: Sun, 02 Dec 2007 12:22:56 -0800 (PST)

> the trio, and that their mobile device strategy does not involve Lemonade

And I have had vendors tell me the exact opposite.

Indeed, the problem I hear over and over from the handset vendor types is that
to the extent they are unhappy with the IETF, it is because we're much too slow
and do much too little.

> that is being proposed for addition now, in any way assists in that goal.

Then with all due repect, you need to make the argument on that basis and do it
case by case.

What I'm objecting to is your assertion that simplicity is something people
value over other things. There are simply too many counterexmaples to this for
it to be in any way credible.

> the extension will be correctly implemented by the server even if it is

This is of course true for the Internet as a whole. But this misses a key
point: We're not talking about the Internet as a whole here. Rather, we're
talking about trying to solve a set of problems for a specific type of client
with specific limitations. Such clients usually operate in an environment
that's quite different than open Internet. In particular, it is often quite
reasonable in such environments to specify a minimum set of extensions.

This is sort of the point of having a LEMONADE profile, as a matter of fact.

> that doesn't even do the base specification right.

Well, perhaps you cannot imagine such a thing, but I can and more importantly
so can Sun. And Sun is acting on this by designing an entirely new product that
depends on many of the more advanced features of various protocols and their
extensions, including but not limited to IMAP.

I will also add that I'm am only tangentially involved with the project I'm
referring to and in particular I had basically no involvement in starting it.
This is all the work of people I doubt you've ever heard of, many of whom only
know the IETF as being "the place where RFCs come from". So this isn't a case
of drinking IETF koolaid, assuming we have any. Rather, it's a case of  people
wanting to solve a problem and find the current work the IETF is doing to be
useful to that end.

> am deeply skeptical.  I have good reason.

I don't recall making any such claim, but never mind that for now. Conversions
are kind of a special case in that there is often no "correct" way to do
a conversion. (X.400 even formalized this by defining conversion-with-loss.)
So the question for many conversions, especially the complex ones, is whether
what's producded is "good enough". 

In any case, I've actually been pleasantly surprised at how well complex
conversions work overall. And since I operate in what is effectively a
Microsoft-software-free environment and yet have to deal with the output of the
Office suite on a daily basis, this is not due to lack of use of such tools.

In other words, I'm actually cautiously optimistic about the ability to do
complex conversions properly.

> is absurd.  I can't obstruct anything.

Once again you're putting words in my mouth. But I see no point in pursuing
this so I'll let it pass.

> try every possible notion in the hope that one of them works.

No. Again, what we're doing is trying to solve a specific set of problems
a specific sort of client has. I am on record as opposing expansion of
this groups work to include activities that fall outside this limited scope.

Will this solve the "email is dying" problem? Of course not, but I can see
making email work really well on mobile devices as a part of such a solution.

> itself yet.  But it is coming.

Of that I have no doubt. Nothing is permanent. But I fail to see how any of
this doom and gloom is relevant to the matters at hand.

				Ned

---

From: Randall Gellens <[email-masked]>
Date: Sun, 2 Dec 2007 14:16:17 -0800

>  Nor does it help to add complexity that is not widely implemented.

I agree with this -- cool features that aren't widely implemented 
aren't much of a help, because a client can't count on them (and of 
course servers have little incentive to implement something that 
clients don't use).

>  I have had vendors (note the plural) tell me that they are NOT 
> going to do the trio, and that their mobile device strategy does 
> not involve Lemonade (or much of IETF).

This can't be much of a surprise to anyone -- given that multiple 
vendors have multiple "mobile email" solutions now, many of which use 
non-IETF protocols (except for perhaps HTTP), we can't have expected 
that they'd all drop their current offerings and switch to IMAP.

But for those that will use IMAP, we need to have the functionality they need.

>  Extensions by their very nature are flawed.  A client implementor 
> can not rely upon a server offering it; nor can a client 
> necessarily assume that the extension will be correctly implemented 
> by the server even if it is offered.

True, and this is especially bad with IMAP.  Which is one reason for 
lemonade: to have a collection of functionality, extensions, and 
server behavior under one name.  A mobile client might reasonably 
insist on a lemonade server, to avoid needing to implement multiple 
code paths for every variant, or offer different UI when some 
extensions aren't available.

>  Yes, it was a cool idea to have the server do header/MIME parsing; 
> I use that capability all the time and love it.  But it has been so 
> badly misimplemented (especially in MIME parsing) that no client 
> can reasonably rely upon it.
>
>  And now you claim that servers will do complex conversions 
> correctly?  I am deeply skeptical.  I have good reason.

A number of years ago, IMAP interoperability was exceedingly poor. 
The IMC IMAP bake-offs really helped a lot.  Some extensions that 
announce server behavior have also helped.  Such things can be done 
again.

>  You're adding complexity in an attempt to keep email from dying.  I 
> don't see any clear or coherant plan to save email, rather a 
> frantic effort to try every possible notion in the hope that one of 
> them works.

I don't see extended error reporting specifically to help with "the 
trio" and related lemonade stuff, which is really focused on mobile 
email, as a "frantic effort to try every possible notion."  I just 
don't see much franticness, and so far things have been focused on 
mobile email.

>  Or, rather, we should think about what will replace email; I think 
> that the technology that will put the final nail in email's coffin 
> hasn't shown itself yet.  But it is coming.

This is entirely separate from extensions to email.  When email is 
finally replaced, it won't be an overnight thing.  Something new 
starts getting used in its place, and over time email gets used less 
and less, perhaps it becomes a protocol for automated process, since 
they don't care.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
    The highlight of the annual Computer Bowl occurred when Bill Gates,
who was a judge, posed the following question to the contestants:
    "What contest, held via Usenet, is dedicated to examples of weird,
obscure, bizarre, and really bad programming?"
    After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple)
hit his buzzer and answered "Windows."
                                          --Recounted by Adam C. Engst

---

From: Randall Gellens <[email-masked]>
Date: Sun, 2 Dec 2007 14:19:43 -0800

At 12:24 PM -0800 12/2/07, Mark Crispin wrote:

>  IETF does a great job when it strives towards simplicity in all 
> things, and it does a wretched job when it allows complexity to 
> take over.

Yes, indeed.

It is often hard to determine what is really needed and what is 
cool-sounding cruft.  Hence the storied reliance on "running code." 
It is often that it only becomes apparent during implementation.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
All probabilities are 50%.  Either a thing will happen or it won't.
This is especially true when dealing with someone you're attracted to.

---

From: Randall Gellens <[email-masked]>
Date: Sun, 2 Dec 2007 14:16:17 -0800

---

From: Randall Gellens <[email-masked]>
Date: Sun, 2 Dec 2007 14:19:43 -0800

Yes, indeed.

---

From: Randall Gellens <[email-masked]>
Date: Sun, 2 Dec 2007 14:30:08 -0800

At 12:22 PM -0800 12/2/07, Ned Freed wrote:

>  value over other things.

Indeed, simplicity is only valued in the abstract.  When given a 
choice, people invariably choose the bells and whistles.  That's part 
of what makes protocol design and standards development hard: weeding 
out the complexity, and putting off to version 2 what can be left out.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Adding manpower to a late software project makes it later.
                -- Fred Brooks in _The Mythical Man Month_

---

From: Randall Gellens <[email-masked]>
Date: Sun, 2 Dec 2007 19:47:52 -0800

At 9:33 PM -0500 12/2/07, Darryl Champagne wrote:

>  One comment about this comment...
>
>  Saying that a lot of this sort of functionality violates the way IMAP works
>  doesn't really help - since there is an increasing amount of US Federal
>  legislation that wants it done that way.

Sure, which is why my remark about it being contrary to the way IMAP 
works was within a "needless to say" clause, by which I meant that it 
was obvious and also besides the point, and hence there was no need 
to say it (but I couldn't help myself from saying it anyway).

>   Many the corporate lawyer demands
>  that emails be deleted after a fixed amount of time (no matter how stupid
>  that actually is relative to productivity), to cut down on legal risk.

This can only be reliably done with client support (such as a plug-in 
to certain clients) and even then, the recipient may have forwarded 
the message, or copied it somewhere, or done something else to it 
(even printed it).  Thus, the original message might be securely 
deleted, but copies of it may exist in places that might be turned up 
by searches.

>  Similarly, once a subpoena has been received, there are all sorts of
>  restrictions on what can be deleted, which conflict with the desire to
>  auto-delete, meaning that backup tapes do not easily do what is needed.

A separate archive that is connected to the mail system via IMAP 
could do this.  It can make copies of all messages, and could either 
never delete anything, or permanently delete those items which are 
not under restriction, possibly triggered by deletion from the user's 
mailbox.

>  We may not like the functionality, but if the CIO could go to jail if that
>  functionality can't be achieved, then supporting it _is_ important, and the
>  ease in supporting it does matter for market share.

Sure.  But much of this could be done today by connecting to the mail 
store with IMAP.  Other functionality can't really be done, and what 
approximation of it can be done can only be done with tight controls 
on all clients that have access to the mail.  At that point it isn't 
really mail.  To be really sure, don't have any local cache, and 
don't permit forward, copy, or print.

The functionality of moving some messages to a secondary storage that 
takes time to access can even be done within the IMAP model by moving 
those messages to an archive mailbox (such as a mailbox corresponding 
to the original but under a different hierarchy).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Ninety percent of the politicians give the other ten percent a bad name.
                                                      --Henry Kissinger

---

From: "Darryl Champagne" <[email-masked]>
Date: Sun, 2 Dec 2007 21:33:03 -0500

legislation that wants it done that way.  Many the corporate lawyer demands

dgc

-----Original Message-----
...
Randall Gellens wrote:

---

From: "Darryl G. Champagne" <[email-masked]>
Date: Mon, 3 Dec 2007 20:16:40 -0500

Hi,
I do understand that all the examples listed (and far more) can be done (but
not easily interoperably!), and many of the ways to actually do them, and
the issues with printing, forwarding, and so on, but I was actually trying
to tie in with the comments about market share, other large products, and so
on...

E.g. - Mark's comments like: 
"If you want to fix IMAP to add the functionality that people really want,
you need to have things as contact management, task management, and
calendaring.  The IETF has failed miserably on all points.

Nobody cares about email-only applications any more.  Email is a small part
of the overall picture, yet you guys are focusing on how to create the Email
Protocol From Hell.  Not only that, but email itself is a dying means of
communication, and you can't blame IMAP for that. "

The thing is, if the big consumers of email (actually integrated messaging)
products require certain features, and they can only be done in custom ways
not supported/obvious by the core protocols, then the protocols themselves
aren't really meeting the existing needs, are they?  Email (etc.) is not
just for geeks anymore...

Right now, IMAP/Lemonade is an absolute bear to try and approach from the
outside.  I know how to address all this functionality in SyncML as well,
but it runs into similar issues, that non-experts don't see how, and thus it
ends up not being interoperable (and people outside of SyncML will happily
tell others how it can't be done).  The bare fact of the matter is that when
a large company assigns a group of non-subject experts to do something, they
don't see how to do what is needed with the existing stuff, and they do
their own thing, and usually everyone loses.

I don't know what direction is the best to go in, but either the protocols
have to have an interoperable way to do everything that is actually needed
in the real world, and/or they need to be simpler (or they gradually fade
away in relevance).  Really I was just objecting to the sentiment expressed,
in that it causes problems, not helps.

dgc

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Sunday, December 02, 2007 10:48 PM
To: Darryl Champagne
Cc: [email-masked]
Subject: RE: [lemonade] extended error reporting

...

---

From: Philip Van Hoof <[email-masked]>
Date: Fri, 07 Dec 2007 00:41:53 +0100

> means of communication, and you can't blame IMAP for that.

In the past people predicted the end of radio, news papers and called
for editors, radio hosts and radio DJs to start finding a new job.

And now Mark thinks that E-mail is going to die ...

Meanwhile, I'm pragmatically making E-mail work on mobiles.

And I'm going to keep doing that.

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be

---

From: Eric Burger <[email-masked]>
Date: Thu, 06 Dec 2007 16:58:31 -0800

Let us not forget that our success is from having a focus on the e-mail
*component* of unified communications systems.  That is what makes us
relevant in the new world.

> And I'm going to keep doing that.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.