RE: [xri] updated proposed XRI 1.1 ABNF

["Lindelsee, Mike " <mlindels@visa.com>]

Dave,

The behavior of the xri-path-noscheme production isn't intended to limit relative-XRIs in the way that you are pointing out that it does.  Do we want to put any constraints on relative-XRIs outside of those that arise in xri-path-absolute?

Mike  

> -----Original Message-----
> From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
> Sent: Tuesday, September 28, 2004 2:03 PM
> To: Lindelsee, Mike ; xri@lists.oasis-open.org
> Subject: RE: [xri] updated proposed XRI 1.1 ABNF
> 
> 
> 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