Re: Fwd: Your new mailing list: httpmail
Dave CROCKER <dcrocker <at> bbiw.net>
2008-12-05 17:23:01 GMT
Barry Leiba wrote:
>> Stated differently, what functionality does this supply that is not
>> already provided by existing email protocols?
>
> The point here is exactly that it defines a standard way to run this
> stuff over HTTP, so that a web browser (or other HTTP client) can do
> this without having to implement IMAP or POP.
From what I can tell, the proposed protocol works between what is really a mail
user agent (MAU) and what is really a message store (MS). If I have that wrong,
please clarify.
So a comparison between this protocol and the obvious existing ones is natural.
And that's a key beginning point: You are still proposling implementing *some*
protocol. So my question is why is it appropriate to invent a new protocol,
rather than re-home an existing one to use HTTP (rather than, say, TCP) as its
transport?
There can be any number of very good reasons.
For example, it might be that HTTP has characteristics that are so different
from TCP, it isn't practical to re-use an existing one.
It might be that the existing ones do not match the desired functionality.
It might be that the existing ones are much too complicated. It's difficult to
imagine claiming that IMAP is too complicated, but gosh, maybe it is...
And so on.
Personally, I'm a fan of protocol competition. (In contrast, the IETF in recent
years has tended to eschew competitive, or even related, protocol efforts.)
Competition gave us SNMP rather than CMIP. SMTP/822/MIME rather than X.400.
TCP rather than TP*. And so on. In each case, the dominant political preference
tended to be for the protocol that, in the long run, lost. And I believe in
each case, the winner triumphed on its technical merits.
But I think it important to consider the competitive differences that are
significant.
For example, the mere fact that the transport layer is different doesn't
automatically justify inventing a new protocol. New protocols are hugely
expensive, in terms of time, effort and dollars.
That's why we so often re-purpose existing ones.
For example, one could imagine taking a query service designed to map between a
name and an address and instead using it for obtaining encryption keys. All of
the underlying query technology, infrastructure deployment and operational
skills for re-using that technology, would therefor be saved, when compared
against deploying a new key query infrastructure...
Similarly, there is a vast base of code and experience with existing MUA/MS
protocols. Why not re-use it?
To repeat: I'm not saying the work shouldn't be done. Rather I'm saying that
being clear about what work is actually needed is important before starting a
process that will take years and spend many millions of dollars. (I think that
you and everyone else recognizes that that is what it takes to deploy a new
protocol.)
Make vs. buy is always an extremely strategic choice. So it helps to make it
carefully.
The spec says that it's
> not meant to replace the email protocols, but to provide an alternative.
>
> In particular:
> - It defines how to discover mailboxes.
OK. New function. Why not add it to IMAP? (One could argue that POP already
contains it.)
> - It defines how to represent mailbox contents in Atom. That lets any
> feed reader (or browser that can read feeds) display a mailbox.
I didn't see this discussed, as such, in the draft, but it sounds interesting.
Basically it seems to create a competitive choice between re-using existing IMAP
mailbox constructs versus Atom mailbox constructs. Exploring that choice in
terms of software, ops, and experience strikes me a potentially enlightening.
> - It recommends permalinks for email messages, allowing browsers to
> cache them.
A new construct, but one that comes from long debate, including recently within
the IMAP community, I believe.
> The main motivating point is the desire to access mail stores using
> HTTP. If you don't think there's a need for that, then clearly you
> won't see the point of Lisa's draft.
I hope that, from my above comments, you now understand that I'm not trying to
challenge the goal of HTTP-based access -- although I think it worth gaining
community consensus about why such a goal is anything other than an attempt to
end-run firewall protection -- but rather to note that achieving that goal does
not obviously preclude using existing protocols by re-homing them on the new
'transport' layer.
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
RSS Feed