Re: Request: URN support in browsers needed!

Daniel W. Connolly (
Fri, 21 Oct 1994 16:19:30 -0500

In message <>, Larry Masinter write
>In general, any unknown scheme should be parsed to the proxy server

Are there exceptions for fragment identifiers, and search terms, and
relative paths, or not? For example:

<p>See <a href="urn:234lkj23/4lk2j#section1">section 1 of "The
Birds and The Bees</a> for more info.

If the user selects the link, what data goes to the proxy?
GET urn:234lkj23/4lk2j#section1 HTTP/1.0
GET urn:234lkj23/4lk2j HTTP/1.0

RFC1630 would suggest the latter. The current URL specs would suggest
the former, although it's not clear that it necessarily answers this
question. It's possible that a WWW client should remove #... at the
end of an HREF attribute before considering it as an internet URL.

Then suppose the resulting document (let's suppose the answer above is
urn:234lkj23/4lk2j ) contains:

<head><isindex><title>An Example</title></head>
<p> See <a href="../overview.html">the overview</a> for
more info.

What if the user selects that link? Is this an error? Must the process
of resolving urn:234lkj23/4lk2j yield some "local" address (ala the
HTTP URI: or Location: header or the HTLM <BASE> tag) for use
with relative HREF's?

Then suppose the user enters "frogs and dogs" as search keywords for
the ISINDEX search. What data goes to the proxy? RFC1630 would

GET urn:234lkj23/4lk2j?frogs+and+dogs HTTP/1.0

I suppose <isindex> doesn't have to work with methods besides http and
wais, but there's no reason for it not to. But perhaps a <FORM> is
necessary to search databases using other schemes...

>Frankly, I've never seen a need for multiple proxy servers. Has anyone
>ever used a different proxy for one protocol vs the other?

It's ironic that you would ask that in response to Michael's question:
clearly his scenario (testing a urn: proxy) motivates a capability to
select different proxies for different services. But it's not clear
that this feature is widely used...