# Re: Problem with mail URLs - was Re: Second round...

Paul Hoffman (ietf-lists@proper.com)
Wed, 11 Jan 1995 10:32:12 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Stephen D. Williams: "Re: Second round for new URL scheme (mailserver)"
- Previous message: Glenn Vanderburg: "Re: Problem with mail URLs - was Re: Second round..."
- Maybe in reply to: Rob Raisch: "Problem with mail URLs - was Re: Second round..."

    Message-Id: <ab39d0500b021003bec5@[165.227.40.28]>

    Date: Wed, 11 Jan 1995 10:32:12 -0800

    To: uri@bunyip.com, raisch@internet.com

    From: ietf-lists@proper.com (Paul Hoffman)

    Subject: Re: Problem with mail URLs - was Re: Second round...

At 5:49 PM 1/10/95, Stephen D. Williams wrote:
>I view URLs as just that: a locator system (global naming system) of
>resources. That doesn't mean that they are all resources that return
>data immediately as their only function.
>
>If you use 'access' instead of 'retrieve', I think you might see more
>possibilities. Also, I could easily see how a client could monitor
>received email and show a queue of received items to retrive.
>(Yes, that implies a client/helper with pop3/imap builtin, which
>I wish I had.)

I agree with Stephen here.

I've thought a great deal about the issues Rob brought up, and think that
they are not an impediment to the mailserver URL. Rob is correct that
mailserver (and the unfortunate mailto) is different than the other URL
schemes in that it does not open a pipe to a resource server, wait for an
answer, and close the pipe. Instead, mailserver (after prompting the user
that he/she really wants to send the specified letter) simply shouts it to
the world and returns nothing.

However, that does not mean that mailserver is not a valid URL scheme, just
that it acts differently than all the other URL schemes. My view is: mail
is different than the underlying mechanisms of the other schemes, and
that's fine. URLs show the location of resources, and mailserver scheme
does that exactly like the existing schemes. What is different is how a
potential client turns the URL into the resource.

To see this more clearly, think about a user who has asked me a question. I
send that user a mail message that says "The information you need can be
found at <URL:http://xxx.com/yyy.txt>." It turns out that that user only
has email access to the Internet. Next assume that the user has a good mail
client that has a feature that, given an http URL, sends a message off to a
known http-by-email server and gets the file mailed to the user. Now assume
that the user today got a full link to the Internet and the user hands that
URL to a Web client. In either case, the URL pointed to a resource, and in
both cases the user was able to get the located resource.

Futher, I believe that in the future, there will be mail clients that act
like today's Web, Gopher, and so on clients, but much slower. You will
lauch the client with a mailserver URL (or something like it), and the
client disappears from your field of view for a while. Later on, the client
pops up and says "Remember me? You asked for the yyy.txt file. Well, here
it is." The current buzzword being used for these clients is "intelligent
agents", but you get the picture.

In summary, I think that if a URL scheme identifies the location of a real
Internet resource, it is valid regardless of how a user or a user's client
would retrieve that resource.

--Paul Hoffman
--Proper Publishing

- Next message: Stephen D. Williams: "Re: Second round for new URL scheme (mailserver)"
- Previous message: Glenn Vanderburg: "Re: Problem with mail URLs - was Re: Second round..."
- Maybe in reply to: Rob Raisch: "Problem with mail URLs - was Re: Second round..."