[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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: IMPORTANT:
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… xri.net/=person/+contact …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… xri.net/=person/(+contact) 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.: xri.net/=person/(mailto:john.doe@example.com) 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: <Path>(+contact)</Path> 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 reasons). 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. =Drummond |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]