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: RE: [xri] updated proposed XRI 1.1 ABNF


We discussed this on the XRI Editors call and I think there was
consensus that it shouldn't be allowed, for the same reason you can't
have something like http:www.epok.net.

Dave

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Monday, October 04, 2004 4:31 PM
> To: Dave McAlpin; 'Lindelsee, Mike '; xri@lists.oasis-open.org
> Subject: RE: [xri] updated proposed XRI 1.1 ABNF
> 
> I agree if in fact we don't want "xri:@foo" to be legal, only "@foo".
I'm
> not sure I'm convinced of the former, however. Why do we explicitly
not
> want
> to allow that?
> 
> (Maybe I'm just being brain-dead on a Monday ;-)
> 
> =Drummond
> 
> -----Original Message-----
> From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
> Sent: Monday, October 04, 2004 3:57 PM
> To: Drummond Reed; Lindelsee, Mike ; xri@lists.oasis-open.org
> Subject: RE: [xri] updated proposed XRI 1.1 ABNF
> 
> That won't work because xri:@foo would be legal, which is what we were
> trying to avoid in the first place. I'm ok with
> 
>  XRI           = [ "xri://" ] xri-hier-part [ "?" xri-query ]
>                [ "#" xri-fragment ]
>  xri-hier-part = ( xri-authority / iauthority ) [ xri-path-absolute ]
>                / ipath-empty
>  absolute-XRI  = [ "xri://" ] xri-hier-part [ "?" xri-query ]
> 
> Dave
> 
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Monday, October 04, 2004 3:52 PM
> > To: Dave McAlpin; 'Lindelsee, Mike '; xri@lists.oasis-open.org
> > Subject: RE: [xri] updated proposed XRI 1.1 ABNF
> >
> > The problem is that we want "//" to be optional in a native absolute
> XRI.
> > In
> > other words, to satisfy our human-friendly identifier requirement,
the
> > following should be legal native XRIs (i.e., before conversion to
IRI
> > normal
> > form):
> >
> > 	=foo
> > 	@foo
> > 	xri:=foo
> > 	xri:@foo
> >
> > So, if we are to follow RFC2396bis format, then we need to make "//"
> > optional in both XRI and absolute-XRI, then require the "//" be
> present
> > when
> > converting to IRI normal form.
> >
> > XRI           = [ "xri:" ] xri-hier-part [ "?" xri-query ]
> >                 [ "#" xri-fragment ]
> > xri-hier-part = ["//"] ( xri-authority / iauthority )
> >                 [ xri-path-absolute]
> >               / ipath-empty
> > absolute-XRI  = [ "xri:" ] xri-hier-part [ "?" xri-query ]
> >
> > =Drummond
> >
> >
> > -----Original Message-----
> > From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
> > Sent: Tuesday, September 28, 2004 6:05 PM
> > To: Lindelsee, Mike ; xri@lists.oasis-open.org
> > Subject: RE: [xri] updated proposed XRI 1.1 ABNF
> >
> > XRI and absolute-XR are inconsistent wrt //.
> >
> > XRI           = [ "xri://" ] xri-hier-part [ "?" xri-query ]
> >               [ "#" xri-fragment ]
> > xri-hier-part = ( xri-authority / iauthority ) [ xri-path-absolute ]
> >               / ipath-empty
> > absolute-XRI  = [ "xri:" ] xri-hier-part [ "?" xri-query ]
> >
> >
> > One possibility is to add // to absolute-XRI, like
> >
> > absolute-XRI  = [ "xri://" ] xri-hier-part [ "?" xri-query ]
> >
> >
> > but my preference is to follow 2936bis.
> >
> > XRI           = [ "xri:" ] xri-hier-part [ "?" xri-query ]
> >               [ "#" xri-fragment ]
> > xri-hier-part = "//" ( xri-authority / iauthority ) [
> xri-path-absolute
> > ]
> >               / ipath-empty
> > absolute-XRI  = [ "xri:" ] xri-hier-part [ "?" xri-query ]
> >
> > 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
> >
> >
> > To unsubscribe from this mailing list (and be removed from the
roster
> of
> > the
> > OASIS TC), go to
> > http://www.oasis-
> > open.org/apps/org/workgroup/xri/members/leave_workgroup.php
> > .
> >
> >
> >
> >
> > To unsubscribe from this mailing list (and be removed from the
roster
> of
> > the OASIS TC), go to http://www.oasis-
> > open.org/apps/org/workgroup/xri/members/leave_workgroup.php.
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster
of
> the
> OASIS TC), go to
> http://www.oasis-
> open.org/apps/org/workgroup/xri/members/leave_workgroup.php
> .
> 
> 



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