Ned Freed writes:
> I note, however, that there have been any number of other specifications for
> submit via IMAP, almost all of them better designed than this one but
> neverthless all flawed in one way or another, and there has been essentially
> zero uptake of any of them. What this says to me is that having
> two protocols
> for access and submit much of a concern for developers as we'd
> like to think.
Uhm. There's been zero uptake for stuff that requires clients to implement
BOTH single-protocol AND two-protocol submission:
if(unlikely condition)
one implementation here
else
another that works in all cases
Why bother with the first branch if the second is unavoidable? Even if you
like the first one better than the second? Even if the first is simpler?
The obvious counterexample here is SMTP pipelining, which is widely implemented
and used. (According to my logs, ~500 out of ~800 connections used pipelining
when talking to my server yesterday.)
But more interesting counterexamples include, but are probably not limited to,
binary SUBMIT and BURL. Usage of them is low but IME definitely not zero. (And
before you ask, the answer is no, I can't provide any specific details on which
of our customers use them. But given their nature you can probably figure out
what sort of client might find them useful.)
Really, it's all about *operational* cost versus benefit. If the operators saw
significant operational benefit in a single protocol solution, *or* saw
significant operational cost associated with using two protocols that a single
protocol solution would eliminate, they would be telling their client and
server implementors to code it up.
But AFAIK we have yet to receive a single request for such support. Which says
to me that neither condition is being met.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp