Re: Email client APIs. features. amd siupport (was: Re: Scope for self-destructing email?)

[Toerless Eckert <[e-mail]>]

Thanks, John for the elaborations. Fully agree.

Some thoughts:

The principle of the IETF to focus on interfaces that require
interoperability is IMHO good, and it has taken certainly a lot of
time to recognize when and how this requirement applies to
north/south interfaces, "abstract APIs", or however you want to 
call them. 

IMHO, the desire to be able to compose software on single systems
from multiple suppliers should evolve to be an ever more important reason
for the IETF to consider those north/south interfaces. As you said
of course there are conflicting market interests to continue building
"platform monopolies". I just hope that some market segments will easier
see the need for such vendor freedom than eg: the consumer market. 
I continue to be grateful we had the opportunity to deploy  rfc822
ubiquitously before the silicon valleys business model of vertical
monopolies took over.

Wrt to PICS: How about we eliminate all SHOULD/MAY fromIETF 
standards and see whats left ;-). There is also the line of
thought that a separate RFC per optional feature is a much better
way to comply with work metrics in certain companies sponsoring
IETF work ;-) IMHO i agree that options should be minimized, but
we also should find a better way for products to allow declaring
how they do implement standards because options are a fact of life
Even in the best IETF work.

Cheers
    Toerless

P.S.: I just can't let go: Self destructing emails exist for a long
time. They are called mails with programs. And they have shown for
decades now how they can destroy themselves and a lot more. So why
do we need a standard. And how do we get all those malware developers to
come to the IETF ? ;-P

On Tue, Aug 22, 2017 at 10:10:15AM -0400, John C Klensin wrote:
> 
> 
> --On Monday, August 21, 2017 19:02 +0200 Toerless Eckert
> <[e-mail]> wrote:
> 
> > John,
> > 
> > I did like to use a couple of those nice email functions driven
> > by special headers. IMHO the main reason why those never
> > catched on is the absence of easy ways for users to figure out
> > how much their software (MTU/MUA) sucks. 
> > 
> > One thing IMHO that would help are mechanisms to provide users
> > with an easy ability to learn what their software is claiming
> > to support, and what's missing. User experience should be some
> > web-page that explains this to the user in easy terms and
> > ideally even suggests to create RFE emails to the vendors. The
> > question would then be what standards APIs one would need to
> > enable interested third parties to generate such web pages
> > (including IETF).
> >...
> 
> Interesting idea, but a very different discussion (hence the
> change of subject lines).   As you know, the IETF has tended to
> avoid API specifications, largely because we have preferred
> performance standards (i.e., "this is what you need to do and
> support") to implementation ones ("this is the API, probably
> expressed on code or pseudocode, all you need to do is call
> it").  We've also tended to focus on what happens or is
> transmitted on the wire between machines rather than how and
> what things are dong or implemented before the bits leave a
> source system or after they get to a destination one.    In
> addition, many people have argued strongly that we should,
> insofar as possible, stay out of the UI business, in part
> because the IETF, as a community, demonstrably has no skill in
> the area.
> 
> Personally, I think it is desirable to review those constraints
> and assumptions from time to time and to do so explicitly.   It
> concerns me a bit when we charter WGs to make major excursions
> into the interface between mail delivery servers or IMAP servers
> and mail stores without explicitly having that review and
> discussion. 
> 
> All of that said, I think the MTA situation is fairly good,
> especially if one is willing to let MTAs be MTAs rather than
> expecting different, or even contradictory, functions (message
> recall or destruction among them).   The MUA situation sucks,
> but, I think, more because of two reasons the IETF probably
> can't solve, certainly not by more standards or APIs.  First,
> the providers of free MUAs as part of larger packages or
> software or services have little or no incentive to strive for
> high quality, especially if quality improvements would make it
> easier for users to switch to other packages or mail services.
> They have little incentive to carefully conform to standards
> either, especially if those standards would interfere with the
> lock-in to their packages or other pieces of their systems for
> which they have a business model.  Second, in an environment in
> which most of the users in the world are using either Webmail
> interfaces to mailstores and submission systems that are
> proprietary to the same providers or "free" mail clients that
> are bundled with office or similar packages, it is hard to think
> about where major investment in new, improved, and updated MUAs
> is likely to come from, especially when one remembers that these
> things need to be maintained to be and stay effective and
> useful, not just developed once and put out there.   I note that
> development stopped on Mulberry and Eudora years ago and that
> Pegasus Mail has never really caught up with current feature
> expectations and development has progressed very slowly if at
> all.
> 
> There are two additional challenges to MUA development today.
> HTML-format email is becoming increasingly common, sometimes
> with advanced and clever (and arguably dangerous) features.
> MUAs that do not use browsers (or APIs to browsers) to read that
> mail but, instead, display either plain text only or that use
> HTML interpreters that are very restrictive about, e.g.,
> automatic processing of external links have large advantages in
> terms of reduced risk from attacks but are attractive only to
> specialists and others with the knowledge to care or require
> significant resources to develop and maintain, especially in the
> age of HTML 5.x.   As far as I know, no one has made the effort.
> In addition, significant parts of the email community decided a
> few years ago that support for email addresses with non-ASCII
> characters in both the local and domain parts was important.
> The features needed to provide and use those addresses have been
> deployed very slowly, partially because of a chicken and egg
> problem and, perhaps more important, because the development of
> high-quality multilingual (not just multiple script, one or a
> few languages other than English, or crudely translated) email
> clients is a hard (and expensive, whether measured in time,
> money, or both) problem.  Any work done by the IETF that would
> make the task of getting those more internationalized capability
> deployed more difficult would be, long-term, a serious
> disservice to the community.
> 
> 
> > Admittedly, i've been annoyed for 25 years that IETF unlike
> > ISO is not doing PICS, so maybe this is a more pragmatic
> > approach to tackle that gap. And one that would be more user
> > friendly, dynamic and maybe even more reliable (depending on
> > how much actual probing instead of just declaration you would
> > be able to do via the API).
> 
> FWIW, there is a point of view that suggests that what made the
> PICS [1] approach important was the proliferation of options
> that make protocols useful only when profiled.  The IETF, at
> least in the best of our work IMO, has tended to focus on
> interoperability rather than conformance to lists of features
> and on keeping protocols simple enough and free of "settle
> arguments but putting everything in" designs to avoid the need.
> Some of us think those preferences are high on the list of
> reasons why we are not all running X.400 mail today.   YMMD, but
> be careful what you wish for.
> 
>       john
> 
> [1] for those who don't know, a "protocol implementation
> conformance statement" that explains exactly what features of a
> protocol a particular implementation, or set of implementations,
> supports.
> 
> 

-- 
---
[e-mail]