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

Stephen D. Williams (sdw@lig.net)
Wed, 11 Jan 1995 01:49:47 +0000 (GMT)

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

    Message-Id: <m0rRsC7-0009v8C@sdwsys>

    From: sdw@lig.net (Stephen D. Williams)

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

    To: raisch@internet.com

    Date: Wed, 11 Jan 1995 01:49:47 +0000 (GMT)

    In-Reply-To: <199501102047.AA10965@ahhh.internet.com> from "Rob Raisch" at Jan 10, 95 03:48:06 pm

>
> I have a concern I'd like to air. Actually, it's more of a nagging feeling of
> unease than a concern. But here goes...
>
> There is a question in my mind regarding the purpose to which we would like to
> put URLs. The crux of this question is that mailto: and mailserver: do not, I
> believe, describe means which can be used to retrieve network resources.

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 have always understood a URL to be composed of three important parts:
>
> - How we will retrieve the stated resource -- (http, gopher, etc.)
> - From where we will retrieve a resource -- (host:port)
> - What resource we will retrieve -- (opaque URL specific info)
>
>
> Rather than a prescription which can be used to retrieve network accessible
> resources, these URLs provide a means of initiating a process, which can,
> perhaps, initiate the retrieval of a network accessible resource -- through a
> channel external to the browser, but is not necessarily required to. We seem
> to already have a method of initiating processes such as these, the CGI API, no?
>
> Now, is it just me or does this grate on others as well? I don't think that we
> really understand what we did when we defined the mailto: URL, and guess I am
> concerned how this will affect our understanding and the ultimate deployment of
> URNs.
>
>
> Comments?
>
> </rr>
>

    --
    Stephen D. Williams    25Feb1965 VW,OH      sdw@lig.net http://www.lig.net/sdw
    Senior Consultant      510.503.9227 CA Page 513.496.5223 OH Page BA Aug94-Dec95
    OO R&D AI:NN/ES crypto     By Buggy: 2464 Rosina Dr., Miamisburg, OH 45342-6430
    Firewalls/WWW servers ICBM: 39 38 34N 84 17 12W home, 37 58 41N 122 01 48W work
    Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.29Nov94

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