- From: Stephen D. Williams <sdw@lig.net>
- Date: Wed, 11 Jan 1995 01:49:47 +0000 (GMT)
- To: raisch@internet.com
- Cc: ietf-lists@proper.com, chrisf@sour.sw.oz.au, uri@bunyip.com, hoymand@gate.net
> > 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
Received on Wednesday, 11 January 1995 01:46:24 UTC