[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] XRI 1.1 issue: star syntax semantics
It's too late to respond to the technical issues here before the call, but I think we need to address the proposed requirement for relative resolution of subsegments before we modify syntax to support it. 1) Should we consider a new relative resolution algorithm for subsegments? 2) If we should, what are the rules? Just a list of examples would be instructive. 3) How do we reconcile these rules with relative resolution as defined by 2396bis? In other words, if a non-XRI aware processor applies standard resolution rules, is the result equivalent to the rules proposed in 2? If not, what are the implications for URI compatibility? I think we need to address these issues independently before we suggest that we've somehow demonstrated that * must be a separator. Dave > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Tuesday, August 03, 2004 3:32 PM > To: xri@lists.oasis-open.org > Subject: [xri] XRI 1.1 issue: star syntax semantics > > 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 > }}} > > > > > > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to http://www.oasis- > open.org/apps/org/workgroup/xri/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]