[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis
Looks good to me as well, but some questions... (1) Is this XRI valid? xri:@example*:23:45 (2) If valid, would it represent 4 resolution steps: 1: @ 2: .example 3: *:23 4: *:45 With the '. on 1: and the '*' on 4 being implicitly stated. (3) If the above XRI is suppose to respresent 4 resolution steps do not the new rules result in only 3 steps? As :23:45 would be considered one segment. Thanks, Bill Barnhill ----- Original Message ----- From: "Lindelsee, Mike " <mlindels@visa.com> Date: Friday, August 20, 2004 12:42 pm Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis > Good point. Your changes work for me. > > Mike > > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Thursday, August 19, 2004 11:01 PM > To: Lindelsee, Mike ; xri@lists.oasis-open.org > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis > > > > Problem: this last BNF would not allow xri-auth-delims (! and *) > in a path segment. > > > > I'm thinking that while the initial proposal to generalize the > subsegment delimiters was intended to make things simpler, the > problem Mike pointed out actually makes it more complex than > another approach: putting just two delimiters (! and *) into "xri- > sub-delims", then putting all the rest of the URI sub-delims into > a new "xri-alt-delims". Now xri-pchar can include xri-alt-delims > just like URI pchar includes URI sub-delims in RFC2396bis. > > > > > So we'd have: > > > > xri-gen-delims = "/" / "?" / "#" / "[" / "]" / "@" / "(" / > > ")" / "$" / "+" / "=" > xri-sub-delims = "!" / "*" > > xri-alt-delims = "&" / ":" / ";" / "," / "'" > > xri-pchar = xri-unreserved / pct-encoded / xri-alt-delims > > > > sub-segment = ( *xri-pchar / xref ) > nz-sub-segment = ( 1*xri-pchar / xref ) > > > > xri-segment = sub-segment *( xri-sub-delims sub-segment ) > nz-segment = nz-sub-segment *( xri-sub-delims nz-sub- > segment ) > > XRI-authority = ( gcs-char [xri-sub-delims] [ nz-segment ] ) / > xref-authority > relative-path = xri-segment * ( "/" xri-segment ) [ "?" xri- > query ] > [ "#" xri-fragment ] > xref-authority = xref *( xri-sub-delims nz-sub-segment ) > > > > > > =Drummond > > > > > _____ > > > From: Lindelsee, Mike [mailto:mlindels@visa.com] > Sent: Thursday, August 19, 2004 2:25 PM > To: xri@lists.oasis-open.org > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis > > > > It seems to me that if we drop xri-path-delim (absorb those > characters back into xri-sub-delim), and include xri-auth-delim in > xri-gen-delim (and correct the relevent productions), we solve > Dave's first concern. Fixing the XRI authority to support "@!" > (as well as the rest of the GCS characters) is actually really > easy in a consistent way -- just add an optional xri-auth-delims > after the gcs-char in the XRI-authority production (see below for > the updated ABNF productions). Changing the production would > allow for "@*" as well. While we can probably consider this as > the default meaning of a single GCS character (such as "@"), I > like the regularity of supporting it explicity. > > > > The problem that I have with allowing the characters in xri-sub- > delims both delimit a sub-segment and to be part of a sub-segment > (by being part of xri-pchar) is that it creates an ambiguity as to > what constitutes a sub-segment. For example, is the local path > in the following xri composed of 2 or 3 sub-segments? > > > > xri://@corp/a;b;c > > > > According to the ABNF (if xri-sub-delims are both used in the xri- > path-segment production and in the xri-pchar production), one > could consider the sub-segments to be (1) a, b, and c, (2) a;b and > c, or (3) a and b;c. I'd prefer to avoid introducing the > ambiguity if at all possible. > > > > My recommendation is to make the changes below and also exclude > xri-sub-delims from the xri-pchar production. > > > > Mike > > > > Updated Changes to ABNF > > --------------------------------------- > > > > xri-sub-delims = "&" / ":" / ";" / "," / "'" > xri-auth-delims = "!" / "*" > > xri-gen-delims = "/" / "?" / "#" / "[" / "]" / "@" / "(" / > > "(" / ")" / "$" / "+" / "=" / xri-auth-delims > > xri-auth-segment = auth-sub-segment *( xri-auth-delims auth-sub- > segment ) > xri-path-segment = path-sub-segment *( xri-sub-delims path-sub- > segment ) > > XRI-authority = ( gcs-char [xri-auth-delims] [ xri-auth- > segment ] ) / xref-authority > relative-path = xri-path-segment * ( "/" xri-path-segment ) [ > "?" xri-query ] > [ "#" xri-fragment ] > xref-authority = xref *( xri-auth-delims auth-sub-segment ) > > auth-sub-segment = ( 1*xri-pchar / xref ) > path-sub-segment = ( *xri-pchar / xref ) > > xri-pchar = xri-unreserved / pct-encoded / xri-sub-delims > > > > > > > > > > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Wednesday, August 18, 2004 4:20 PM > To: 'Dave McAlpin'; Lindelsee, Mike ; xri@lists.oasis-open.org > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis > > Agreed. Then, Dave, do you agree with Mike's suggestion of > creating a new "delims" category for xri-auth-delims? > > > > I'm beginning to wonder if the generalized treatment of > subsegments in the proposed XRI 1.1 path is worth the trouble. > Would it be simpler to just define * and ! as the two sub-delimins > and then let the other subdelims be part of the path? That way > they will be available for all producer-specific algorithms anyway > > > > Mike, do you think it would be simpler to just have an "xri-path- > delim" production for * and ! ? In that case the XRI authority > segment and the path segments could go back to being the same. > > > > Mike, one thing that occurred to me this morning: we can't > eliminate null subsegments in the XRI authority segment without > knocking out using ! after a GCS character (e.g., "@!1234"), as by > the current BNF, ! is proceeded by a null subsegment. We'd either > have to otherwise change the BNF to support that (taking us back > into "decorator" land) or simply have tight resolution rules about > null subsegments. > > > > =Drummond > > > > > _____ > > > From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] > Sent: Wednesday, August 18, 2004 2:51 PM > To: Lindelsee, Mike ; xri@lists.oasis-open.org > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis > > > > Unless there's a compelling reason to do otherwise, I'd suggest > that we move "*" and "!" back to xri-gen-delims. > > Dave > > > -----Original Message----- > From: Lindelsee, Mike [ mailto:mlindels@visa.com] > Sent: Wed 8/18/2004 1:13 PM > To: xri@lists.oasis-open.org > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis > > Do you think that we should place "*" and "!" in gen-delims then? > Or are my proposed changes ok as they stand? > > Mike > > -----Original Message----- > From: Dave McAlpin [ mailto:Dave.McAlpin@epok.net] > Sent: Wednesday, August 18, 2004 12:58 AM > To: Lindelsee, Mike ; xri@lists.oasis-open.org > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis > > > > I intentionally included xri-sub-delims in xri-pchar, and this was > correct in the original ABNF. Since then, someone moved sub- > segment delimiters from xri-gen-delims to xri-sub-delims. I think > this is just a misunderstanding of what I intended for xri-sub- > delims. The idea (borrowed from 2396bis), is that xri-gen-delims > are delimiters for which we define semantics and are reserved for > the purpose defined in the spec. In contrast, xri-sub-delims are > reserved as delimiters with no defined semantics, intended for > processor specific algorithms. > > Dave > > > -----Original Message----- > From: Lindelsee, Mike [ mailto:mlindels@visa.com] > Sent: Tue 8/17/2004 4:23 PM > To: xri@lists.oasis-open.org > Subject: [xri] Initial proposed XRI 1.1 ABNF and issues analysis > > I've taken a look at the proposed ABNF and would like to recommend > a couple of changes. First, I think we should be relatively > strict in the authority part and restrict the segment delimiters > to only those that are valid delimiters. My concern is that > showing other delimeters in the authority part will imply to > people reading the ABNF that those delimiters might have some sort > of meaning. The second change is to remove the support for null > segments in the authority part. While there is an XDI use for > null segments in the path part, it doesn't seem to be needed in > the authority part. And not allowing null segments in the > authority part helps to keep resolution as simple as possible. > > I also noticed what might be a bug -- the inclusion of xri-sub- > delims in the xri-pchar production. This allows segment > delimiters to be embedded within segments. I don't think that > this makes sense (Dave, please correct me if I'm wrong on this). > > Mike > > > Proposed changes to the updated XRI ABNF > ---------------------------------------- > (change) xri-sub-delims = xri-auth-delims / xri-path-delims > (add) xri-auth-delims = "!" / "*" > (add) xri-path-delims = "&" / ":" / ";" / "," / "'" > > (remove) xri-segment = sub-segment *( xri-sub- > delims sub-segment ) > (add) xri-auth-segment = auth-sub-segment *( > xri-auth-delims auth-sub-segment ) > (add) xri-path-segment = path-sub-segment *( > xri-sub-delims path-sub-segment ) > > (change) XRI-authority = ( gcs-char [ xri-auth-segment ] > ) / xref-authority > (change) relative-path = xri-path-segment * ( "/" xri- > path-segment ) [ "?" xri-query ] > [ "#" xri-fragment ] > (change) xref-authority = xref *( xri-auth-delims auth- > sub-segment ) > > (remove) sub-segment = ( *xri-pchar / xref ) > (add) auth-sub-segment = ( 1*xri-pchar / xref ) > (add) path-sub-segment = ( *xri-pchar / xref ) > > (change-bug)xri-pchar = xri-unreserved / pct-encoded > > > > > > > > > > > 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]