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] 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]