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] | [Elist Home]


Subject: RE: [xri] Top Ten XRI Requirements


Looks like these "Top" requirements are specifically for the 
addressing aspect of XRI. I suppose there are other parts 
to XRI. To me, one of the most important aspect of such protocols is 
the access control. Without it, one cannot safely resolve and 
share data. Thus, access control and traceability is one of the priorities. 

I am going to send another requirement tomorrow. 

By the way, is anyone on this list working on something like GCI 
and IC Tag? We might need to look at these as well. 
On similar note, Japanese government is also working on similar 
code/messaging scheme that we may want to influence. 

Nat

> -----Original Message-----
> From: Drummond Reed [mailto:Drummond.Reed@onename.com]
> Sent: Wednesday, February 05, 2003 4:29 AM
> To: 'xri@lists.oasis-open.org'
> Subject: [xri] Top Ten XRI Requirements
> 
> 
> All:
> 
> In reviewing our strawman requirements document and Gabe's excellent
> motivations document, I found myself wanting to boil it down 
> to a "top ten"
> list to help us focus on the essence, particularly as we 
> approach the f2f.
> 
> I publish the following as a first attempt at doing this, and 
> also as a
> reminder to everyone of their homework assignment to send in 
> to the list
> either: a) any open issues relative to the requirements 
> proposed so far, or
> b) confirmation that you don't have any open issues.
> 
> =Drummond 
> 
> TOP TEN REQUIREMENTS FOR XRIs
> 
> 1) Location-independence: the ability for an identifier to identify a
> resource independent of its physical location on the network.
> 
> 2) Application- and transport-independence: the ability for 
> an identifier to
> identify a resource independent of the application or protocol used to
> access the resource. 
> 
> 3) Persistence: the ability for an identifier to permanently 
> identity the
> same resource (i.e., not be reassigned).
> 
> 4) Human and machine optimization: the ability for identifiers to be
> optimized for either human readability/memorability or 
> machine and network
> efficiency.
> 
> 5) Peer-to-peer: the ability for any resource to serve as its own root
> identifier authority (i.e., no centralized or absolute 
> authority required).
> 
> 6) Unlimited federation: the ability for identifier authority to be
> delegated to any depth. 
> 
> 7) Context addressability: the ability for a resource to be 
> identified in
> the context of another resource.
> 
> 8) Attribute addressability: the ability to identify the 
> attributes of a
> resource to any depth.
> 
> 9) Version addressability: the ability to identify the versions of a
> resource or its attributes to any depth.
> 
> 10) Extensibility: the ability for the identifier scheme to 
> be extended by
> adding new sub-schemes without changing the underlying architecture. 
> 


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


Powered by eList eXpress LLC