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,

  http://www.example.com/blah.dtd

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 
DNS).

> > 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 ...

Cheers,


Miles

-- 
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