[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]