Local-part simplification proposal

["Wachob, Gabe" <gwachob@visa.com>]

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 localpart. 

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

	-Gabe
 
__________________________________________________ 
gwachob@visa.com
Chief Systems Architect
Technology Strategies and Standards
Visa International 
Phone: +1.650.432.3696   Fax: +1.650.554.6817