Subject: Fwd: Your new mailing list: httpmail

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 3 Dec 2008 10:45:26 -0800

I created a new mailing list to discuss HTTPMail (
http://tools.ietf.org/html/draft-dusseault-httpmail-00):

   https://www.ietf.org/mailman/listinfo/httpmail

I have been thinking about this for a while, but delayed because I wasn't
sure there was really enough demand for a new client access protocol.  But
I've started thinking of it as foremost a remote 3rd-party interface to an
email store, which is a rather different niche.  It would be good for email
to have the same interconnectivity opportunities as the Web has (or better).

Lisa
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 03 Dec 2008 12:26:45 -0800

Lisa,

 From an architectural standpoint, how is this different from replicating (a 
subset of) IMAP functionality but running it over HTTP?

Not surprisingly, I'd particularly like to see a reference to the line 
segment(s) in:
 
<http://bbiw.net/specifications/draft-crocker-email-arch-12-01dc.html#rfc.figure.5>

that the spec targets.

Stated differently, what functionality does this supply that is not already 
provided by existing email protocols?

I've looked over your discussion in the draft but am not yet understanding these 
motivating points.

One obvious possibility is that it is IMAP that can more easily get through a 
firewall.  I'm guessing you have something more substantial in mind.

Can you clarify?

(And yes, I think it useful to do it on this mailing list, first, rather than 
the new one.)

Thanks.

d/

ps.

Lisa Dusseault wrote:
> I created a new mailing list to discuss HTTPMail 
> (http://tools.ietf.org/html/draft-dusseault-httpmail-00):
> 
> I have been thinking about this for a while, but delayed because I 
> wasn't sure there was really enough demand for a new client access 
> protocol.  But I've started thinking of it as foremost a remote 
> 3rd-party interface to an email store, which is a rather different 
> niche.  It would be good for email to have the same interconnectivity 
> opportunities as the Web has (or better).

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Barry Leiba <[email-masked]>
Date: Fri, 05 Dec 2008 10:14:34 -0500

> 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.  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.
- It defines how to represent mailbox contents in Atom.  That lets any feed 
reader (or browser that can read feeds) display a mailbox.
- It recommends permalinks for email messages, allowing browsers to cache them.

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.

Barry

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Dec 2008 09:23:01 -0800

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:

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 

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

---

From: SM <[email-masked]>
Date: Fri, 05 Dec 2008 11:23:21 -0800

At 09:23 05-12-2008, Dave CROCKER wrote:
> 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.

As I see it, the proposed protocol is not between a mail user agent 
and a message store.  It can extend the concept of message access 
beyond what we generally see in mail user agents.  As far as I'm 
aware, we don't have mashup functionality in mail user agents.  That 
alone opens new avenues to how messages can be presented.

>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.

We could view the access as a way to get around firewall 
protection.  Or we could see it as a way to access messages with a 
browser.  Whether we like it or not, the browser is a driver when it 
comes to presenting information.

What this proposal brings us is also a layer of simplicity.  There's 
still the question of complexity when it comes to message/rfc822 
parsing but that's a separate issue.  The applicability goes beyond 
what is mentioned in the draft.

Regards,
-sm

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 5 Dec 2008 15:31:21 -0800

On Fri, Dec 5, 2008 at 9:23 AM, Dave CROCKER <[email-masked]> wrote:

> 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.

This is in fact pretty key to the proposal: a new set of tools, libraries
and even approaches that can be looped in.  I worked on this with Jeff
Lindsay, and in the roughly three days we sat together and worked on it, I
wrote the draft and he wrote this, heavily leaning on existing libraries:

http://github.com/progrium/httpmail/tree/master

It doesn't do everything, but it did work as a proxy between a native Atom
newsreader and a native IMAP store.   No changes were needed to the actual
mail store or to the Atom newsreader.

Lisa

---

From: John C Klensin <[email-masked]>
Date: Sat, 06 Dec 2008 11:04:50 -0500

At the risk of agreeing with Dave (or even appearing to do so)
on an actual protocol matter...

While I disagree with several of his specific examples, I think
there is a related point to be considered.

We really don't have a Mail Store -> Mail-reading-MUA protocol,
partially because of the "Split UA" model that has been argued
to be a fundamental part of the IMAP and POP architectures.
But, from that point of view, the HTTP-based approach supplied
here is just another kind of Split UA and Dave's "do we really
have an adequate reason to invent a third one" question seems
exactly right.

I also note that we have never tried to standardize an interface
or API for access to a mail store from an MUA running on the
same system, although that is the classic model with its many
variations.

So, let me add a question to Dave's: if the desire for this work
is  such as to justify thinking about a new Split UA protocol to
complement POP and IMAP, should we not, instead, finally be
thinking about whether we know enough to standardize basic mail
store primitives and access in a way that could support POP,
IMAP, some sort of HTTP thing(s), _and_ local MUA systems?
Obviously, it would be a larger piece of work, but it would have
a lot more leverage on protocols and design development.

It is possible that the often-asked, but rarely actually
considered, question of what a minimal/ core/ primitive IMAP-ish
protocol would look like if we designed it de novo today is
equivalent to the question I'm trying to raise above.  If so,
maybe it is time.

The answer may well be "no" to all of these questions but, as
with Dave's questions, I think asking the questions carefully
and being sure we have answers would considerable illuminate
what actually needs to be done and how it would relate to what
is out there already.

    john

--On Friday, 05 December, 2008 09:23 -0800 Dave CROCKER
<[email-masked]> wrote:

> 
> 
> 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.
> 
>...

---

From: Tony Finch <[email-masked]>
Date: Sun, 7 Dec 2008 00:35:14 +0000

> to be a fundamental part of the IMAP and POP architectures.

What do you mean by "mail-reading-MUA"? Does it relate to one of the
models described in RFC 1733? Why isn't IMAP this protocol?

> It is possible that the often-asked, but rarely actually considered,
> question of what a minimal/ core/ primitive IMAP-ish protocol would look
> like if we designed it de novo today is equivalent to the question I'm
> trying to raise above.  If so, maybe it is time.

There has been some discussion along these lines on the IMAP5 list.
https://www.ietf.org/mailman/listinfo/imap5

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH UTSIRE: NORTHWESTERLY BACKING SOUTHWESTERLY 4 OR 5. SLIGHT OR MODERATE.
SHOWERS. GOOD.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John C Klensin <[email-masked]>
Date: Sat, 06 Dec 2008 19:59:23 -0500

--On Sunday, 07 December, 2008 00:35 +0000 Tony Finch
<[email-masked]> wrote:

>> We really don't have a Mail Store -> Mail-reading-MUA
>> protocol, partially because of the "Split UA" model that has
>> been argued to be a fundamental part of the IMAP and POP
>> architectures.
> 
> What do you mean by "mail-reading-MUA"? Does it relate to one
> of the models described in RFC 1733? Why isn't IMAP this
> protocol?

:-)

I was referring to such wonders of modern and advanced
technology as the U**x "mail" command as well as more recent
developments such as emacs mail mode, MH, XMH, and so on, i.e.,
mail-reading and composing programs that read information
directly from the mail store on the same host (or that pretend,
via NFS or its clones), to do so.   Nothing so abstracted as
IMAP.

>> considered, question of what a minimal/ core/ primitive
>> IMAP-ish protocol would look like if we designed it de novo
>> today is equivalent to the question I'm trying to raise
>> above.  If so, maybe it is time.
> 
> There has been some discussion along these lines on the IMAP5
> list. https://www.ietf.org/mailman/listinfo/imap5

I am vaguely aware of that, and more aware of several other,
more or less similar, discussions over the years.  Collectively,
they were what I was referring to as "often-asked, but rarely
actually considered".  My question, stated differently, is
whether the suggested need for yet-another Split UA mail reading
protocol might really be the indication that it is time to apply
serious work to IMAP-core or IMAP--, or however one might want
to model it instead (whether Lemonade has turned into IMAP++
but, as an intended set of profiles for IMAP4, never had the
potential to do this work).

    john