RE: [xri] an ambiguity in the ABNF

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

Mike, funny, but I was thinking about this myself last week when testing out
the simplified XRI 1.1 path proposal.

This problem actually existed in XRI 1.0 as well, because a relative XRI has
always been a legal XRI value, and a relative XRI could start with the same
characters as a URI/IRI. And in fact when we ran across the problem then, we
realized that it exists in URI syntax as well, because a relative URI can
start with the same chars as a URI scheme name.

So we solved it in XRI 1.0 the same way the original RFC2396 solved it by
including the following text in section 2.3.2:

***BEGIN QUOTE FROM XRI 1.0 SECTION 2.3.2***

[RFC2396] points out that relative URI references with an initial segment
containing a colon may be subject to two interpretations:

	"Authors should be aware that a path segment that contains a colon
character cannot be used as the first segment of a relative URI path (e.g.,
"this:that"), because it would be mistaken for a scheme name. 

	"It is therefore necessary to precede such segments with other
segments (e.g., "./this:that") in order for them to be referenced as a
relative path."

Relative XRI references can be similarly misinterpreted. Therefore if any
segment prior to the first forward slash ("/") character in a relative XRI
reference contains a colon, the relative XRI reference must be rewritten to
begin either with a "." or a "./". Thus, "foo:bar" becomes ".foo:bar" or
"./foo:bar" and "foo.bar:baz" becomes ".foo.bar:baz" or "./foo.bar:baz".
Note that by the rules of sections 2.3.2 and 2.4.3, this transformation does
not affect equivalence.

***END QUOTE FROM XRI 1.0 SECTION 2.3.2***

With XRI 1.1, I'd suggest we keep the same solution, only due to our
increased alignment with RFC2396bis, we use only "./" as the prefix (since
"." alone will no longer have any special meaning in the path.)

=Drummond  


-----Original Message-----
From: Lindelsee, Mike [mailto:mlindels@visa.com] 
Sent: Tuesday, September 07, 2004 1:43 PM
To: xri@lists.oasis-open.org
Subject: [xri] an ambiguity in the ABNF

While working on the ABNF I've noticed an ambiguity that I'm not completely
sure how to deal with and thought I'd ask the list for thoughts and/or
recommendations.  The relevant production is:

   xref            = "(" ( xri-value / IRI ) ")"

I won't give the supporting productions, but the issue is that an xri-value
can be a relative-path (i.e., a path not prefixed by a "/").  This means
that in some cases, it couldn't be determined if the value of an xref is an
XRI or an IRI.  For example:

    (mailto:mlindels@visa.com)

could be interpreted as either.

Anyway, my questions are: (1) does the ambiguity matter and (2) if the
ambiguity matters, does anyone see an obvious way to fix this without
causing problems for XDI use cases.  For instance, we could only allow
absolute XRIs in cross references, but I'm not sure that would be an
acceptable solution.

Mike

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
.