[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
My intent is reflected, I think, in a subsequent email. If a relative = XRI starts with an xref, it should be preceded with ./ Dave ------_=_NextPart_001_01C4BC83.6DEF960C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7226.0"> <TITLE>RE: [xri] Stable XRI 1.1 ABNF</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>Comments inline<BR> <BR> Dave<BR> <BR> <BR> >-----Original Message-----<BR> >From: Lindelsee, Mike [<A = HREF=3D"mailto:mlindels@visa.com";>mailto:mlindels@visa.com</A>]<BR> >Sent: Fri 10/22/2004 11:51 AM<BR> >To: xri@lists.oasis-open.org<BR> >Subject: Re: [xri] Stable XRI 1.1 ABNF<BR> ><BR> >It took a little while, but Gabe and I have worked through the ABNF = and<BR> >have a couple of comments/recommendations.<BR> ><BR> >1. In xri-hier-part, iauthority is used. This allows an = IRI authority that<BR> > can't be distinguished from an XRI = authority. The problem is with the<BR> > iuserinfo part of iauthority -- @ihost is = allowed. This could just as<BR> > easily be an XRI authority. Our = recommendation is to use ihost (or a<BR> > similar production) instead of iauthority. = We believe that the goal is to<BR> > allow authorities based on IP addresses and DNS = names. It isn't clear that<BR> > keeping the iuserinfo part is meaningful in the = context of XRI.<BR> ><BR> <BR> I think we've discussed this before. An XRI like @foo is disambiguated = in the current BNF by the "greedy algorithm" - xri-authority = has a higher priority than iauthority, so @foo is interpreted as an = xri-authority. Effectively the current BNF doesn't allow an empty = username. We can emphasize this in text.<BR> <BR> >2. ireg-name (the production that is used to allow DNS names) = allows strings that<BR> > are not legal DNS names. While IRI allows = this, our opinion is that in XRI,<BR> > we should further restrict this to support only = valid DNS names. This turns out<BR> > to be quite a chore, though, if we allow = internationalized DNS names.<BR> <BR> I disagree. IRI defines the transformation from ireg-name to a legal DNS = name. The idea is to allow a fully internationalized IRI and just to = refer to to the IRI spec for conversion rules to a legal URI. I really = don't want to reproduce that transformation.<BR> <BR> ><BR> >3. Is the absolute-XRI production just for parallelism with = IRI? It's not clear<BR> > why we need it in XRI.<BR> <BR> We have it for the same reason RFC2396bis has it - so there's a = production that local resolution can point to that drops the fragment = before operations (like retrieval) are performed on the resource.<BR> <BR> ><BR> >4. There doesn't seem to be a need to restrict the first = segment in the path to<BR> > being a non-null segment. IRI needs to do = this to avoid ambiguity, but the XRI<BR> > ABNF doesn't have this ambiguity. Our = recommendation is to replace the<BR> > xri-path-absolute production as follows:<BR> ><BR> > xri-path-absolute =3D = "/" [ xri-segment ] *[ "/" xri-segment]<BR> ><BR> > This would allow us to get rid of the = xri-segment-nz and xri-subseg-od-nz<BR> > productions.<BR> ><BR> <BR> I considered this, but disallowing //foo does two things - it avoids a = potentially misleading XRI (in //foo, foo looks like an authority) and = it avoids an awkward rule when transforming to a URI. I left this in on = purpose and, unless there's a compelling to allow it, I suggest we keep = the current restriction.<BR> <BR> >5. The ABNF explicitly disallows cross references as the first = segment of a<BR> > relative XRI. This is due to allowing = "xri://" to be optional. From our<BR> > perspective, it seems broken to disallow this = whole class of XRI's. For instance,<BR> > xri://@foo/(+SecurityPolicy) is allowed by the = ABNF but the relative XRI<BR> > "(+SecurityPolicy)" is always treated = as an absolute and therefore can never<BR> > be expressed in a relative form. Anyway, = our recommendation is that we should<BR> > either require "xri://" in all absolute = XRI's or take another careful look<BR> > at what we are doing to the XRI syntax to = accomodate "xri://" being optional.<BR> <BR> My intent is reflected, I think, in a subsequent email. If a relative = XRI starts with an xref, it should be preceded with ./<BR> <BR> Dave<BR> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C4BC83.6DEF960C--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]