Making XRI Authority be a URI-style authority

["Dave McAlpin" <Dave.McAlpin@epok.net>]

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