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:">mailto:</A>]<BR>
>Sent: Fri 10/22/2004 11:51 AM<BR>
>To: <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--
