XRI 1.1 issue: star syntax semantics

["Drummond Reed" <drummond.reed@cordance.net>]

XRI Members and Observers,

Attached below, and posted at
http://xrixdi.idcommons.net/moin.cgi/XriChangeStarSemantics, is background
on one of the XRI 1.1 issues that will be discussed on the XRI Editor's SC
call today regarding the proposed star syntax.

=Drummond 


== Introduction ==

The XRI TC has already reached consensus that due to changes in RFC2396bis
[http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html], which made dot an
unreserved character
[http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#reserved], that a
different RFC2396bis reserved character needed to replace dot. 

The remaining issue with this change involves whether:

 a. Star should simply replace dot in the current XRI 1.0 syntax, so that
both star and colon are subsegment delimiters (as dot and colon were
subsegment delimiters), or
 a. Star should become the sole subsegment delimiter, and colon become the
sole "decorator" used to indicate a persistent subsegment.

== Argument for Separating Subsegment Delimiter and Persistence Decorator ==

A use case has arisen in XDI addressing which appears to leave us no choice
but to separate the roles of subsegment delimiter and persistence decorator
in XRI 1.1 syntax.

The use case is relative addressing of subsegments. The easiest way to
illustrate this use case is to start by showing the difference between two
existing types of relative XRIs in XRI 1.0: those that start with no leading
character, and those that start with slash as a leading character, e.g.:

{{{
:123
/:123
}}}

If the base XRI against which these relative URIs are being resolved is

{{{
xri:@:9999/:888/:77
}}}

then by current XRI relative resolution rules, the resulting XRIs would be

{{{
:123	-->	xri:@:9999/:888/:123
/:123	-->	xri:@:9999/:123
}}}

Now let's apply the same rules to relative resolution of subsegments. To
illustrate this, let's first assume that the roles of subsegment delimiter
and persistence decorator are separated, with star being the subsegment
delimiter and colon the persistence decorator. The following would
illustrate two different types of relative XRIs using this syntax:

{{{
:123
*:123
}}}

If the following was the base XRI

{{{
xri:@:9999/:888*:77/:66
}}}

then applying an analogous set of rules to relative resolution of
subsegments as those illustrated above for relative resolution of segments
would result in the following absolute XRIs:

{{{
:123	-->	xri:@:9999/:888*:77/:123
*:123	-->	xri:@:9999/:888*:123
}}}

As can be seen from this example, it would be impossible to support these
relative subsegment resolution rules if the roles of subsegment delimiter
and persistence decorator are combined. For example, if colon was both the
subsegment delimiter and persistence decorator, there would be no way of
telling which of the above two absolute XRIs should result from the
following relative XRI:

{{{
:123
}}}

Since the proposed XDI addressing rules for the v4 XDI metaschema make use
of relative addressing of subsegments at all levels of an XRI, to any depth,
the ability to distinguish between these two forms of relative XRIs is
vital.

== Proposed ABNF for XRI 1.1 Paths ==
If the roles of subsegment delimiter and persistence decorator are
separated, the ABNF for XRI segments and subsegments is also simplied. The
proposed ABNF for XRI segments (taken from
[http://xrixdi.idcommons.net/moin.cgi/Xri1dot1ProposedAbnf]) would be:


{{{
  xri-segment     = sub-segment  *( "*" sub-segment )

  sub-segment     = [ ":" ] ( 1*xri-pchar / xref )

  xri-pchar       = xri-unreserved / pct-encoded / xri-sub-delims
}}}

This simple pattern is repeatable for all XRI segments from GCS root nodes
down to any level of depth. No special equivalence rules are needed for
optional reassignable subsegment decorators, as are currently required for
dot in XRI 1.0.

== Option for Using ! as the Persistence Decorator ==
We would like to make syntax for XRI authorities conform to the reg-name
production in RFC2396bis (see the discussion at
[http://xrixdi.idcommons.net/moin.cgi/Xri1dot1ProposedAbnf#head-521400ffff86
fe4699a247e9d8631533fd96fd3b]). As shown below, reg-name does not permit
colon without escaping because colon is used to delimit the port from the
host.

{{{
  iauthority      = [ iuserinfo "@" ] ihost [ ":" port ]

  iuserinfo       = *( iunreserved / pct-encoded / sub-delims / ":" )

  ihost           = IP-literal / IPv4address / ireg-name

  ireg-name       = *( iunreserved / pct-encoded / sub-delims )

  iunreserved     = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar

  pct-encoded     = "%" HEXDIG HEXDIG

  sub-delims      = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="
}}}

Therefore if we wish to avoid the need to escape colons in XRI authority
segments, we should consider the use of a different character that is a
legal URI subdelim. One option is to use the bang character ("!"), which is
consistent with its proposed new XRI 1.1 use as the GCS character for
authority-independent identifiers (the "physical" namespace). Under this
option the ABNF for the XRI 1.1 path would become:

{{{
  xri-segment     = sub-segment  *( "*" sub-segment )

  sub-segment     = [ "!" ] ( 1*xri-pchar / xref )

  xri-pchar       = xri-unreserved / pct-encoded / xri-sub-delims
}}}

There is also a nice symmetry with the fact that an absolute physical XRI
would then begin with double bang, just the way an absolute URI under
2396bis begins with a double slash.

{{{
  xri:!!1234*!5678/!1A2B
}}}