RE: [xri] updated proposed XRI 1.1 ABNF

["Dave McAlpin" <Dave.McAlpin@epok.net>]

Mike,

Can you talk a little about the production for xri-path-noscheme. It's
only used in relative-XRI (via xri-path) and I understand that it's
intended to keep a relative XRI from looking like an absolute URI. We
wouldn't want to allow a relative XRI of http://www.epok.net, for
example. The way it's defined, though, doesn't seem right to me. If we
inline xri-subseg-nc-nx, we get

xri-path-noscheme = ( "*" / "!" ) 1*xri-achar *( "/" xri-segment )

relative-XRI can only start with an absolute path, an empty path or an
xri-path-noscheme. A relative XRI, then, must start with either "/",
"*", "!" or have an empty path. That means something like "foo" or
"foo/bar" is not a legal relative XRI. Is that the intent? It also means
the traditional way of fixing the first example -
"./http://www.epok.net"; - is illegal.

It's also odd that the first segment in a relative XRI is only allowed
to contain a single subsegment - "*foo*bar/baz" is also illegal. Was
there a reason for that?

Dave

> -----Original Message-----
> From: Lindelsee, Mike [mailto:mlindels@visa.com]
> Sent: Wednesday, September 22, 2004 3:20 PM
> To: xri@lists.oasis-open.org
> Subject: RE: [xri] updated proposed XRI 1.1 ABNF
> 
> Attached is an updated version of the 1.1 ABNF.  A number of issues
were
> raised and discussed on the editor's call yesterday.  The new ABNF
> addresses all but one of those issues.  To summarize, the issues (and
> their resolutions) were as follows.
> 
> 1.  Concern about allowing the "//" at the beginning of an XRI to be
> optional.  Resolution: "//" is never optional.  Absolute XRIs begin
with
> "xri://" or with either an xref or gcs character.
> 
> 2.  [This is the issue that is still open.]  Should multiple xrefs and
> characters be allowed to be mixed in a subsegment in the path (the
part of
> an XRI after the first "/" and before a fragment or query)?  E.g.,
> xri://@foo/(bar)abc(xyz).  The issue at stake here is should the path
be
> left as flexible and loosely-defined as possible, or should the XRI
> specification make stronger statements about the syntax and semantics
of
> segments or sub-segments in the path (and what should that syntax and
> semantics be).
> 
> 3.  Should production names that refer to sub-segments have "sub" in
their
> names or is it ok to just call them "segment" productions?
Resolution:
> replace "segment" in the appropriate productions with "subseg".
> 
> 4.  Support for authority-less XRIs.  E.g., xri:/foo.  Resolution:
Remove
> support for authority-less XRIs.
> 
> 5.  Should we follow 2396bis and disallow "[" and "]" in the query and
> fragment productions? Resolution: Follow 2396bis.
> 
> Two errors were also found in the ABNF and have been corrected.  The
first
> allowed an XRI authority that started with an xref to be followed by
> arbitrary characters (e.g., xri://(@foo)abc).  The second allowed a
> subsegment in an XRI authority to be composed of an arbitrary number
of
> characters and xrefs (e.g., xri://@foo.(@bar)abc(@xyz)def).  This
second
> error is related to issue number 2 above, but such behavior was never
> supposed to be allowed in the authority part of an XRI.
> 
> Mike