RE: [xri] an ambiguity in the ABNF

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

My instinct would be yes, we should follow RFC2396bis on this.

=Drummond 

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

Right.  This problem has been fixed in the 2396bis ABNF as well.  It
explicitly requires that the first segment either start with a "/" or that
that first segment not have a colon embedded in it.  Does it make sense to
follow the 2396bis grammar on this?

Mike

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