Hi Harald.
Harald Alvestrand wrote:
Julian Reschke wrote:
Well. There's definitively a total disconnect between that IESG
recommendation, and the W3C TAG's point of view (see ongoing
discussion on the TAG mailing list about the "xri" scheme).
It would be good when both organizations could come up with consistent
answers.
If a new URI scheme is defined, it needs to state what it identifies,
and how it is resolved. If it identifies an HTTP resource, and
resolution is done via HTTP, then it seems to me you don't need it.
Note: I totally disagree.
Interesting, as most of what follows is something I *do* agree with :-)
The point I was trying to make is that when a specification defines a
new URI scheme, it should be able to state what it identifies, and, if
it's intended to be resolvable, how that resolution process works.
This information isn't present in the HELD draft.
I detest, abhor and condemn the idea that there is such a thing as a
"HTTP resource".
I was using "HTTP resource" as in "something identified by an HTTP URL".
An URI identifies a resource.
Yes.
One possibility of accessing that resource is by using HTTP; if the URI
scheme is "http:", there is an implication that the definer of the URI
regarded this as the "normal" way of accessing the resource, and that
whether the resource is static, dynamic or changeable is a matter
strictly under the control of the manager of the server identified by
the hostname in the URI.
Yes.
Certain usages of HTTP (in particular, the use of HTTP URLs for XML
schemas) have tended to denigrate this implication, and say "you should
regard this as an identifier". Still, the usage is prevalent enough that
people have complained that servers identified in popular XML schemas
are getting hit with enough extra traffic to cause operational problems.
I've heard that as well, and tried to find out exactly *what* URLs were
causing the problem. As far as I can tell, it was always because of URLs
that were intended to be dereferenced, such as URLs of DTDs. (If this is
incorrect, I'd love to see a pointer...).
Now, many resources can be accessed over HTTP. And many more will be.
But in many cases, the guarantees given should be DIFFERENT; a "mid:"
URI means that "if you find a copy of the message with this message-ID,
it's probably the same message" - a "tag:" URI means "someone intended
this URI to be an unique reference, and you can figure out who it was
given enough time and effort". And I haven't even mentioned URNs yet.
Yes.
The WG needs to be clear about what kinds of resources it's identifying,
and what the properties it wants to embed as part of the URI scheme is.
Yes. This is what I was saying, wasn't I?
Usually, "all the features and warts of HTTP" won't be the answer.
>
I don't speak for anyone but myself. But just based on Julian's
comments, I stand with the IESG advice on this one, and think that the
W3C TAG (if its recommendation is reported correctly) is off in the weeds.
It seems to me that you have been reading something into my comments
that isn't there.
HELD (as in draft 08), defines two new URI schemes, does not define what
they identity, does not state how to resolve them, and has examples
using untested HTTP/1.1 features for resolution.
That's why I was asking whether a new naming scheme really is needed *here*.
BR, Julian
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf