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


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_workgroups.php 





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