RE: [xri] RE: Single delegation character

["Drummond Reed" <drummond.reed@cordance.net>]

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
.