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] Local-part simplification proposal

Gabe, my message probably overlapped on the wire. Yours and Mike's proposal
addresses cross-references, but doesn't say anything about persistent
identifiers. It may be that cross-references are the only XRI feature that
needs to be addressed in the path from an ABNF standpoint. However, if you
agree with my point that persistence is a second key XRI feature that *can*
extend to all levels of the path, would your proposal be any different to
accommodate this?

Also, we will need to adjust the xri-char productions to only allow those
that are not in RFC2396bis gen-delimins.


-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Monday, August 30, 2004 2:03 PM
To: xri@lists.oasis-open.org
Subject: [xri] Local-part simplification proposal

Mike Lindelsee and I have discussed the suggestion, made on the most recent
XRI editors call, that we investigate what the implications of a
"simplification" of the local part production would entail. From our (Mike
and I) point of view this simplifcation is motivated by a strain between the
definitions of some of the subsegment delimiters in XRI and the proposed
uses of these delimiters in XDI. (ie the combinations of ! and * to mean
something separate from their use individually). 

Also, several of us have wondered out loud what the point of defining the
structure of the local part of the XRI so specifically would be. 

Mike and I feel that the only structure that XRI really needs to define in
the local part of the XRI (besides the slash-delimited segments as defined
in RFC 2396bis) is cross references. While we expect subsegment delimiters
to be useful in many applications such as XDI, we do not feel there is a lot
of value in baking in their meaning and use in the XRI specification if they
have no impact on processing within the XRI specification. Cross-references,
even in the local part, *do* impact processing (in the XRI to IRI
normalization transformation), so we believe they should be defined even in
the stripped down BNF proposed here. Subsegment delimiters in the local
part, as far as we can tell, do not impact any XRI-specified processing and
so we believe there is much less of a reason for them to appear as special
characters in the local part.

So here's our proposed simplified BNF (pay attention to the new local-part
and lchar productions - the xri production is not intended to be a new rule
- I just don't have the old BNF in front of me at this second):

xri = xri-auth [local-path] [query] [fragment]
local-part = "/" *(lchar/xref) [local-part]
lchar = all legal XRI characters except /()?#

This allows for a superset of XRI 1.0 syntax and even the currently proposed
XRI 1.1 syntax. In particular, it allows for arbitrary combinations of * and
! and other pchars, and it also allows strings of cross references
unseparated by a subsegment delimiter -- i.e. @foo*bar/(+xref)(+otherxref)

We believe this proposal would provide just enough specification to enable
other specifications like XDI to extend XRI by defining new meaning for
characters in the localpath segment, including *perhaps* the way in which
those strings are tokenized or parsed. The only common processing rules
about XRI localpath parts will be those in the current XRI-normal to
IRI-normal transformation rules we have now. But since XRIs, even as defined
today, define no application-general processing rules outside the
transformation, so we really aren't losing that much, in terms of what code
actually might do. 

I'd note that this brings us even closer to alignment with the spirit of
2396bis which defines a lot of restrictions and structure on the authority
part, but leaves the localpath to be fairly freeformed. 

I believe then that the XDI use of XRI would be impacted only in the sense
that the XDI specification has to speak more about the structure of the

As usual, this stuff is subtle and its quite likely there are issues with
the proposal we may have overlooked. Feedback and discussion welcomed.

Chief Systems Architect
Technology Strategies and Standards
Visa International 
Phone: +1.650.432.3696   Fax: +1.650.554.6817

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]