W3C home > Mailing lists > Public > www-tag@w3.org > January 2009

RE: Meaning of names and operations of services

From: Larry Masinter <masinter@adobe.com>
Date: Fri, 30 Jan 2009 08:47:55 -0800
To: "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>
CC: Lisa Dusseault <lisa@osafoundation.org>, Mark Nottingham <mnot@mnot.net>, "www-tag@w3.org WG" <www-tag@w3.org>
Message-ID: <8B62A039C620904E92F1233570534C9B0118C85153BE@nambx04.corp.adobe.com>

Noah wrote:
> I should be able to discover the correct interpretation of what I
> find by application of specifications that are discoverable,
> recursively, from references from the URI specification itself.

Yes, you "should be able to" do that.

It's one thing to recommend this as a good practice, and another thing
to design languages whose meaning and stability depend on it being

> So, while I agree with the quote from you as far as it goes, you
> imply that what IANA chooses to do is therefore of low importance.

It is important that organizations fulfill their charter. IANA has a
charter to maintain and publish its registries. Originally, this
was done by periodically publishing a RFC with lists of all registered
values. RFCs were available from replicated FTP sites around the
Internet. As the registries grew, this method of publication became
impractical, and it started making the lists of registered values
available on the net, and eventually by running a web site.

It is not part of IANA's charter, funding, or mandate to run a web
site according to the design principles of W3C TAG findings. In the
future, IANA is as likely to make registries available via other
methods of net publication as it is via HTTP.

> The question, I think, is not whether they are running some random
> service, but in particular a Web server that will respond to HTTP
> GETs for the URIs identifying certain abstractions.

It's clear to me that IANA has no good reason to accept that as 
part of its charter; it's not part of IANA's operational contract
to run a Web server to do so.

Moving the registry from iana.org to w3.org doesn't help.  W3C itself
does not have a trust that can insure that, even if the W3C Foundation
fails to acquire donations or in 2035 the W3C organization disbands,
having completed its work, that there would continue to be a "w3.org"
web site.

> While the meaning of those URIs does not "depend" on what the server
> does, it is very important that the URI refer to one thing and not
> more,

I think that's a lost cause; of course the same URI can be used in
different contexts to refer to different things, even without
quibbling about "refer" and "thing".

That may be unfortunate but it's a fact to be taken into

> it's desirable that representations be available if the resource is
> an information resource or that a URI with descriptions be available
> (presumably through redirection) if not, and that any
> representations returned be faithful to the underlying resource.

This may or may not be desirable at any point in time, but
it is a bad idea to design other specifications so that it
is necessary.

> Whether the particular solution proposed in resolving httpRange-14
> is the best one is hard to say.

Personally, I "httpRange-14" was a response to an unresolvable

> Whether it's practical to deploy seems to be the subject of ongoing
> debate in various communities.

I'm not even sure what "deploy" means in this context. Practically,
you could think about setting up a foundation with a large enough
trust to insure the continued operation of IANA.org and their web
site, but over time, even that isn't a guarantee that they will
continue operations for as long as "describedBy" should have meaning.

> Still, I agree with Tim that the costs of reopening the decision
> would be very high at this point.

I have no interest in reopening the decision for httpRange, I just
think it's a bad idea to try to put its deployment on the critical
path to writing other meaningful specifications, or as a top
priority for W3C.

> So, I think we should at least try hard to make it work.

I don't think making httpRange-14 "work" is anywhere close to a top
priority for W3C; there are too many other architectural issues
pressing that are crucially important to the survival of the
organization as a meaningful voice in insuring the function of the

Received on Friday, 30 January 2009 16:48:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:26 UTC