Although I think "default_proxy" is a good idea, I don't think it
covers everything.
The question is what should a "reasonable" client do when it is handed
a URL with a protocol part it doesn't know. There should be both a
reasonable default action, and a way of specifically instructing it
to do a particular action.
In the absense of "default_proxy" or any proxy being set, I think it
would be reasonable to attempt a proxy connection to a http server
at the same host part address as the unknown protocol URL. (*)
A setting of "default_proxy", or "proto_proxy" would override that
default behaviour.
The other type of override is with client-side helpers.
Most clients don't do telnet: themselves - they call another program
to open a telnet session for them. The list of helpers for output
data types is usually extensible, but I don't think any of the current
clients allow extensible mapping of protocol helpers.
[ I use imap: in the example below, since that is one of the
gateways I am currently prototyping, but the intention is
to allow general extensibility of supported prototypes and
to not freeze useful URLs at those *currently* supported by
Mosaic and other WWW browsers. ]
So, a proposed "reasonable" client, on getting, for example a url:
imap://user@host/mailbox#message
where it didn't know how to "speak" the imap protocol, would by
default ( without any proxies being set ) transform that URL into:
http://host/imap://user@host/mailbox#message
And try for the existance of a http-imap gateway on that host.
( If a host is going to give out imap URL's when that protocol
is not widely supported by clients, then it is also "reasonable"
for that host to provide a gateway. But the original URL remains
a logical access method specifier that will still be valid if and
when support for additional protocols is added. )
This default behaviour could be changed by either the setting of
"default_proxy", "imap_proxy", or by the designation of a client-
side "imap_helper" program. [ And if pine or some other imap
mailer is given command-line imap URL support, then it could be
dispatched to access that URL, just as in the current telnet case.]
Note that setting "imap_proxy" to a different host than the one
in the imap URL would allow a third party gateway. This might be
acceptable for read-only public mailboxes ( and is, in fact, the
main use a present I have for such a gateway, which will probably
only support a subset of IMAP functionality - just enough to fetch
a message out of an acrhive. ) but would make passing plain-text
passwords (to access a private mailbox by URL) even *MORE* unsafe.
[ Don't use an untrusted proxy if you are going to pass passwords!]
[ Sorry for broadcasting this so widely: I looked in the newsgroups
and mailing list archives and didn't see any discussion of this
issue, and I wasn't sure where the appropriate forum was, since it
falls in the cracks: it has to do with client server interaction, but
doesn't really have anything to do with the protocol or HTML. It
has to do with the interpretation of a URL, but the URL/URI drafts
seem to intentionally distance themselves from semantics.
(*) Note: The above would violate the notion (expressed in the drafts)
that everything after the proto: was an opaque representation.
However, it is already the case that there is a defacto standard
syntax and a defacto semantics for parts of URL's. It is embedded
in various libraries of URL parsing code, so it's not unreasonable
to assume that if a url has a host part, it should follow the
proto://[user[:password]@]hostname[:port]/... syntax, even if the
rest of the following string is opaque. ]
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics