RE: Proposed issue: site metadata hook

> The architecture of the web is that the space of identifiers
> on an http web site is owned by the owner of the domain name.
> The owner, "publisher",  is free to allocate identifiers
> and define how they are served.
>
> Any variation from this breaks the web.  The problem
> is that there are some conventions for the identifies on websites,
> that
>
>     /robots.txt  is a file controlling robot access
>     /w3c/p3p is where you put a privacy policy
>     /favico   is an icon representative of the web site
>
> and who knows what others.  There is of course no
> list available of the assumptions different groups and manufacturers
> have used.
>
> These break the rule.  If you put a file which happens to be
> called robots.txt  but has something else in, then weird things happen.
> One might think that this is unlikely, now, but the situation could
> get a lot worse.  It is disturbing that a
> precedent has been set and the number of these may increase.

As far as the P3P's "/w3c/p3p" is concerned, this discussion already happened, so I expected to reply to this with a pointer to some
public email in www-p3p-comments, but after a search, I realized that in fact, no public response to this issue yet appeared.
This was tackled only internally (W3C-Team), at
http://lists.w3.org/Archives/Team/t-and-s/2001Jun/0138.html
from which I'll extract the relevant part to the public here, hoping to clarify history, and present state, on the P3P's side:

[[[
Here's my recollection of the matter (trying to play the historic memory of the wg here.. ;)
First,  a premise that I tried to get some relevant pointers from mailing lists/minutes, without success. Quite a frustrating
experience
clashing with w3c's search engine (sigh, wish we had some semantic web tools already in place...). Anyway, here's my "memory-only"
recollection:
The "well-known location" (WKL for short) proposal has been introduced quite some time ago (approx 1999) in a STRICT form (see
later), already at the time when Dan La Liberte
was in the wg. I remember this because we had an internal team discussion as well about this, esp. with him, who was in favour (like
some others in the wg),
versus my opposition. My "big no" at the time, raised in the wg, has been that setting such a fixed URI is not only is a hack, but
even clashes against Web Architecture
(capital letters please ;), as it breaks the Axiom of opaque URIs (cf. w3c's http://www.w3.org/DesignIssues/Axioms.html#opaque ):
URLs should be opaque, while that
way they are not, as we'd be reserving a particular meaning for some specific URIs.
Now, what happened at the time was that the WKL proposal was at the end rejected.
Later on in the wg (in 2000) the proposal came up again, because implementors found the current methods we had (headers) not very
feasable/easy to
deploy in IE.
Again I was raising the "opaque" objection...

   ...BUT (and here's the big but in the story...)...

...we found a compromise along the way: the WKL had been weakened, and
would have been an optional feature, meaning not only that the other P3P methods (like headers) to access policy reference files
would have been maintained, but (and more important), the WKL file
could have contained anything (even a GIF...), and only when the file was in the proper format it could have been interpreted by a
P3P agent as the corresponding policy
reference file.
This means a considerable weakening from the original WKL proposal (that didn't allow this), and as you can see this doesn't break
the Opacity axiom any more (no
more than the "/index.html" convention..;)
With this proviso, therefore, I felt like this was much safer and not really clashing with Web Architecture: still hacky and not
elegant, and personally not my favourite at
all, but something I could live with. And *without doubt*, something in fact very helpful for P3P's deployment in browsers. Giving
up elegance for deployment, so to say.
]]]

Older in time, always on the metadata vs fetch cycles compromise, there's the Jul 2000 post
"A trip into the Future: p3p.xml"
http://lists.w3.org/Archives/Member/w3c-p3p-specification/2000Jul/0002.html
which might be taken into practical consideration, orthogonally (and/or on top of) any proposed metadata redirection solution that
is employed.

-M

Received on Tuesday, 11 February 2003 20:49:55 UTC