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.
I detest, abhor and condemn the idea that there is such a thing as a
"HTTP resource".
An URI identifies a resource.
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.
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.
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.
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.
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.
Harald
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf