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] AuthorityID best practices


I apologize for being so slow in responding - I was off email due to travel
most of last week. 

See inline marked ### below.


-----Original Message-----
From: Fen Labalme [mailto:fen@idcommons.org] 
Sent: Friday, April 15, 2005 10:54 PM
To: xri@lists.oasis-open.org
Subject: [xri] AuthorityID best practices

I'm a bit confused by the second of two URN's in a standard XRID:

  1) XRIDescriptor/AuthorityID identifies the describing authority

  2) XRIDescriptor/Authority/AuthorityID identifies the authority described
by this Authority

So in our market vocabulary, the resolver that produced this XRID always 
produces XRIDs with the same #1 AuthorityID.

### Do you mean "the *authority* that produced this XRID"? A resolver never
produces XRIDs, it only requests them. By the XRI specs, the server that
answers these requests is called the XRI authority. (Don't worry, I called
it resolver myself for months before we finished the XRI 2.0 specs and I
mended my errant ways ;-)

### Anyway, yes, the authority that produces the XRIDs has the #1

The #2 AuthorityID must match the one attached to the resolver pointed to by

the current Authority, such that when it is then called for its resolution 
step, it will return this value as its "#1" AuthorityID.

### Yes, except again it should be "The #2 AuthorityID must match the one
attached to the [delegated] *authority* pointed to by the current

Question: where is this #2 URN stored in the Registry?  If whenever it 
assembles an XRID with an XRIDescriptor/Authority element (for the
resolution of further delegated subsegments) it must also know that
resolver's associated URN, it seems like there is a bootstrapping problem
here (not to mention the fact that I don't believe current registries have a
field for this).

### Again, in the above para, it should be, "... it must also know that
*authority's* associated URN..."

Of course, as I stated above: I'm a bit confused by this, so maybe I don't 
understand how these values are used.  Can someone please enlighten me?

### The XRI specs don't dictate "where this #2 URN is stored in the
Registry", only that it is included in the XRID. But the "best practice" I
expect of XRI authorities in general is that their AuthorityID will be their
"best-known" persistent XRI ("i-number").

### While it is not an XRI specification requirement, I expect many (if not
most) XRI Authority registries will store at least one persistent XRI
(i-number) for each delegated Authority. In this case, I believe this
i-number is ideally suited to be used by that delegated Authority as their

### If a delegated Authority has more than one persistent XRI assigned by
another registry, the delegated Authority should of course indicate which
one should be used as its AuthorityID.

### Simple example using "@a*b": If the XRI authority "@a" has the
persistent XRI "@!123", then its AuthorityID could be "@!123" (that would be
your #1 URN). If "@a" then assigned to a delegated Authority both the
reassignable XRI (i-name) "*b" and the persistent XRI "!777", then the
delegated Authority would have the i-number "@!123!777" which it could use
as its AuthorityID. Since "@a" knows this i-number for every delegate, it is
easy for it to produce it as your "#2 URN" in the XRID describing "@a*b".

### I hope that answers your question.

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