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: [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 ./


Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
<TITLE>RE: [xri] Stable XRI 1.1 ABNF</TITLE>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Comments inline<BR>
&gt;-----Original Message-----<BR>
&gt;From: Lindelsee, Mike&nbsp; [<A =
&gt;Sent: Fri 10/22/2004 11:51 AM<BR>
&gt;To: xri@lists.oasis-open.org<BR>
&gt;Subject: Re: [xri] Stable XRI 1.1 ABNF<BR>
&gt;It took a little while, but Gabe and I have worked through the ABNF =
&gt;have a couple of comments/recommendations.<BR>
&gt;1.&nbsp; In xri-hier-part, iauthority is used.&nbsp; This allows an =
IRI authority that<BR>
&gt;&nbsp;&nbsp;&nbsp; can't be distinguished from an XRI =
authority.&nbsp; The problem is with the<BR>
&gt;&nbsp;&nbsp;&nbsp; iuserinfo part of iauthority -- @ihost is =
allowed.&nbsp; This could just as<BR>
&gt;&nbsp;&nbsp;&nbsp; easily be an XRI authority.&nbsp; Our =
recommendation is to use ihost (or a<BR>
&gt;&nbsp;&nbsp;&nbsp; similar production) instead of iauthority.&nbsp; =
We believe that the goal is to<BR>
&gt;&nbsp;&nbsp;&nbsp; allow authorities based on IP addresses and DNS =
names.&nbsp; It isn't clear that<BR>
&gt;&nbsp;&nbsp;&nbsp; keeping the iuserinfo part is meaningful in the =
context of XRI.<BR>
I think we've discussed this before. An XRI like @foo is disambiguated =
in the current BNF by the &quot;greedy algorithm&quot; - 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>
&gt;2.&nbsp; ireg-name (the production that is used to allow DNS names) =
allows strings that<BR>
&gt;&nbsp;&nbsp;&nbsp; are not legal DNS names.&nbsp; While IRI allows =
this, our opinion is that in XRI,<BR>
&gt;&nbsp;&nbsp;&nbsp; we should further restrict this to support only =
valid DNS names.&nbsp; This turns out<BR>
&gt;&nbsp;&nbsp;&nbsp; to be quite a chore, though, if we allow =
internationalized DNS names.<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>
&gt;3.&nbsp; Is the absolute-XRI production just for parallelism with =
IRI?&nbsp; It's not clear<BR>
&gt;&nbsp;&nbsp;&nbsp; why we need it in XRI.<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>
&gt;4.&nbsp; There doesn't seem to be a need to restrict the first =
segment in the path to<BR>
&gt;&nbsp;&nbsp;&nbsp; being a non-null segment.&nbsp; IRI needs to do =
this to avoid ambiguity, but the XRI<BR>
&gt;&nbsp;&nbsp;&nbsp; ABNF doesn't have this ambiguity.&nbsp; Our =
recommendation is to replace the<BR>
&gt;&nbsp;&nbsp;&nbsp; xri-path-absolute production as follows:<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xri-path-absolute =3D =
&quot;/&quot; [ xri-segment ] *[ &quot;/&quot; xri-segment]<BR>
&gt;&nbsp;&nbsp;&nbsp; This would allow us to get rid of the =
xri-segment-nz and xri-subseg-od-nz<BR>
&gt;&nbsp;&nbsp;&nbsp; productions.<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>
&gt;5.&nbsp; The ABNF explicitly disallows cross references as the first =
segment of a<BR>
&gt;&nbsp;&nbsp;&nbsp; relative XRI.&nbsp; This is due to allowing =
&quot;xri://&quot; to be optional.&nbsp; From our<BR>
&gt;&nbsp;&nbsp;&nbsp; perspective, it seems broken to disallow this =
whole class of XRI's.&nbsp; For instance,<BR>
&gt;&nbsp;&nbsp;&nbsp; xri://@foo/(+SecurityPolicy) is allowed by the =
ABNF but the relative XRI<BR>
&gt;&nbsp;&nbsp;&nbsp; &quot;(+SecurityPolicy)&quot; is always treated =
as an absolute and therefore can never<BR>
&gt;&nbsp;&nbsp;&nbsp; be expressed in a relative form.&nbsp; Anyway, =
our recommendation is that we should<BR>
&gt;&nbsp;&nbsp;&nbsp; either require &quot;xri://&quot; in all absolute =
XRI's or take another careful look<BR>
&gt;&nbsp;&nbsp;&nbsp; at what we are doing to the XRI syntax to =
accomodate &quot;xri://&quot; being optional.<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>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]