On Thu, Aug 7, 2008 at 1:56 AM, Harald Alvestrand
<harald(_at_)alvestrand(_dot_)no> 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).
That discussion is just too long and gnarly to summarize, but without
touching on any of the actual technical issues:
There is a strong perception among quite a few people, notably
including the TAG, that the XRI people don't understand the
technologies they're trying to replace; many of their statements
beginning "XRI is needed because..." have been challenged as being
simply technically wrong.
The TAG is in fact clearly correct when they state that introduction
of new URI schemes is quite expensive. So it comes down to a matter
of cost/benefit, and a lot of people are not convinced that a real
benefit has been established for XRI, relative to the existing Web.
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.
Actually, no. There are lots of identifiers that do not have a
"resolution" requirement.
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.
This has happened, usually due to clueless implementors. The most
famous case is the DTD URIs appearing in the HTML <!DOCTYPE>, which
certain developers who will remain nameless tried to retrieve every
time they parsed an HTML page. Surprise surprise, it didn't work.
It's a real risk. Any identifier that can be used to retrieve
something will so be used, whether that's appropriate or not, and
that's a risk we have to work into our plans.
-Tim
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf