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

List:       imap
Subject:    Re: I-D ACTION:draft-showalter-imap-id-02.txt
From:       Barry Leiba <leiba () watson ! ibm ! com>
Date:       1999-07-23 12:31:43
[Download RAW message or body]

Mike Macgirvin wrote:
> timely manner. There are buggy clients and buggy servers and we know they
> are there and we know what is wrong with them and how to react if we
> encounter one. What we don't know is how to positively identify them
> without lengthy and potentially irreversible command/response probes.

I have a lot of sympathy for this position, and it's hard, in some ways,
to argue against it... except that I also know how fraught with difficulty
it is to keep it from getting out of hand.

The main problem is that if you hard-code these workarounds, as you sort
of must (see below), then it's difficult to adjust them.  You know that
FarbleCom's release 4.2a of the KumquatMail server has a bug in which 
you can't request ENVELOPE and BODYSTRUCTURE on the same FETCH command 
(real name/vendor/release number changed to protect... well, changed).
You don't want to send separate FETCH commands all the time, along with 
the extra round trips and all, so you code a workaround.  Easily done.
But....

How do you know when the bug is fixed in the KumquatMail server?
How do you know the complete list of releases that have the bug?
How do you test the ID response to decide to apply your workaround?
When KumquatMail has a new release and the bug still isn't fixed,
you have to check for this new release, and everyone has to upgrade
to your latest client, or else they won't work with the new KumquatMail
server.

And then, of course, when do you remove the workaround?  It winds up
staying in your code forever (for some value of "forever"), because you
never know when everyone has stopped using the bad release(s) of 
KumquatMail.

Yeah, Mark's point that server bugs are worse than client bugs applies 
here, but my point's still valid.  Yeah, in the example I give you can
just punt and apply your workaround to *every* KumquatMail release, because
it doesn't hurt anything.  But it's not hard to come up with an example
where that doesn't apply.  It's a general nightmare to try to do things
this way, with the possible exception of the case where a vendor *refuses*
to fix a problem (and people insist on using that vendor's software anyway).
And I still say that the right answer for that is to let things break and
get pressure on the vendor... but see my first sentence, far above, where
I understand what's involved there, especially when the errant vendor is 
large and the righteous one is small and struggling [like Mike M's company
:-)  :-) ].

As to hard-coding the workaround, well... the right answer, then, would be 
to put the workaround into a configuration file.  I've never seen an effective
way to do this.  The closest one can come is to hard-code the workaround and
let a configuration file control which releases it applies to.  Somewhat
better, but still awkward... at least it addresses the major problem of
deciding when to apply the workaround.

No, I have a lot of sympathy for the position, and I *do* find it hard to 
argue vehemently against it.  But, in the end, I think the problems with
doing this outweigh the advantages, and I *do* argue vehemently against it.

In any case, there's nothing stopping you from violating the spec and doing
this anyway; all we're saying in our argument here is that you can't expect
the spec to condone that, and you can't claim to be in full compliance with
it.  I think that's a reasonable approach.

Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba

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