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

> 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.  
[...]
> 
> Now, is it just me or does this grate on others as well?

Yes, but as you say, it's more just a nagging feeling of unease.  And
there are others URL schemes, such as telnet, which do not fit the
"prevalent" mode of use for URLs.

I agree with Stephen Williams' comment that part of the problem is the
prevalent view that a URL is used for document retrieval.  Clearly, that's
the case for some URL schemes, but not for others.  "Access" is often a
better word.

Much of my unease would go away if this were simply made more explicit in
the URL documents: "Some schemes (x,y,z) follow (or can follow) a retrieval
model, whereas others simply provide a means to access a network resource
(which may be interactive)"  (That's a strawman, of course.)

I'm coming at this from an unusual direction: I'm writing a draft 
specification for using URIs as an access-type in MIME message/external-body
parts, the existing model for which is decidedly retrieval-oriented.  URL
schemes like telnet and mailto will undoubtedly be useful in that context,
but it certainly complicates things, especially given the fact that new
schemes will be defined.  It would be nice if I could say "schemes which
follow a retrieval model should be handled so" with some hope that it would
be unambiguous.

I don't think there's a serious problem.  Telnet servers, mailboxes, and
files served by mail servers are, without question, network "resources",
and thus are properly referenced by URLs.  But perhaps some talk about 
the *kind* of resources involved would not be out of place in the specs.

---glv

Received on Wednesday, 11 January 1995 13:03:06 UTC