Re: GlobalID (was RE: [xri] Minutes:Joint XRI & XDI TC Telecon Thursday

Subject: Re: GlobalID (was RE: [xri] Minutes:Joint XRI & XDI TC Telecon Thursday 2007-06-21)

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

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.

[Markus] I think rule #3 should explicitly say that. When I read it, I first thought it allows only GlobalIDs that begin exactly with whatever is in the ProviderID. Maybe say explicitly that the resolver must allow any combination of verified synonyms in the resolution chain? (which I think include the original subsegments, the LocalIDs AND also CanonicalIDs, probably even the polyarchical ones).

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.

What should I put into the ProviderID if I want to support trusted resolution, but don't have any CanonicalIDs? Trusted resolution, like CID verification also requires matching the ProviderIDs. I guess then using a reassignable XRI is still better than generating some URN (this is what the OpenXRI server currently does).

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.

Self-describing XRDs? I've never heard of that, is it a new idea? :)

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.

Okay so if I get an XRDS from http://markus.at/xrds, then I get <ProviderID> http://markus.at/xrds</ProviderID>

And if I get an XRDS from http://markus.at/xrds#vienna, I also get <ProviderID> http://markus.at/xrds</ProviderID>, right ?

Do I get a <Query>...</Query> in either of these? I think no?

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

=Drummond

I modified the OpenXRI roadmap a bit according to all this. http://dev.inames.net/wiki/OpenXRI:RoadMap#Server_-_Authority

Markus

xri message