RE: [xri] RE: Single delegation character

["Loren West" <loren.west@epok.net>]

Thank you for clarifying the fact that we're only talking about
the XRI-Authority part of the XRI.  It has helped this thread
get back to it's original topic.

The original topic had to do with dropping the ":" as a 
sub-segment separator, and replacing it with "*:".

I'm not a proponent of that change.  Maybe because I don't
understand the benefit of a single separator, but mostly 
because it adds clutter to MFIs.

=Loren

-----Original Message-----
From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] 
Sent: Thursday, June 10, 2004 10:49 AM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] RE: Single delegation character


After discussing this with Drummond last night, it's clear that I've
done a poor job explaining my understanding of this issue. I think
Drummond and I reached consensus, so I'll give it one more shot here.

First, I think the concept of "delegation" has almost no role if you're
only talking about syntax. Delegation is only meaningful in the context
of either resolution or local access. In pure XRI syntax, all we're
talking about is successive levels of hierarchy.

In a conventional URI, the slash ("/") character denotes hierarchy. If
the URI contains an authority component, one important hierarchy is
between the authority and the remainder of the path. For example, in
http://www.example.com/foo, we can identify two hierarchical elements -
the authority (www.example.com) and the path (/foo). In a URI like
http://www.example.com/foo/bar, the path component (/foo/bar) is also
hierarchical, but that's pretty much all we can say about it. We can't
make any assumptions about delegation. (Incidentally, the only
assumption about delegation made by 2396bis is between the authority
component and the path, i.e. on the first slash. "Many URI schemes
include a hierarchical element for a naming authority, such that
governance of the name space defined by the remainder of the URI is
delegated to that authority (which may, in turn, delegate it further)."

In http://www.example.com/foo/bar, the authority component
(www.example.com) contains a second level of hierarchy delimited by dot
("."). (It's not entirely clear to me why dot is allowed to act as a
delimiter in the authority component by the current rules of 2396bis,
but that's a different problem.) Similarly, XRIs provide second level
delimiters in the xri-authority component via star ("*") and colon
(":"). For example, in xri:@example*foo/bar, we have first level
hierarchy between the xri-authority (@example*foo) and the path (/bar),
and second level hierarchy within the xri-authority (between @ and
example and between example and foo). Likewise with xri:@:1:2/foo, where
: acts as the second level delimiter.

In URIs, second level delimiters are defined only for special cases of
the authority component, specifically for IP addresses and domain names.
No second level delimiter is defined generally. XRIs, in contrast,
reserve star and colon as second level delimiters throughout the XRI.
For example, in xri:@:1:2/:3:4/:5:6, the first level of hierarchy is
denoted by the slash, with special consideration for the leftmost first
level element (the authority), and the second level of hierarchy within
each component delimited by slashes is denoted by the colon. In other
words, we can separate the above XRI into two logical components,
authority and path (@:1:2 and /:3:4/:5:6). We can divide the path into
two hierarchical elements, :3:4 and :5:6. We can further divide each of
those into two second-level hierarchical elements (:3 and :4, and :5 and
:6, respectively). At the generic syntax level that's all we can say,
with the possible exception of namespace delegation between the
authority and the rest of the path.

Now, if we consider standard resolution, we CAN say more about
delegation. Specifically we can say that in the authority component star
and colon imply delegation. That's _not_ because of some intrinsic
characteristic of star and colon, but rather because of the semantics
defined for those characters specifically for the authority component by
standard resolution. Note that in a different resolution protocol,
delegation might not be implied.

Similarly, local access protocols and/or local implementations can
define delegation semantics for either first or second level delimiters
in the path component, but that's outside the scope of the XRI spec. At
the syntax level as defined by the spec, these characters only denote
successive levels of hierarchy without respect to delegation.

Dave

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Wednesday, June 09, 2004 6:05 PM
> To: xri@lists.oasis-open.org
> Subject: RE: [xri] RE: Single delegation character
> 
> Dave, I was careful to qualify my entire point with the statement,
"within
> the XRI authority portion of an XRI". I never meant anything more than
> that,
> which is why I made that qualification.
> 
> It is true that the proposed XRI addressing rules for the proposed XDI
> metaschema carry this distinction further down into XDI documents,
which
> is
> all the province of a different TC. However that proposal only applies
> within the context of XDI, and only if the XDI TC decides on that
> approach.
> 
> =Drummond
> 
> -----Original Message-----
> From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
> Sent: Wednesday, June 09, 2004 5:49 PM
> To: Drummond Reed; xri@lists.oasis-open.org
> Subject: RE: [xri] RE: Single delegation character
> 
> 2396bis says slash ("/"), question mark ("?"), and number sign ("#")
are
> all hierarchy characters. These characters serve two purposes - first,
> to make identifiers easier to read by using a common syntax and
second,
> to provide a uniform representation of relative references (and
> consequently common algorithms for processing them).
> 
> In @foo/bar/baz, I think all we can say about /bar/baz is a) it's
> hierarchical and b) it's in a namespace controlled by the authority
> represented by @foo. If we're using standard resolution, we can also
say
> that if @foo/bar/baz is resolvable, the mechanism(s) for accessing the
> resource represented by /bar/baz is defined in an XRID associated with
> foo.
> 
> In @foo*bar/baz, all we can say for sure about @foo*bar is a) it's
> hierarchical using the second level delimiter and b) it's the
namespace
> authority for /baz. If we're using standard resolution, we can
> additionally say that @ is the namespace authority for foo, foo is the
> namespace authority for bar, and the mechanism(s) for accessing the
> resource represented by /baz is defined in an XRID associated with bar
> (assuming the XRI is resolvable).
> 
> None of this is all that different than Drummond's statement below,
but
> it doesn't support his conclusion. First, only the first slash has
> defined semantics. After that we have no idea whether or not slash
> represents "delegation" - that's completely determined by the local
> access protocol and/or internal implementations. Second, * or ! or
> whatever is only a second level hierarchical delimiter in the generic
> syntax. Semantics are defined only if we're using standard resolution,
> and then only in the authority component. Only in that special case,
> i.e. in the authority component when standard resolution is employed,
> does * or ! imply delegation.
> 
> Dave
> 
> 
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Wednesday, June 09, 2004 5:17 PM
> > To: xri@lists.oasis-open.org
> > Subject: RE: [xri] RE: Single delegation character
> >
> > I agree with Peter's characterization of the meaning of the
> distinction,
> > and
> > I believe that, within the XRI authority portion of an XRI, this
> > distinction
> > applies to all contexts. For example, in pure XRI technical terms,
the
> > distinction between "@foo/bar/baz" and "@foo*bar/baz" (to use star
as
> an
> > example of the delegation character) is that:
> >
> > * In "@foo/bar/baz", both "/bar" and "/bar/baz" are identifiers for
> > resources assigned by the identifier authority "@foo".
> >
> > * In "@foo*bar/baz", both "@foo" and "@foo*bar" are identifier
> > authorities,
> > and the latter is the identifier authority responsible for
identifying
> the
> > resource "/baz".
> >
> > So essentially slash is the "hierarchy character" (taking our queue
> from
> > 2396bis BNF) that does NOT delegate authority, as opposed to star
(or
> > whatever delegation character we decide on) which explicitly
delegates
> to
> > another identifier authority.
> >
> > =Drummond
> >
> >
> > -----Original Message-----
> > From: Peter C Davis [mailto:peter.davis@neustar.biz]
> > Sent: Monday, June 07, 2004 7:25 AM
> > To: Loren West
> > Cc: 'Fen Labalme'; xri@lists.oasis-open.org
> > Subject: RE: [xri] RE: Single delegation character
> >
> > I think of the distinction (highly simplified) as:
> >
> > a slash denotes a resource in the context of an authority (@idc/fen)
> > while the "delegation char" is a resource authority.
> >
> > subtle but important distinction.
> >
> > --- peterd
> >
> > On Mon, 2004-06-07 at 01:46, Loren West wrote:
> > > You're right, the dot means delegation in the authority section.
> > > I was referring to your statement about the slash having specific
> > > meaning (you said it's the stuff @idcommons knows about fen).
> > >
> > > =Loren
> > >
> > > -----Original Message-----
> > > From: Fen Labalme [mailto:fen@idcommons.org]
> > > Sent: Friday, June 04, 2004 6:25 PM
> > > To: Loren West
> > > Cc: xri@lists.oasis-open.org
> > > Subject: Re: [xri] RE: Single delegation character
> > >
> > >
> > > I don't believe I have.  In the authority section (before the
first
> > > forward slash) dot means delegation.  Am I not correct?
> > >
> > > Loren West wrote:
> > > > I understand that you have attached additional semantics to
> > > > the identifiers beyond the scope of the XRI TC, and it's why
> > > > you're reluctant to ask users if they prefer a syntax
> > > > that they may be more familiar with.
> > > >
> > > > Another example of the problems associated with encoding
> > > > semantics into identifiers.
> > > >
> > > > One could argue that XRI is here because of the
> > > > semantics embedded within existing identifier systems,
> > > > and it's why I'm fairly sensitive about keeping them to
> > > > an absolute minimum within the XRI TC.
> > > >
> > > > =Loren
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Fen Labalme [mailto:fen@idcommons.org]
> > > > Sent: Friday, June 04, 2004 5:12 PM
> > > > To: Loren West
> > > > Cc: xri@lists.oasis-open.org
> > > > Subject: Re: [xri] RE: Single delegation character
> > > >
> > > >
> > > > Yes, I agree that @idcommons/fen and @idcommons*fen could be
> defined
> > to
> > > > be equivalent, but we have a real reason that we want then to be
> > > > different.  The ability to explicitly state that @idcommons*fen
is
> an
> > > > authority delegated to fen and @idcommons/fen is stuff
@idcommons
> > knows
> > > > about fen enables a useful differentiation.
> > > >
> > > > This still leaves the door open for some communities to define
> that
> > > > e.g., @epok/loren defines an authority loren delegated by epok,
> but
> > > > that's a choice up to the community.  I'd rather not make it in
> the
> > > syntax.
> > > >
> > > > Fen
> > > >
> > > > Loren West wrote:
> > > >
> > > >>Actually, @idcommons/fen is anything @idcommons wants it to
> > > >>be - including a delegation to a different endpoint that
> > > >>fen has control over.
> > > >>
> > > >>It could work the same as @idcommons*fen.  I believe a user
> > > >>given this option will choose it over bang or splat, and
> > > >>it would be a shame if you're conducting a survey to leave
> > > >>it out.
> > > >>
> > > >>The XRI specification says nothing about what @idcommons/fen
> > > >>means, and very little about what @idcommons*fen means
> > > >>other than it's a delegated means of obtaining an endpoint.
> > > >>
> > > >>It specifically excludes the concept of identity, or what
> > > >>one identity knows about another identity, or who owns what,
> > > >>or where control lies.
> > > >>
> > > >>=Loren
> > > >>@idcommons*Loren
> > > >>@idcommons/Loren
> > > >>
> > > >>The above examples may point to 3 different places, or to
> > > >>the same place.  There isn't any expression that I have
> > > >>control of any of these places.
> > > >>
> > > >>I believe that as soon as you express that information within
> > > >>an identifier you get yourself into trouble.  It's complex
> > > >>information, and changes at a different rate than the
> > > >>identifier (which means it de-stabilizes the identifier
> > > >>when it changes).
> > > >>
> > > >>It's meta-data about the resource pointed to by the
> > > >>identifier, and outside the scope of this TC.
> > > >>
> > > >>=Loren
> > > >>
> > > >>-----Original Message-----
> > > >>From: Fen Labalme [mailto:fen@idcommons.org]
> > > >>Sent: Friday, June 04, 2004 3:17 PM
> > > >>To: Loren West
> > > >>Cc: xri@lists.oasis-open.org
> > > >>Subject: Re: [xri] RE: Single delegation character
> > > >>
> > > >>
> > > >>Loren West wrote:
> > > >>
> > > >>
> > > >>>Fen - while you're at it, you should try asking if they prefer
> > > >>>@idcommons/fen to either of the above.  That works regardless
> > > >>>of the change to the spec (if any).
> > > >>
> > > >>
> > > >>No, Loren - it doesn't work.  Unless we make / the delegation
> > character
> > > >>( which I think would be a very bad idea).  @idcommons/fen is
what
> > > >>idcommons authority knows about fen, as opposed to
@idcommons!fen
> in
> > > >>which idcommons delegates to the fen authority, which is what we
> want.
> > > >>
> > > >>
> > > >>
> > > >>>I prefer bang over splat, and admit to printing a "bang name"
> > > >>>on my business card in the past.
> > > >>
> > > >>
> > > >>Yeah, I had one, too.  1982 or so.  I kinda like bang, too, but
> I'm a
> > > >>geek.  I'm looking forward to this weekend (survey) to kind out
> what
> > > >>normal people think.
> > > >>
> > > >>=Fen
> > > >>
> > > >
> > > >
> > > > 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
> > .
> >
> >
> >
> > 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
.