OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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]