W3C home > Mailing lists > Public > uri@w3.org > February 2001

RE: My 2c on scheme abuse

From: Miles Sabin <MSabin@interx.com>
Date: Mon, 5 Feb 2001 17:56:13 -0000
Message-ID: <23CF4BF2C499D411907E00508BDC95E116FBF1@ntmews_01.interx.com>
To: uri@w3.org
Mark Baker wrote,
> Miles Sabin wrote:
> > Sadly HTTP URLs _will_ be resolved even when that's 
> > unnecessary for them to be meaningful as bare identifiers. 
> > And if they are, then servers (particularly ones hosting 
> > extremely popular DTDs or namespaces) might well be in 
> > trouble.
> Will they be resolved by the origin server enough that it's a 
> problem? How do you know?

What's 'often enough' to cause a problem? It could be quite a low
frequency. How do I know? I don't ... and I don't want hostages 
left to fortune.

> > xml-dev's RDDL or anything similar, if widely adopted, would 
> > put namespaces more or less on a par with DTDs on the 'XML 
> > parsers running off to get stuff' front.
> I couldn't disagree more.  It is a requirement on validating 
> parsers that the DTD be retrieved.  It is not a requirement on 
> any existing piece of software that a representation of an XML 
> namespace be retrieved.

What have requirements got to do with anything? There's no
requirement that non-validating parsers retrieve DTDs, but some
do (I believe that Suns/Crimson did at one time, maybe still
does). Mutatis mutandis for namespace URIs and anything that
might be hanging off the end of them.

> > These aren't problems with either DTDs or namespace URIs per 
> > se. The problem is using a protocol (and, by extension, 
> > encoding that protocol in an identifier via a scheme) which 
> > doesn't support distribution and replication in a way which 
> > is appropriate for this kind of situation.
> The architecture of the Web, and the design of URIs and HTTP, 
> is meant to accomdate *exactly* this situation.  What exactly 
> does HTTP not do that you need?

Huh? If my client isn't configured to use a proxy (either 
directly or transparently) then if I try to retrieve,


it goes off and hits www.example.com. What current, widely 
deployed, widely applicable, mechanism is there for redirecting 
that request elsewhere? Even if my client is configured to use
a proxy, the proxy might not have that resource cached.

By 'widely applicable', I mean a mechanism which can be applied 
to a 'hot' resource without the hosting site having to be 
radically rejigged (eg. wholesale delegation to a third party via 

> > You've mentioned an Akamai-type solutions to this problem. I
> > don't see how that's supposed to help ... could you 
> > elaborate?
> Just that URL resolution (including HTTP URLs) need not ever 
> reach the origin server.

More detail please ...



Miles Sabin                               InterX
Internet Systems Architect                5/6 Glenthorne Mews
+44 (0)20 8817 4030                       London, W6 0LJ, England
msabin@interx.com                         http://www.interx.com/
Received on Monday, 5 February 2001 12:56:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:02 UTC