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] GlobalID (was RE: [xri] Minutes:Joint XRI & XDI TC Telecon Thursday 2007-06-21)


How does using a persistent XRI for a providerID relate to having private roots?

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Monday, July 09, 2007 10:20 PM
To: 'Markus Sabadello'
Cc: xri@lists.oasis-open.org
Subject: [xri] GlobalID (was RE: [xri] Minutes:Joint XRI & XDI TC Telecon Thursday 2007-06-21)

 

Markus, see [=Drummond] inline.

 


From: markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Monday, July 09, 2007 7:57 PM
To: Drummond Reed
Cc: xri@lists.oasis-open.org; xdi@lists.oasis-open.org
Subject: Re: [xri] Minutes:Joint XRI & XDI TC Telecon Thursday 2007-06-21

 

 

On 7/9/07, Drummond Reed <drummond.reed@cordance.net > wrote:

 

* Wil and Markus have both pointed out in email that value of a GlobalID can be deduced from the value of a LocalID element in all previous XRDs in the chain of resolution. However Drummond pointed out that a GlobalID still adds information in that it selects a specific subset of those LocalIDs to produce an absolute GlobalID. In most cases this will be a subset of the LocalIDs in the resolution chain that are persistent identifiers, vs. other LocalID values that may be reassignable.


Okay let's assume I find the crazy but legal <GlobalID>=example.name!1234</GlobalID>, which I want to verify. Rule 3 of XRI to XRI CanonicalIdVerification tells me how I do that:

"The value of EACH xrd:XRD/xrd:GlobalID element asserted in an XRD MUST be an identifier for which the authority providing the XRD, as identified by value of the xrd:XRD/xrd:ProviderID element, is authoritative."

But my ProviderID looks like this: <ProviderID>xri://=!f831.62b1.44fd.2855</ProviderID>
Help! What do I do now? It seems the resolver can't rely on the ProviderID, right? If it wants to be able to verify every possible (however crazy) <GlobalID>, it must remember all subsegments, LocalIDs AND (hierarchical) CanonicalIDs from previous XRDs.

[=Drummond] The role of ProviderID is essentially to provide the CanonicalID for the XRD provider (vs. the target resource). Any verified synonym of that ProviderID will also work. See below.

However I think I am beginning to like GlobalID. Not because it fills a gap between LocalID and CanonicalID (noone ever missed it, right?),

[=Drummond] Not until now…;-)

and not because it adds extra information (you could really replace it with a LocalID, the resolver must remember the previous ones anyway), but because it allows you to separate the whole process into two steps: First you resolve your original XRI, along the way you verify any GlobalIDs you find. And second, you resolve the polyarchical CanonicalID, looking for a Ref or Backref to one of the (already verified) GlobalIDs of your original XRI.

Did I get that right?

[=Drummond] Exactly right. It constrains the whole Canonical ID verification process because with each XRD, all the resolver needs to do is: a) verify each asserted GlobalID, if any (which MUST be hierachical, so it’s very efficient to verify), and b) verify any asserted CanonicalID, if any (which, if it is hierarchical, verifies just like a GlobalID, or if it is polyarchical, will reference back exactly as you put it – to one of the (already verified) GlobalIDs of your original XRI).

By the way, the ProviderID keeps confusing me, perhaps someone could respond to my earlier mail on that.

[=Drummond] I’m sorry I didn’t reply to that – I meant to but got swamped. See below.

Or if it was too complicated, here is a short version:
1) What was the idea behind allowing URNs as ProviderID ?

[=Drummond] That idea was first promulgated by XRI TC representatives from Epok that pointed to XRI namespaces and other places where URNs were already being used as persistent identifiers for resources. If such an XRI authority already has a URN, it might want to continue using it. However in ED03, I think we should:

1) Strongly recommend use of a persistent XRI for XRI authorities.

2) Further clarify in the new Self-Description section (the section that will define how you can get a self-describing XRD from any XRI authority, including a community root authority) that ProviderID is synonymous with any verified GlobalID, CanonicalID, Ref, or Backref in a self-description XRD. That way even if an XRI authority wants to use a URN as a ProviderID, a resolver can determine its XRI synonym on which other GlobalIDs can be rooted.


2) What goes into the ProviderID if you retrieve an XRDS from an URL ?

[=Drummond] Good question. Since URLs do not have an authority chain, other than fragments (for which the fragmentless URL is authoritative), they are “flat”. So the ProviderID would be the same as the original URL. That’s another big difference between XRIs and URLs.

[=Drummond] Hope this helps. Keep asking these great questions!

=Drummond

 



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