RE: [xri] RE: Single delegation character

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

Good point. Now that we've beaten the delegation issue to death, we can
come back to the original question about whether we should define one or
two second level delimiters.

The question is whether we prefer

xri:@:3*:4*:5/*:6*:7

or

xri:@:3:4:5/:6:7

for reasons already stated. My preference is the second, i.e. to define
two second level separators, star ("*") and colon (":").

Dave

> -----Original Message-----
> From: Loren West [mailto:loren.west@epok.net]
> Sent: Thursday, June 10, 2004 11:37 AM
> To: xri@lists.oasis-open.org
> Subject: RE: [xri] RE: Single delegation character
> 
> 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
> .
> 
> 
> 
> 
> 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.