[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] an ambiguity in the ABNF
OK, well, we didn't call out that case in the cross reference - I had forgotten that we allowed relative XRI values in cross references in 1.0... __________________________________________________ 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:45 PM > To: Wachob, Gabe; Lindelsee, Mike ; xri@lists.oasis-open.org > Subject: RE: [xri] an ambiguity in the ABNF > > > 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 .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]