Subject: RE: [Asrg] "New Email Protocol Replaces SMTP"

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 1 May 2006 09:58:42 -0700

> From: Dave Crocker [mailto:[email-masked]] 

> My SMTP-replacement mantra:
> 
> When folks agree on the service (changes) needed, and When 
> that agreement does not break legitimate uses of email, and 
> When the community tries to retrofit those changes into the 
> existing email infrastructure, and When that effort fails, 
> Only then will an effort to replace SMTP make any sense at all.

I disagree, I think that what will eventually happen is that another
protocol will emerge to serve an entirely separate niche that turns out to
provide a useful email facility which gradually replaces SMTP the same way
CD gradually replaced vinyl.

The most likely place for a competing spec to emerge is from the synchronous
messaging space. The cost of spam in Instant messaging is potentially huge,
there is a big incentive to build controls into the system to limit it. The
need to control spam even trumps the value of ubiquitous connectivity.

One can imagine a generalized synchronous messaging scheme covering text,
voice and video, such a scheme would inevitably require a voicemail type
capability, adding an option to go straight to voicemail becomes a
no-brainer. A text message that goes straight to a 'mail' stager is...
Email.

I think it will take a long time and there is unlikely to be a major
incentive to cut off SMTP connectivity for even longer. We are still plagued
by the business requirement to have a fax machine even though email renders
fax functionally obsolete.

The only functionality that SMTP does not currently handle well is defered
transfer of attachments. If I am sending a 1Gb video message or a similar
sized document or data file the recipient probably wants to be sure they
want to receive it before accepting the start of the message transfer.
Deferred transfer of the attachment would not be difficult to add into SMTP
(it would merely be a content type to drop into a multipart/alternative).
But I think it most likely this would happen as organic convergence working
out from the synchronous space. DKIM is certainly an essential first step. 

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "B. Johannessen" <[email-masked]>
Date: Mon, 01 May 2006 19:30:22 +0200

Hallam-Baker, Phillip wrote:
> transfer of attachments.

SMTP (via MIME) handles it just fine, see: RFC 2046, section 5.2.3; 
External-Body Subtype. Not widely implemented in user agents though, but 
that's hardly an SMTP problem...

	Bob

---

From: "Jim MacLeod" <[email-masked]>
Date: Mon, 1 May 2006 11:08:18 -0700

Perhaps the more approprate comparison is between HTTP and FTP, or IPv4 and
IPv6.

Moving email protocols is necessarily a complicated process, as they involve
us admins changing systems, not end users.  One might argue that admins
could switch Internet email protocols, while maintaining existing intra-net
mail protocols.

If I were forced to predict the future, I'd say that a decendent of IMAP
will likely take over the MUA<->MTA space entirely, and relegate SMTP to the
edge.  The most likely next step then would probably be a DKIM-type SMTP
extension.  An inter-MTA protocol has to be able to accept email from a
total stranger, and DKIM allows that in a way that's more secure than SPF et
al.  (Disclaimer: I'm a fan of CSV, but I don't expect it to gain widespread
fame.)

I just hope that the the transition, when/if it occurs, happens like LP ->
CD, not (( Betamax <-> VHS ) <-> LaserDisc ) -> VHS -> DVD -> ( HD-DVD <->
Blu-Ray ).

-Jim

---

From: "David Nicol" <[email-masked]>
Date: Mon, 1 May 2006 17:31:40 -0500

On 5/1/06, Jim MacLeod <[email-masked]> wrote:
>  An inter-MTA protocol has to be able to accept email from a
> total stranger,

that's a policy directive, not a technical requirement.

--
David L Nicol
The best way to predict the future is to invent it (Alan Kaye)

---

From: Steve Atkins <[email-masked]>
Date: Mon, 1 May 2006 17:45:40 -0700

> that's a policy directive, not a technical requirement.

Policy directive or technical requirement, potato, potahto - it's a
requirement that rules out many, many of the suggested approaches,
and tends to be the achilles heel in even the better thought-out
suggestions.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 May 2006 19:17:50 -0700

> that's a policy directive, not a technical requirement.

Just to hammer this home, the language was "be able to".  That's a 
technical requirement.

The ability to exchange mail, without prior arrangement, is fundamental 
to Internet mail.  That a receiver might invoke policies to the contrary 
is entirely their right.  But the basis for the design choices of the 
standards is quite clear.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>