[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Interesting XRID bootstrap twist
As a specification writer, UUID vs. XRI doesn't matter to me one whit. I haven't thought through the implementation consequences of one vs. the other, so I think this is a case where real-world experience will lead to a best practice (be it, use UUID, use XRI, use either, or do something else). -Gabe > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Monday, April 11, 2005 11:32 PM > To: Wachob, Gabe; xri@lists.oasis-open.org > Subject: RE: [xri] Interesting XRID bootstrap twist > > Gabe, see inline ### below. > > -----Original Message----- > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Monday, April 11, 2005 5:16 PM > To: Drummond Reed; xri@lists.oasis-open.org > Subject: RE: [xri] Interesting XRID bootstrap twist > > I think you are basically correct though I admit I didn't really spend > much time working out the underlying logic. > > The contents of Resolved and the outer AuthorityID in the > Root XRID are > not really significant, as they are never really used -- but it > certainly makes sense for them to contain the leftmost subsegment. > > ### That's what I thought. > > The AuthorityIDs, btw, can contain any URI (need to check this once > again) so while what you have is legal, I think it would also be > acceptable (or even "normal") to have a UUID instead of the XRI's you > have there. > > ### You say "normal" to have a UUID there, and while I agree > that might be a > very common practice, it seems just as "normal" for an > XRI-based addressing > community to specify the use of persistent XRIs as > AuthorityIDs, given that > they fulfill the same requirements for global uniqueness and > persistence as > UUIDs. > > ### Does that make sense, or does anyone see a specific > reason to use UUIDs? > > =Drummond > > > > -----Original Message----- > > From: Drummond Reed [mailto:drummond.reed@cordance.net] > > Sent: Monday, April 11, 2005 4:48 PM > > To: xri@lists.oasis-open.org > > Subject: [xri] Interesting XRID bootstrap twist > > > > In section 2.2.3 of the Resolution spec we recommend the > > following about the > > root XRID for an identifier community: > > > > "The root XRID, or its location, is known a priori and is > part of the > > configuration of a resolver, similar to the specification > of root DNS > > servers in a DNS resolver. (Note that is not strictly > > necessary to publish > > this information in an XRID-it may be supplied in any format > > that enables > > configuration of the XRI resolvers in the community-but > > providing an XRID at > > a known location simplifies the process.)" > > > > XDI.ORG is doing this now for the community roots it plans to > > offer, and in > > writing the specs an interesting bootstrap twist has come up. > > According to > > section 2.2.2, the xrid:Resolved element is required, as is > > the AuthorityID > > element. But these take on an interesting role in the root > > XRID because the > > Authority being described can be the same Authority publishing the > > description. In other words, the XRID may be entirely > self-describing. > > > > To illustrate, look at the following hypothetical root XRID for the > > community "xri://(http://example.org)": > > > > <XRIDescriptors xmlns="xri://$res*schema/XRIDescriptor*($v%2F2.0)"> > > <XRIDescriptor xrid:id="first"> > > <Resolved>(http://example.org)</Resolved> > > <AuthorityID>(http://example.org)</AuthorityID> > > <Expires>2005-09-30T00:00:00Z</Expires> > > <Authority> > > <AuthorityID>(http://example.org)</AuthorityID> > > <Type>xri://$res*auth.res/XRIA</Type> > > <URI>http://example.org/resolve</URI> > > <URI>https://example.org/resolve</URI> > > </Authority> > > <TrustMechanism>xri://$res*trusted/None</TrustMechanism> > > </XRIDescriptor> > > </XRIDescriptors> > > > > In this case the Resolved element, the describing AuthorityID > > element, and > > the described AuthorityID element all end out being the same. > > Of course, the > > AuthorityID value could be different than the Resolved value. > > For example, > > this alternative uses a UUID for the AuthorityID: > > > > <XRIDescriptors xmlns="xri://$res*schema/XRIDescriptor*($v%2F2.0)"> > > <XRIDescriptor xrid:id="first"> > > <Resolved>(http://example.org)</Resolved> > > <AuthorityID> > > urn:uuid:c9f812f3-6544-4e3c-874e-d3ae79f4ef7b</AuthorityID> > > <Expires>2005-09-30T00:00:00Z</Expires> > > <Authority> > > <AuthorityID> > > urn:uuid:c9f812f3-6544-4e3c-874e-d3ae79f4ef7b</AuthorityID> > > <Type>xri://$res*auth.res/XRIA</Type> > > <URI>http://example.org/resolve</URI> > > <URI>https://example.org/resolve</URI> > > </Authority> > > <TrustMechanism>xri://$res*trusted/None</TrustMechanism> > > </XRIDescriptor> > > </XRIDescriptors> > > > > But it still ends out that the AuthorityID of the describing > > Authority and > > the described Authority are the same because it's a self > > description. Sort > > of like saying, "Bob says his name is Bob." > > > > I believe this is all consistent, but I just wanted to check > > with Gabe to be > > sure this is the way he forsaw root XRIDs working. And with > > Chetan to make > > sure this is what he forsaw with root XRIDs in trusted resolution. > > > > =Drummond > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all > > your TCs in OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr > > oups.php > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all > your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr > oups.php > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]