Webmail is implementation, not Internet architecture (was Re: Change the mailing list protocol, not DMARC.)

[Dave Crocker <[e-mail]>]

On 6/12/2014 6:33 PM, Phillip Hallam-Baker wrote:
> On Thu, Jun 12, 2014 at 10:50 AM, John C Klensin <[e-mail]
...
>     (2) One of those changes --support for remote body parts-- was
>     incorporated into MIME in its very first version and contains
>     most of the mechanism needed to support what I understand PHB is
>     recommending for PUSH-PULL-PULL.  It has been implemented in
>     several places but has gotten very little traction in the mail
>     sending and receiving community.  IMO, it ought to be incumbent
>     on anyone proposing a different "get notification, then retrieve
>     mail from server" model explain why their ideas will be more
>     successful than that 20-odd-year-old MIME mechanism.
> 
> In a word - WebMail.

This is a classic confusion between software implementation and
operation, vesus networking architecture.

Webmail is nothing more than a particular style of user interface,
integrated into the operations of a particular service.  25-30 years
ago, Einar Stefferud labeled this a "split UI" mode, since part of the
mail user interface runs on the user's platform and part runs on the
server's.  It uses whatever homegrown UI-to-UI protocol the local
operator chooses, but otherwise is nothing but classic Internet Mail
architecture.

It's a useful operating mode, within its limits, which typically
includes requiring full-time connectivity.  As good as user access to
the Internet often is, requiring it all the time, for doing email, is a
pretty serious limitation.

More importantly, it isn't interoperable, in the sense we use the term
in the IETF, since it locks the user into the service provider for
literally everything.

There's no user ability to have a different MUA, different email
storage, different address book, different anything.   By having things
locked into the recipient's own email service provider, there is no way
to distribute out enhancements.

So, for example, there is no way for the /author/ to declare an
attachment as being located somewhere else.


> Updating mail clients is a long and tedious process so it is not
> surprising that updates take a lot of time to percolate through. It was
> 5 years after the initial deployment of MIME before mail clients to
> support it became common. And the first of those that did were actually
> combined mail/NNTP readers.

Truly distributed networking architecture certainly does carry costs,
including costs and delays of making changes.

But we've had a highly siloed world before the Internet and we didn't
much like sticking to it.  That we've moved back to it for many services
is convenient for providers to control their market (and, yes, quickly
provide new features) but it has made the user's world notably more
complex and often less interoperable.

Consider the issue, the next time you want to send someone an instant
message.  Do you send it via SMS, google, facebook, yahoo, skype or --
oh yeah -- aol?  That's a really prime example of the derivative effects
of excessive integration witha provider: combinatorial explosion rather
than seamless Internet integration.

And the view that it is sufficient to have a client which integrates all
the heterogeneous services into a single user interface misses the
operational complexities and lack of interoperability they are living with.


> I don't read all my mail in Webmail, 

Why not.  If it's so wonderful, then why isn't it being used for all
your email?


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net