[prev in list] [next in list] [prev in thread] [next in thread] 

List:       imap
Subject:    Re: [Imap-protocol] [noob] select & unseen?
From:       Bron Gondwana <brong () fastmail ! fm>
Date:       2011-11-14 20:59:19
Message-ID: 20111114205919.GA5573 () brong ! net
[Download RAW message or body]

On Monday, November 07, 2011 8:52 AM, "Mark Crispin" <mrc+imap@panda.com> wrote:
> > Unfortunately, all these warts are required to be supported - and common sense
> > is a cop-out.
> 
> Lawyers insist upon a legalistic interpretation without any use of "what
> is intended here".

You get those.

> Engineering requires practical interpretations. Nobody gets anywhere with
> legalistic interpretations. Engineering requires cooperative problem
> solving.

Which is why everyone doesn't spit out anthing for "UNSEEN" when there is
nothing unseen even though the standard clarifies in two updates that they
really REALLY MUST.

> > hence my assertion that a fully complient server is required to
> > immediately disconnect any client issuing a "SELECT" for a mailbox which doesn't
> > contain unseen messages.
> 
> You seem to think that saying such things somehow impresses me of your
> intelligence and talent.

Obviously, it was a joke.  It is crazy to do things like that.  Courier-MTA
used to be so strict (last time I tried to use it) that it was useless for
receiving email from the real internet[tm].  Even with postfix in front,
we pass all incoming mail through an LMTP proxy which cleans up some of the
more disgusting things from the wild so that Cyrus will accept them.

> If you were intelligent and talented you would be constructive and
> cooperative.

Maybe I'm turning into a grumpy old man as well.

> Intelligent and talented people do not bang drums repeatedly upon finding
> a trivial ambiguity in a specification.

It's OK, there's always some new sucker who runs into the same fricking
ambiguity.

> Intelligent and talented people don't go off on a tangent with a
> misinterpretation that is both absurd and harmful.

Oh, I dunno about this one.

> Intelligent and talented people, if they find that trivial matter to be
> annoying enough, will write an errata with proposed replacement wording,
> post it for review, and upon general concensus will submit it to the RFC
> 3501 errata for inclusion in a future revision.

I started work on this and saved this as a draft for days, but haven't
yet finished.  I'll give it another go tonight.

> For what it's worth, that particular bit of text was from someone else's
> errata...to remedy another silly ambiguity.
> 
> I was the editor of RFC 3501. I did write a great deal of it; but that
> document is the work of many authors (and one editor). I feel sorry for
> you if you believe that perfection (or even complete consistency) is
> possible in such an effort.

I know full well how easy it is to get inconsistency.  It's a pity IMAP
is trying to cater to two different audiences with the same protocol:

a) clients that want to "mirror" the entire server state locally, and
   potentially make changes offline and then synchronise them to the
   server.
b) clients that want to display a small window (usually the "most recent"
   for some value of) into the server state, without needing much local
   storage.

Both of these clients want timely information about updates - where these
days the blackberry-experienced generation consider timely to be "within
one second".

Bron.
_______________________________________________
Imap-protocol mailing list
Imap-protocol@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
[prev in list] [next in list] [prev in thread] [next in thread]