Re: Webmail is implementation, not Internet architecture (was Re: Chang

On Sat 14/Jun/2014 09:14:51 +0200 Dave Crocker wrote:
> On 6/12/2014 6:33 PM, Phillip Hallam-Baker wrote:
> > On Thu, Jun 12, 2014 at 10:50 AM, John C Klensin 
> > <john-ietf(_at_)jck(_dot_)com
> ...
> >     (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.
I agree with Dave on this point.  His note is especially meaningful
in this thread, because Phillip started it noting that:

On Sat 07/Jun/2014 14:40:50 +0200 Phillip Hallam-baker wrote:
Archived-At: 
http://mailarchive.ietf.org/arch/msg/ietf/kvU9-WN7AASUAUpfUCpc__LpLGE
> > > > That is what folk complaining don't get: you don't have the right to
> > > > use your employers email or a public email provider's email any way
> > > > you want. The domain name owner makes the rules.
> > > >
> > > > As Craster insists: My domain, my rules.
That is the sort of reasoning which is often heard about social
networks, sometimes culminating with someone observing that we should
devise a protocol for generic social sites, so as to avoid being at
the mercy of the provider of the day...

Specifying a protocol is only useful inasmuch as it allows to swap
the underlying implementation.  Webmail, for example, can be
implemented locally using an IMAP backend (e.g. Mailpile).

The issue at hand originates from the fact that protocols, by
definition[1], cover the mechanics rather than the semantics.  DMARC
attempts to ensure the authenticity of an identifier, whose semantics
should provide for accountability.  So, while its enforcement depends
on the ability of receivers to reject (with "considerable care"[2])
its impact and semantics are still left to the community.  Some sort
of training is appropriate, but IETF's voice doesn't seem to be much
heard outside of a restricted circle, which is one of the reasons why
I proposed an online demonstration.

Ale

[1] thread starting in:
 http://www.ietf.org/mail-archive/web/ietf/current/msg71257.html
my observation on semantics was in:
 http://www.ietf.org/mail-archive/web/ietf/current/msg73752.html

[2] http://tools.ietf.org/html/rfc5321#section-7.9