RE: [xri] an ambiguity in the ABNF

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

Gabe,

I'm a little confused on the first point - XRI 1.0 also allowed relative
XRIs in cross-references (it allowed any legal XRI value). However our
requirement in the XRI 1.0 ABNF was (and I think should remain) that if the
value is a URI/IRI, then it MUST be an absolute value.

Therefore if you have a relative value, you know that it is a relative XRI.
So the only thing we need to disambiguate is whether it is a relative XRI or
the scheme name of an absolute URI/IRI.

If, as Mike says, the RFC2396bis ABNF now makes it clear that the first
segment of a relative URI/IRI cannot include a colon, and we follow suit,
then that ambiguity is gone, and the rules are now pretty simple: if a
cross-reference value begins with...

1) A dot or a slash, it is a relative XRI.
2) A sequence of letters or digits NOT followed by a colon, it is a relative
XRI.
3) A sequence of letters or digits followed by a colon, it is an absolute
URI.
4) Any other character (which should leave the GCS characters and opening
parentheses), it is an absolute XRI.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Tuesday, September 07, 2004 3:25 PM
To: Drummond Reed; Lindelsee, Mike ; xri@lists.oasis-open.org
Subject: RE: [xri] an ambiguity in the ABNF


Actually, the ambiguity you talk about Drummond happens in a different place
- yours is the ambiguity that occurs when you are expectings a URI reference
and you have a relative XRI that looks like a URI. If the colon is in the
first segment, you can't tell if you were dealing with a relative XRI or an
absolute URI. That problem actually remains, I think.

We have a *new* problem in the context of cross references because we are
allowing relative XRIs in the cross references. Its largely the same
ambiguity, we just have to apply the same rule *inside cross references*.
That would be at least one proposal.

Also, we have to talk about * and not . -- So *foo:bar or ./foo:bar instead
of just foo:bar ... 

	-Gabe


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


> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Tuesday, September 07, 2004 3:15 PM
> To: Lindelsee, Mike ; xri@lists.oasis-open.org
> Subject: RE: [xri] an ambiguity in the ABNF
> 
> 
> 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
> .
> 
> 
> 
> 
> 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.
> 
> 

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
.