OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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]