Re: mail and URIs (was RE: FW: LC Comments: Web Method Feature)

On Tue, 2002-07-09 at 16:32, Mike Dierken wrote:
> > From: Amelia A Lewis [] 
> > > So, from a URI point of view, a mailto URI isn't an 'action'. It 
> > > identifies a resource that can be interacted with via SMTP, IMAP, 
> > > POP3. You can talk
> > 
> > Yes, but.  You can identify the "resource" of a target 
> > mailbox to send to (interaction via SMTP, mailto), a resource 
> > (in a more comprehensible
> > sense) of a mailbox to retrieve from (interaction via imap, 
> > pop, mbox, maildir, or something proprietary; imap and pop 
> > have official schemes and I've seen mbox used unofficially), 
> > but there isn't a lot of sense in having a unification ... 
> Why do you say that a unification wouldn't make a lot of sense?
> I'm not deeply knowledgeable about SMTP/POP/IMAP, so I may be missing
> something important here.
> If I had a URI scheme that supported something like 
> and I defined operations that were read/write on any of these, why would
> that not make sense?
> The MTA reads from 'outbox' and writes to 'inbox'.

The MTA reads from its own standard input.  You can't get SMTP to come
look at your box, either.  The MDA writes to inbox.

> The MDA (or maybe the MUA?) reads from the 'inbox' and writes to the
> 'outbox'.


> Please help me understand...

Hmm.  On the one hand, schemes already exist that match the protocol
capabilities.  A genericized, or higher-level scheme of this sort
obscures some of the capabilities of the various pieces of the system. 
But perhaps we should say "hides" rather than "obscures", and recognize
that it might be useful to hide this sort of stuff.

> > Or, to try to bring this back around, the protocol, and 
> > sometimes application limitations which are inherent in, but 
> > not explicit in, a URI limit the useful actions that can be 
> > taken with that URI.  Sure, you can GET a mailto, but it 
> > isn't useful.  You can POST to mbox, but it isn't usual 
> > (although perhaps that would be how an MDA populated it?). 
> > Interesting ...
> Let me paraphrase what you wrote & correct me if I'm wrong
> "... the protocol limitations that are inherent in a URI limit the useful
> actions..."
> The mailto: URI scheme isn't a network protocol, but applications know what
> network protocols are associated with that URI scheme. 


> Would it be
> technically possible - and allowed by the mailto: URI spec - for an
> application to use POP/IMAP protocols to provide 'read' access to the
> information identified by the URI?

POP and IMAP have associated schemes (pop and imap, as it happens ...
pop may be a simple scheme, like mailto, but imap is standard internet
notation, with hierarchy (it earns the double-slash, in other words)).

You see, the problem here is that I *don't* *care* about the mailto for
myself.  The URI that I'm interested in, when I send mail, is the one
that belongs to (for instance) Mike Dierken.  Or xml-dist-app.  I could
certainly associate the "sendfrom" hypothetical scheme with a unified
POP/IMAP/mbox MUA scheme, but that doesn't help to send mail (it only
helps as a return address).  That's useful to advertise, of course (I
need to do so in every message that I want a reply to), but it doesn't
get the message any furtherer.

Apart from LMTP, I don't think protocols for MDAs are well-established. 
I'm not sure how interesting it would actually be to publish them (an
implicit part of the contract of establishing a URI scheme is that
people will want to publish them, pass them around, at least within some
bounds).  In order to allow MTA to work with MDA and MUA?  MDTUAybe. 

If the proposal is a email:// ... I suppose that
one could do this, keeping most of the hierarchy private to the user,
and exposing only the equivalent of the inbox address publicly.

But the problem remains that some URIs are, in effect, write-only, while
others are basically read-only.  Actually, the problem that I would like
to highlight is that the information about valid methods for a
particular URI cannot be determined from the URI, only by knowledge of
the protocols and applications backing a particular scheme.

Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.

Received on Tuesday, 9 July 2002 17:03:41 UTC