Re: Perisistence (was RE: [XRI] Private naming conventions and hypermedia)

Hi Stuart,

Reply inline.

On 7-Aug-08, at 2:57 AM, Williams, Stuart (HP Labs, Bristol) wrote:

> Hello John,
>
> Firstly a missed question, given your first response:
>
>> A is correct an authority at any level of the hierarchy can mint
>> subordinate subsegments that are either regular or non-reassignable.
>
> there was a second question that went unanswered... and given your  
> answer
> I'm really interested only in assignment of top lebel persistent  
> segment
> names.
>
>>> Secondly, how does one obtain an assigned persistent segment name?
>
> My guess is that were I to register say '=skw' the registration  
> process
> would necessarily assign a fresh persistent segment name of the form  
> =!nnnn.
> nnnn.nnnn.nnnn (particular form not important only that is unique  
> over all
> time amongst the persistent names assigned by
> the authority for '='). Basically if I register a top-level i-name I  
> can't
> not have an assigned persistent segment name which at least at the  
> time of
> registration the more human friendly form is a synonym for.
>

Every XRI resolves to meta-data with a CanonicalID element.  That  
CanonicalID is assigned by the parent authority to the target resource  
described by an XRD.

This must be an identifier for which the parent authority is the final  
authority.

For any XRI other than a community root authority (DNS) the CID must  
consist of the parent authorities CanonicalID plus one additional  
subsegment.

Once assigned, a parent authority SHOULD NEVER
a) change or reassign a CanonicalID value
b) stop asserting a CannonicalID element in an XRD in which it has  
been asserted.

For those reasons XRI 2.0 resolution STRONGLY RECOMMENDS using a  
persistent XRI or URN for the CannonicalID

Typically when @ or =  are the parent authority a persistent XRI  
identifier is created like !1.2.3.4, this is added to the CID of the  
appropriate registry ie =!1.2.3.4

There is nothing to stop GRS from minting =!skw as a CID if they  
wanted to.  It would be valid.
People are discouraged from encoding semantic meaning in CID.

This becomes the CID of the target resource.

In XRI CanonicalIDs play a special role in the XRD synonym  
architecture in that they are the ultimate test of XRD equivalence.

On the other hand the answer you may be looking for is, the price of a  
iNumber from GRS is about $1US/year and is normally bundled in the  
$12US/Year cost of an iName.

You can register multiple iNames against the same iNumber if you want  
to use them as synonyms, and save the $1/year .

iNumbers like iNames are portable between registrars.


>
> Assuming that that's out of the way, back to what it is that is  
> persistent.
>
> Your response to my question on that was:
>
>> B)  is the closest.  It is the mapping assigned by the parent
>> authority to the relationship between and administrative
>> authority and  the identifier.
>
> where B) was
>
>>> b) The association between the identifier and whatever it refers  
>>> to (a
>>> resource?)?
>
> I think this in part gets close to the heart of the matter. What I  
> believe
> you are saying is that what it is that is persistent is, as you say,  
> the
> relationship between an (persistent) identifier and the authority that
> administers it.
>
Yes it is an administrative relationship.
! segments are used to specify persistent identifiers― 
identifiers that are permanently assigned to a resource and will not  
be reassigned at a future date.

In this context the resource is the XRD document.  The administrative  
control of that XRD document must not be reassigned.

If =skw is assigned to you along with =!BF81.FD97.C81B.B4E5 and at  
some point you stop paying for =skw and TBL wants to purchase it he  
can get =skw but not =!BF81.FD97.C81B.B4E5,  a new CID would be  
created if he needed it.

As the openid.claimed_id is the CID and not the iName TBL would not be  
able to get access to your resources.

It is always possible to reassign the administrative control of a XRD  
to some other entity if the owner requests it.
That might be necessary if a company is sold or something like that.

> This is largely a social matter wrt to administrative policy rather  
> than a
> technical one. The underlying social issue that this seeks to  
> address is a
> lack of stabilty in this relationship induced by the administrative  
> policies
> assoicated with the DNS - specifically, that the authority for a given
> domain name can change over time. If DNS domains were not 'rented'  
> on a 1-2
> year renewal basis where an authority can 'accidentally' loose
> administrative control over the name through inattention, or simply
> relinquish control which is subsequently picked up by another party.
>
> Is that the primary issues that motivates persistent (top-level) XRI  
> path
> names?

Yes DNS has no way to detect identifier recycling.  It is quite  
common.  having the CIDs be persistent like URNs is the way that we  
addressed the issue.

Detecting recycling doesn't stop the DNS identifiers from changing  
hands,
Where with persistent XRI the parent authority is explicitly making a  
promise not to do that.

>
>
> I don't know the DNS spec's or administrative practices well enough  
> to know
> whether there are fields within it that serialise changes in authority
> associate with a name such that there are mechanisms by which such  
> changes
> could be detected. It seems plausible to me that there are or should  
> be such
> facilities within the DNS system - I am simply ignorant and yes this  
> is in
> danger of being FUD.
>
I think that would require some major changes to DNS,  software would  
have to remember when they interacted with an identifier and compare  
that to some date or serial number returned by DNS.

> Anyway, the point that I'm trying to make is that the issue is with  
> the
> social and administrative policies associated with the DNS system -  
> and the
> solution is to establish a separate namespace outside the DNS system  
> that
> has different social/adminsitrative policies (particularly wrt  
> persistent
> name segments) that better suits the requirements of the XRI  
> community.
> There is the question as to whether that alternate social/ 
> administrative
> system will endure into the long term such the the persistence  
> intended
> guarantees endure... or not - however that will largely be  
> determined by
> market forces (adoption) and 'crudely' the funding regime that  
> enables the
> administrative structure of XRI to persist - and probably includes  
> the use
> of IPRs to prevent duplicate/alternate root problems which we have  
> seen  in
> the DNS world (http://en.wikipedia.org/wiki/Alternative_DNS_root).
>
Remember that XRI are designed to be composable any subsegment can be  
a URI or other authority resolution service.
(http://xri.boeing.com)*jbradley   This uses a URI as the first  
subsegment bypassing GRS.

The XRI 2.0 spec allows anyone to run a community registry rooted in a  
URI.

The name is longer but is otherwise fully functional.
GRS (=,@) and iBrokers selling root and community names are bound by  
ICANN like agreements on privacy and other policy issues,  community  
registries have no such restrictions.

> A (say) .xri TLD with associated administrative policies induced on
> subdomain registrations would be an alternate way of meeting XRI  
> persistence
> requirements within the DNS system (would require negotiation and
> contractual agreements with ICANN). Likewise, as in the bradley/booth
> proposal (for want of a better name) subdomain registrations under  
> xri.net
> could work modulo the persistentence of the relationship between the
> registration of  xri.net and legal entity that serves as its  
> authority.
>
Yes special persistence rules could be established under a TLD.

I need to think about that.

The intent of the TLD was to use those DNS names for the proxy servers.
The XRI subsegments would be in the URI path.


> Anyway, the persistence XRI speaks of for persistent identifiers is  
> the
> persistent in the relationship between and identifier and its  
> administrative
> authority.
>

Yes,  the identifier is assigned to a XRD and the administrative  
authority for that XRD will not be reassigned.

By contrast a reassignable XRI can be assigned by an identifier  
authority to represent a different resource at some future time.

I hope that helps.

Best Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
五里霧中


> [Again just seeking to understand - not to take a particular position]
>
> Stuart
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell,  
> Berks RG12
> 1HN
> Registered No: 690597 England.
>
>
>> -----Original Message-----
>> From: John Bradley [mailto:john.bradley@wingaa.com]
>> Sent: 04 August 2008 18:04
>> To: Williams, Stuart (HP Labs, Bristol)
>> Cc: Mark Baker; Henry S. Thompson; www-tag@w3.org
>> Subject: Re: Perisistence (was RE: [XRI] Private naming
>> conventions and hypermedia)
>>
>> Hi Stuart,
>>
>> I will answer inline.
>>
>> On 4-Aug-08, at 7:11 AM, Williams, Stuart (HP Labs, Bristol) wrote:
>>
>>> Hello John,
>>>
>>>> Stuart Williams wanted me to have a stab at the
>> persistence question.
>>>> Hopefully this will advance the conversation.
>>>
>>> Let me unpick may question a bit, largely from a position
>> of personal
>>> ignorance on persistent XRI.
>>>
>>> Firstly a couple of syntactic/administrative questions using your
>>> example
>>> from below:
>>>
>>> 	xri://@!B1E8.C27B.E41C.25C3!A7B8.4D42.3EF6.C2A9
>>>
>>> As an XRI, this has two peristent segments:
>>>
>>> 	!B1E8.C27B.E41C.25C3
>>> and
>>> 	!A7B8.4D42.3EF6.C2A9
>>>
>>> Which of the following (if any) is correct:
>>>
>>> a) The second segment is scoped by the first (ie. the authority for
>>> !B1E8.C27B.E41C.25C3
>>>  can mint subordinate persistent path segments provided they meet
>>> some
>>> administrative
>>>  policy requirement eg. such that they are never re-assigned).
>>>
>> A is correct an authority at any level of the hierarchy can mint
>> subordinate subsegments that are either regular or non-reassignable.
>>
>>> Or...
>>>
>>> b) Each persistent segment name is independently globally
>>> significant and
>>> assigned by some
>>>  centrally administer registry.
>>>
>>>
>>> Secondly, how does one obtain an assigned persistent segment name?
>>>
>>> Ok... syntactic/admin questions out of the way...
>>>
>>> What is it that is intended to be persistent? Some candidate
>>> responses...
>>>
>>> a) The identifier? (but that is trivially true)
>>>
>>> b) The association between the identifier and whatever it refers  
>>> to (a
>>> resource?)?
>>>
>>> c) The resource itself in the sense that the resource is
>> persistently
>>> available to be accessed via the given identifier?
>>>
>>> d) The resource state in the sense that the state of the resource is
>>> invariant over all (future?) time
>>>  ie. all future retrieval operations provide access to an
>> invariant
>>> set of
>>> resource representations (content-type + bits).
>>>
>>> e) The meta-data accessed via the given identifier in the sense
>>> that, whilst
>>> it may change, it is persistently avaialable and
>>>  persistently about the thing designated by the identifier.
>>>
>>> f) The meta-data accessed via the given identifier in the
>> sense that
>>> that
>>> meta-data is invariant (and persistently available).
>>>
>>> In terms of wha you say below:
>>>
>>>> 2. Persistent,  "Not Reassignable"  These entities will by
>>>> administration policy will not change owner, or be
>> reassigned in any
>>>> way.
>>>>
>>>> Nether of these say anything about the contents of the XRDS,  the
>>>> contents of a given XRD associated with a CID can change
>> at any time.
>>>>
>>>> In XRI persistence is a quality of the identifier not the data.
>>>
>>> I don't know what you mean by this... that persistence "is
>> a quality
>>> of the
>>> identifier."
>>> That seems most closely aligned with a) or b) above, of
>> which b) is
>>> more
>>> useful and likely.
>>
>> B)  is the closest.  It is the mapping assigned by the parent
>> authority to the relationship between and administrative
>> authority and
>> the identifier.
>>
>> The administrative authority that is delegated
>> !A7B8.4D42.3EF6.C2A9 is
>> free to have any iname resolve to it or change the meta-data at any
>> time.
>>
>> Since the subsegments are hierarchical @!B1E8.C27B.E41C.25C3
>> is saying
>> that it will not recycle the local identifier
>> !A7B8.4D42.3EF6.C2A9 to
>> any other administrative authority.
>>
>> This is used in openID to detect if a XRI like xri://@id* 
>> 五里霧中
>> has been recycled to a new person/administrative entity.
>>
>> If I abandoned my registration and someone else wanted the name it
>> would have a new CID.
>> @!B1E8.C27B.E41C.25C3!A7B8.4D42.3EF6.FFFF or something like that.
>>
>> Since it is still administered by @id the first part would
>> remain the
>> same only the subsegment under the control of @id would change.
>>
>> Note the CID for @ is @
>> The CID for id is !B1E8.C27B.E41C.25C3 as assigned by the @ registry.
>>
>>>
>>>
>>>> In ARK Persistence is a quality of the data not the identifier.   A
>>>> given ARK URL may or may not exist at any point.  The only
>> thin that
>>>> may be persistent aside from the data would be the URI path.
>>>
>>> Ok... that's close to c) or d) above, I suspect d) with an
>>> expectation that
>>> the resource itself is invariant.
>>>
>>> Wrt to CanonicalIDs. Are they necessarily fully persistent
>> XRIs? Can
>>> they be
>>> any XRI or indeed URI?
>>>
>>> If two non-persistent XRI resolve (eventually possibly
>> after serveral
>>> resolution cycles) to the same (fully persistent?) XRI
>>> can we conclude that the original pair of XRI designate the
>> same thing
>>> (whatever it may be)? Currently? Over what temporal scope?
>>>
>>> All of these questions are merely seeking to understand the design
>>> intention
>>> or persistent requirements of XRI.
>>>
>> Re-assignable identifiers for CID can be used.  They are recommended
>> against but valid.
>>
>> The CID of a XRDS that is returned from a URI via Sec 6 resolution
>> ( Yadis/XRDS-Simple) is set by the document author and not
>> the parent
>> authority as that is DNS in this case.   For the CID to be Validated
>> in this case it must be the URI that the XRDS is retrieved from.
>> This is one of the places you would find a reassignable CID.
>>
>> If a subsegment is a cross reference then it is up to that
>> protocol to
>> provide a CID typically  the reassignable version of the identifier
>> itself is used.
>>
>> An example for tel:
>> xri://(tel:+1-201-555-0123)*foo
>>
>> The CID for the first subsegment is xri://(tel:+1-201-555-0123) and
>> the second !1234 so the full CID would be
>> xri://(tel:+1-201-555-0123)!
>> 1234.
>>
>> CID validation can be preformed automatically during resolution for
>> XRI that don't contain cross-references.  Where you have http: and
>> other cross-references a second resolution of the CID itself may be
>> necessary for validation.
>>
>> It's a long spec:)
>>
>> XRI need to be considered with all of there input parameters
>> including
>> accept headers if used in HXRI form.
>>
>> If two XRI when resolved with the same input parameters
>> resolve to the
>> same CID then they are considered to be equivalent for that
>> resolution.
>>
>> Equivalent in that for the service being resolved the meta data
>> returned will be equivalent for the identifiers.
>>
>> A single XRI iName may through the use of SEP references
>> resolve to a
>> different CID for each service if the author is so inclined.
>>
>> It is really more like DNS where multiple domain names may
>> resolve to
>> the same IP address,  but the same domain name if queried for
>> a MX or
>> some other record type may return a different IP address.
>>
>> I have probably raised more questions for you than I answered.
>>
>> Lets keep working through this.
>>
>> Thanks for the interest.
>>
>> Best Regards
>> John Bradley
>> OASIS IDTRUST-SC
>> http://xri.net/=jbradley
>> 五里霧中
>>
>>
>>> Regards
>>>
>>> Stuart
>>> --
>>> Hewlett-Packard Limited registered Office: Cain Road, Bracknell,
>>> Berks RG12
>>> 1HN
>>> Registered No: 690597 England
>>>
>>>> -----Original Message-----
>>>> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]
>>>> On Behalf Of John Bradley
>>>> Sent: 25 July 2008 19:40
>>>> To: Mark Baker
>>>> Cc: Henry S. Thompson; www-tag@w3.org
>>>> Subject: Re: [XRI] Private naming conventions and hypermedia
>>>>
>>>> Hi Mark,
>>>>
>>>> I am going to use the IRI form with the xri: scheme in my
>>>> examples as
>>>> that is what is currently in the spec.
>>>> the proposed HXRI forms add additional complexity.
>>>>
>>>> Remember XRI is more like DNS resolution than http:
>>>>
>>>> The process of dereferencing an XRI via native resolution always
>>>> results in a XRDS document containing a CannonicalID element
>>>> <CanonicalID>xri://@!1</CanonicalID>
>>>>
>>>> Any number of XRI may resolve to the same CID
>>>>
>>>> As an example
>>>> xri://@id*fmof
>>>> xri://@id*五里霧中
>>>> xri://@id*gorimuchuu
>>>> xri://@!B1E8.C27B.E41C.25C3!A7B8.4D42.3EF6.C2A9
>>>>
>>>> All of these deference to an XRDS document  with a CannonicalID
>>>> element in the final XRD containing
>>>> <CanonicalID>xri://@!B1E8.C27B.E41C.25C3!A7B8.4D42.3EF6.C2A9</
>>>> CanonicalID>
>>>>
>>>> The process of dereferencing a XRI maps the identifier to a uniques
>>>> entity described by an XRD
>>>>
>>>> Each XRI identifier may produce a different XRDS document during
>>>> resolution depending on the path through the XRI graph it takes.
>>>> The sequence of XRD's in a XRDS are determined by XRD refs and XRI
>>>> cross-references encountered during the resolution of the authority
>>>> sub segments.
>>>> However equivalence is determined via the contents of the
>> final XRD.
>>>>
>>>> If you look closely at the CID you will notice that it contains
>>>> subsegments prefixed with !.
>>>>
>>>> The ! indicates a persistent subsegment.
>>>>
>>>> The Syntax spec states:
>>>>
>>>>> An XRI consisting entirely of persistent segments is designed to
>>>>> meet the requirements set out in Functional Requirements
>>>> for Uniform
>>>>> Resource Names [RFC1737].
>>>>>
>>>>> XRI syntax extends generic IRI syntax in the following four ways:
>>>>>
>>>>> 	* Persistent and reassignable segments. Unlike generic
>>>> URI syntax,
>>>>> XRI syntax allows the internal components of an XRI
>>>> reference to be
>>>>> explicitly designated as either persistent or reassignable.
>>>>>
>>>>> 	* Cross-references. Cross-references allow XRI references to
>>>>> contain other XRI references or IRIs as
>>>> syntactically-delimited sub-
>>>>> segments. This provides syntactic support for “compound
>>>>> identifiers”, i.e., the use of well-known, fully-qualified
>>>>> identifiers within the context of another XRI reference. Typical
>>>>> uses of cross-references include using well-known types of
>>>> metadata
>>>>> in an XRI reference (such as language or versioning metadata), or
>>>>> the use of globally-defined identifiers to mark parts of an XRI
>>>>> reference as having application- or vocabulary-specific semantics.
>>>>>
>>>>> 	* Additional authority types. While XRI syntax supports
>>>> the same
>>>>> generic syntax used in IRIs for DNS and IP authorities, it also
>>>>> provides two additional options for identifying an authority: a)
>>>>> global context symbols (GCS), shorthand characters used for
>>>>> establishing the abstract global context of an identifier, and b)
>>>>> cross-references, which enable any identifier to be used to
>>>> specify
>>>>> an XRI authority.
>>>>>
>>>>> 	* Standardized federation. Federated identifiers are those
>>>>> delegated across multiple authorities, such as DNS names. Generic
>>>>> URI syntax leaves the syntax for federated identifiers up to
>>>>> individual URI schemes, with the exception of explicit support for
>>>>> IP addresses. XRI syntax standardizes federation of both
>>>> persistent
>>>>> and reassignable identifiers at any level of the path.
>>>>>
>>>>
>>>> This leads us to the question of what do we all mean by
>> "Persistence"
>>>>
>>>> In ARK I think that persistence is meant as some
>> indication that the
>>>> "Data/Meta Data"  pointed to by a specially formated URL path is
>>>> intended to be the same as data pointed to by the same specially
>>>> formated path under a different authority.
>>>>
>>>> This would seem on first examination completely different use case
>>>> compared to the "Persistence"  provided by XRI syntax and
>> resolution.
>>>>
>>>>
>>>> In XRI there are two basic subsegment types:
>>>> 1. Reassignable,  These identifiers can be re-used and
>> move from one
>>>> persons control to another they may be reconfigured to point to any
>>>> CannonicalID at any time for any reason under the control of the
>>>> person or organization who has administrative control of the
>>>> identifyer.
>>>>
>>>> 2. Persistent,  "Not Reassignable"  These entities will by
>>>> administration policy will not change owner, or be
>> reassigned in any
>>>> way.
>>>>
>>>> Nether of these say anything about the contents of the XRDS,  the
>>>> contents of a given XRD associated with a CID can change
>> at any time.
>>>>
>>>> In XRI persistence is a quality of the identifier not the data.
>>>>
>>>> In ARK Persistence is a quality of the data not the identifier.   A
>>>> given ARK URL may or may not exist at any point.  The only
>> thin that
>>>> may be persistent aside from the data would be the URI path.
>>>>
>>>> I find the concept of a persistent URL path without a
>> persistent URL
>>>> authority a bit of a slippery one.
>>>>
>>>> People will raise the question of what is a good administrative
>>>> authority who adheres to the rules vs a bad one.
>>>>
>>>> XRI and ARK have to answer that question to there constituent
>>>> communities.
>>>>
>>>> What ARK and XRI both enable is a syntactical way of communicating
>>>> persistence.
>>>>
>>>> Though I would argue different notions of persistence.
>>>>
>>>> When we look at HXRI the http: proxy starts attracting some of the
>>>> problems encountered by ARK.
>>>>
>>>> Take one of my above examples as a HXRI:
>>>>
>>>> http://xri.net/@!B1E8.C27B.E41C.25C3!A7B8.4D42.3EF6.C2A9
>>>>
>>>> I have now mixed what may be an in-persistent DNS authority with a
>>>> persistent XRI.
>>>> I have certainly lost the benefit of it being a URN, unless we move
>>>> forward with one of the proposals to create "Special DNS
>> Authorities"
>>>>
>>>> I suppose ICAN could make a special class of "Persistent
>>>> Authorities"
>>>> for DNS.
>>>>
>>>> Stuart Williams wanted me to have a stab at the
>> persistence question.
>>>> Hopefully this will advance the conversation.
>>>>
>>>> Best Regards
>>>> John Bradley
>>>> OASIS IDTRUST-SC
>>>> http://xri.net/=jbradley
>>>> 五里霧中
>>>>
>>>>
>>>>
>>>>>
>>>>> On 25-Jul-08, at 9:41 AM, Mark Baker wrote:
>>>>>
>>>>>
>>>>>> HST [...] I think there's a fundamental issue we need to be clear
>>>>>> on: is it OK for a group of domain name owners to agree a naming
>>>>>> convention amongst themselves? In the ARK case, this
>>>> trespasses on
>>>>>> the WebArch advice wrt aliasing, and in general might also
>>>> seem to
>>>>>> fall foul of the whole business of URI opacity (that was Mark
>>>>>> Baker's particular concern).
>>>>>
>>>>> "URI Opacity" is a term that I've found means different things to
>>>>> different folks, so I try to avoid it now.  But I do believe that
>>>>> private naming conventions do cause harm to the Web
>> because they are
>>>>> essentially a proprietary form of link and link metadata.
>>>> If two URIs
>>>>> at different domains identify the same resource,
>>>> dereferencing one of
>>>>> them should provide a declaration (Link header, RDFa,
>> whatever) that
>>>>> the resource is the same (owl:sameAs or equivalent) as the other.
>>>>>
>>>>>> From a REST perspective, the architectural constraint
>> that's being
>>>>> disregarded by this practice is "hypermedia as the engine of
>>>>> application state", and IMO, it's the constraint most
>>>> responsible for
>>>>> imparting Web-nature.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Mark.
>>>>>
>>>>
>>>>
>>
>>