From: Drummond Reed [mailto:email@example.com]
Sent: Saturday, May 27, 2006 5:11
Subject: [xri] Proposed
autocorrection rule for HXRIs
Wil has raised a key question regarding the path matching
rule stated on line 1381 of XRI Resolution 2.0 Working Draft 10 (http://www.oasis-open.org/committees/download.php/17293/xri-resolution-v2.0-wd-10.pdf).
This rule currently reads:
If there is no match, this comparison MUST be repeated after
enclosing the value of the Path String parameter in parentheses
(“(“ and “)”). This eliminates the need for XRD authors
to specify multiple xrd:Path elements in order to match an
XRI path that may or may not be expressed as a cross-reference.
The purpose of this rule was to enable humans to type a
simple HXRI such as…
…into a browser address bar and have it resolved via
proxy resolution to a Web page for contacting the identified person.
Technically this is not a legal HXRI, i.e., to be syntactically correct, it
needs to be…
The parentheses are required around “+contact”
because it is an absolute XRI by itself, and therefore if used anywhere except
at the start of the authority segment of the XRI, it must be expressed as a
cross-reference, i.e., enclosed in paratheses. The same is true for any XRI or
URI embedded in an XRI, e.g.:
However, because it is unrealistic to expect human users to
understand/remember/type XRI cross-reference syntax (even many developers
don’t like typing it), the proposed path matching rule above would
instruct the resolver to match either the path “+contact” or
“(+contact)” to the following Path element value:
In other words, if a human typed
“xri.net/=person/+contact”, the resolver would first try to match
the path “+contact” and find no match, but then it would try to
match the path “(+contact)” and get a match.
What Wil pointed out is that an XRI parser would actually
reject “xri.net/=person/+contact” as being syntactically invalid,
so a strict implementation that parsed the XRI to determine the path component
would error out BEFORE it ever got to path comparison. So Wil suggested that if
we are going to compensate for human lack of understanding and do
“autocorrection” of “xri.net/=person/+contact” to
“xri.net/=person/(+contact), we should not do it via modifying the path
comparision rules, but publish a set of rules for such autocorrection that: a)
apply to all QXRIs, b) are not ambiguous, c) do not introduce potential
security flaws, and d) are applied prior to formal XRI parsing (for obvious
I agree with Wil’s assessment, so I propose the
following autocorrection rule for HXRIs:
AUTO-CORRECTION RULE: If any segment of the path portion of
the QXRI embedded in an HXRI begins with either: a) a reassignable GCS character
(=, @, +, $), or b) with a double persistent GCS character (!!), then to be a
syntactically compliant XRI that segment MUST be enclosed in matching
parentheses. A compliant proxy resolver MUST automatically turn such an QXRI
into a valid XRI by adding these parentheses if either or both are missing. A
compliant local resolver SHOULD also perform this same autocorrection of XRIs.
Note that if we add this rule in Working Draft 11, we can
delete the path comparison rule currently defined starting on line 1381,
because autocorrection will have already been applied.
This is a important change for Working Draft 11, so please
post any feedback if you disagree.