RE: [xri] GCS Characters

["Schleiff, Marty" <marty.schleiff@boeing.com>]

What I don't like about @ and = is that they are an attempt to DESCRIBE
the named resource instead of just NAME the named resource. Everywhere
else we recognize the folly of trying to describe the resource in its
identifier, and instead look to XRDS and resolution to learn about the
actual resource. The syntactic characteristics of XRI should be used to
describe the identifier, not to describe the resource named by the
identifier. For example, "!" says the identifier is "persistent"; not
that the resource is persistent; $ and + say the identifiers are tags,
not that the named resource is a tag. Etc.

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow
Information Security Technical Controls
(206) 679-5933

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Monday, November 24, 2008 12:11 PM
To: Schleiff, Marty; 'Victor Grey'; 'John Bradley'
Cc: 'Chasen, Les'; 'OASIS XRI TC'; 'David Orchard'
Subject: RE: [xri] GCS Characters

While I appreciate Victor's suggestion (even though it does make my head
explode ;-), what it doesn't take into account is the policy differences
between = and @. The former represents a personal authority (where the
data subject is an individual) and the latter an organizational
authority (where the data subject is an organization). This is a vital
difference from many standpoints, particularly with respect to global
privacy laws (which differ markedly in the EU and Japan from the United
States). It is also a significant difference from trademark law and
property law.

As an example, XDI.org has implemented XRI 2.0 registries that implement
such policies for registration of = and @ identifiers -- policies that
took many months to develop.

	
http://gss.xdi.org/moin.cgi/FrontPage?action=AttachFile&do=get&target=gs
s-v1
.0.pdf

Lastly, in my work on data sharing implementations based on XRI and XDI,
the ability to distinguish between data subject to personal authority
and data subject to organizational authority has proven critical. One
motivation for the GCS Delimiter proposal is to make this easy for any
authority to declare than any data belongs in one space or another via
the use of both = and @ as delimiters. Any URI from anyone can be "cast"
as representing personal data or organizational data using the = and @
GCS characters:

	...=(http://example.com/data/uri)...
	...@(http://example.com/data/uri)...

=Drummond 


> -----Original Message-----
> From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
> Sent: Monday, November 24, 2008 11:01 AM
> To: Victor Grey; John Bradley
> Cc: Chasen, Les; Drummond Reed; OASIS XRI TC; David Orchard
> Subject: RE: [xri] GCS Characters
> 
> Then 1id.com might have to refund Boeing's purchase of @boeing ;-)
> 
> I agree with Victor. If there is a reason for two (= and @), then 
> there is a reason for more than just two (even though we may not yet 
> have discovered the reason). And I've always believed that the 
> difference between individuala and organizations may be difficult to 
> recognize, and therefore difficult to enforce. When an individual 
> acquires the "=example" XRI, they also acquire the rights to 
> administer the "=example" namespace. So if they register an 
> organization in their namespace, "=example*orgname" then that's an 
> identifier for an organization under the = space.
> 
> 
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow
> Information Security Technical Controls
> (206) 679-5933
> 
> -----Original Message-----
> From: Victor Grey [mailto:victor@idcommons.org]
> Sent: Monday, November 24, 2008 10:23 AM
> To: John Bradley
> Cc: Chasen, Les; Drummond Reed; OASIS XRI TC; David Orchard
> Subject: Re: [xri] GCS Characters
> 
> The confusion with email addresses, social, technical or otherwise, is

> not the only problematic aspect of the @ GCS character.
> XMPP addresses take the form of username@host/optional/path. The 
> username part (known as a JID or Jabber Identifier) has only a very 
> few disallowed characters, including whitespace and control chars and
: / "
> ' and of course @.
> 
> The = and @ GCS characters both denote a reassignable identifier for 
> an entity, as opposed to + and $ which identify terms.
> @ and = also serve as configurable aliases for an XRD discovery 
> function $f(x), for example $dns(xri.net).
> 
> If we didn't have to deal with @, we could define a very simple and 
> expandable set of transformations for XRD discovery:
> Given an abstract ID =drummond with $f(x) configured as $dns 
> (xri.net), here are some possible discovery transformations:
> https		https://xri.net/=drummond
> http		http://xri.net/=drummond
> xmpp		=drummond@xri.net
> mailto	=drummond@xri.net (I think there is an attractive case
for
an
> XRI aware mailserver that can resolve the XRI and make service 
> selections based on the XRD and x-headers.)
> 
> Other as yet to be invented communication protocols could all be 
> accommodated with this simple and very abstract spec. We shouldn't let

> the current kerfluffle with the W3C derail us into thinking that http 
> is the whole universe of possibility.
> 
> Since @ and = behave exactly the same way, and =ids --can-- be used as

> community roots already, I've never really understood any strong 
> necessity for the overloading of the entity identifier to distinguish 
> individuals from collections of individuals, and the disregard of the 
> fact that there could be other kinds of entities besides those two.
> 
> So at the risk of making everyone's head explode, I'm proposing that 
> we deprecate the @ GCS character in XRI 3, and make = the single GCS 
> character that denotes a reassignable identifier for any kind of
entity.
> An entity would be defined as anything that can have an XRD.
> 
> =vg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php