[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] AuthorityID best practices
Fen, I apologize for being so slow in responding - I was off email due to travel most of last week. See inline marked ### below. =Drummond -----Original Message----- From: Fen Labalme [mailto:email@example.com] Sent: Friday, April 15, 2005 10:54 PM To: firstname.lastname@example.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 AuthorityID. 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 Authority..." 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 AuthorityID. ### 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.