RE: FW: LC Comments: Web Method Feature

On Tue, 2002-07-09 at 14:53, Mike Dierken wrote:
> > > GET mailto:mike@dataconcert.com HTTP/1.1
> > > Host: magic.httpserver.net
> > > User-Agent: not-your-fathers-browser
> > > Authentication: BASIC YA4H8G==
> > > Accept: text/xml; message/rfc822; text/plain
> > 
> > By its nature, as far as I can parse it, a mailto URL is 
> > going to indicate a state-changing, non-idempotent action, 
> > and thus isn't appropriate for a GET.  For that matter, I 
> > don't quite understand how one would 'get' a mailto ....  But 
> > you've produced an example, what does it mean?
> > 
> It just means that the URI can be used in an HTTP GET situation.

Umm, a glass bottle can be used in a hammer situation, but the results
are ... well, deprecated.

> The mailto: scheme isn't all that descriptive of the resources on a mail
> server that a client can interact with.

It's highly descriptive of SMTP, as a matter of fact.  SMTP does not
supply retrieval semantics.  You can't ask an SMTP server for your
mail.  Most SMTP MTAs also either are, or have access to an MDA in order
to drop the mail into a local store.

> This was sort of a forced example to try to show that URI are only
> identifiers and even though 'mailto' sounds (to a human) like a directional
> action, it isn't. 

It isn't to a computer, either.  Not if we're talking SMTP.

> 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 ... well, maybe a "sendfrom:" URI (shades of
intercal's COMEFROM statement), but that isn't particularly useful as a
URI.  The POP scheme (barring experimental extensions) can't send mail;
mbox (an unofficial scheme) can't send mail; imap sorta can but no one
does, really.

> /about/ the resource in other contexts by referencing the resource with
> mailto: also, which is a secondary purpose of identifiers in addition to
> direct interaction.
> 
> But this is stretching things because of the history of mailto: - it'd be
> nice to have a more clearly defined mail: or mailbox: or im: URI scheme that
> provided the naming of resources for complete, rich 'Web automatable'
> access.

I don't follow.  mailto indicates target, imap, pop, and mbox indicate
access.  All of these schemes have *restricted* interactions, compared
with the generality of HTTP: you can't usefully GET a mailto, can't
usefully POST or PUT (hmm, corner case!) pop or mbox ... imap supports
MOVEing resources around (PUT plus DELETE is equivalent, though).  I
suppose you could define POST for pop, imap, and mbox, but it isn't
quite the same semantic (just as it isn't really a dialogue when I talk
to myself).

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

Are there any other schemes that are largely write-only, associated with
protocols that are effectively write-only (in SMTP, you can't ask for
your mail; TURN has been deprecated for longer than I've been on the
net, and ETRN signals the desire for the start of another transaction
with role reversal)?  How about read-only?  POP is largely read-only, I
suppose (updates happen outside the protocol).

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 9 July 2002 16:00:33 UTC