Making XRI Authority be a URI-style authority

Overview

 

The draft of 2396bis on which XRI 1.0 relied (draft 3),
defined authority in a way that disqualified XRI authorities (@epok or =dave,
for example). That's the reason there's no // in an XRI like xri:@epok - //
must be followed by a 2396bis-style authority and @epok didn't qualify. This
changes in the current draft of 2396bis, where most restrictions on the form of
authority have been removed. This opens the possibility of making an XRI
authority be a URI-style authority.

 

Why use a URI-style authority?

 

An XRI in "URI normal form" is currently not a
valid URI because relative resolution rules as defined by 2396 and 2396bis do
not apply. For this reason, a relative XRI, even in URI normal form, can _only_
be used in a context that explicitly understands and expects an XRI.
Consequently XRIs are only partially URI compatible.

 

Here's an example. Imagine that the base XRI is xri:@epok
and the relative XRI is /dave. We'd like relative resolution to produce xri:@epok/dave,
but this only works with implementations that are aware of the special
processing rules for XRIs. If the above is used in a generic context like an
HTML anchor tag, the result of relative resolution is xri:/dave. If, on the
other hand, we change the XRI authority (@epok, in this example) to be a URI
authority, we'd have a base XRI of xri://@epok and relative resolution in any
context would yield xri://@epok/dave.

 

What's the cost?

 

There are three main problems with making an XRI authority
be an authority per 2396bis:

 

1) We currently depend on // to introduce a DNS-based
authority, so we'd need to invent some syntax to distinguish between a
DNS-based authority and an XRI authority.

 

2) The authority component must be case insensitive.

 

3) Two important characters have special meaning in
authority component - the at sign ("@") and colon (":").

 

The first two points don't seem like big issues to me, but
I'm happy to discuss them if someone sees a problem. The third point, though,
is problematic since both @ and : have defined semantics for XRI authorities.
The straigtforward way to deal with this is simply to escape those characters
in an authority component during the transformation to IRI normal form. For
example, the following XRI in XRI normal form

 

xri://@example:1:2:3/foo/:4:5

 

in IRI normal form would become

 

xri://%40example%3A1%3A2%3A3/foo/:4:5

 

This is obviously hard to read, but it's similar to the
required encoding for international characters in a URI. It's also worth
remembering that many XRIs have to be heavily escaped when they're transformed
to URI normal form (see sections 2.2.4.3 and 2.2.4.4 in XRI Core for examples).

 

Another option, of course, is to use different characters
for @ and :. The exclamation point ("!") has been suggested as a
replacement for colon. If we went that route, we'd have this XRI in XRI normal
form

 

xri://@example!1!2!3/foo/!4!5

 

and the same XRI in IRI normal form would be

 

xri://%40example!1!2!3/foo/!4!5

 

The @ character could potentially be handled the same way.

 

Dave